Question,
If you already have #!/bin/sh in the Autostart.sh file at the top, do you need to put it again just before the new items you added?
This #! is a shebang, and it tells the shell what program should be used to interpret the script when executed. -- in this case /bin/sh . If you wanted to use a different program, you could use for instance bash, and hence that line would become #!/bin/bash
The /var/ is a tmpfs, which means it's mounted in RAM, but in the case of logs, systemd's journal is used. In the /etc/systemd/journald.conf there's the following:
...
[Journal]
#Storage=auto
...It's commented out, and the value points to what is currently used as default. So the default behavior of this mechanism is to store the log files under /run/log/journal/ , and the /run/ dir is also a tmpfs resource mounted in RAM.
If you claim that fsck deletes your actual files with family photos and cat videos, you have to learn what data is checked by fsck.
I know what files it deleted, because it printed to the screen the name of the corrupted files.
If something works well for you, it doesn't necessary mean that it will work well for everyone else. In my cases there was data corruption and please accept this fact. This topic is not about what suits you or anyone well. I just came here to find a solution to the question asked in the very first post -- I just want to mount the drive read only, that's all.
====================================
GDPR-7, I found the solution.
The command that has to be added to the /storage/.config/autostart.sh script is the following:
(sleep 10 && mount -t ntfs-3g -o remount,ro /var/media/ntfs_data) &1. There's no need for the sync command after the umount command (in your suggestion), since when you issue the umount command, it will sync the filesystem before unmounting it.
2. There's no need for unmounting the drive's filesystem because you can simply remount it instead.
3. There's need for some delay of execution the above command, since the /storage/.config/autostart.sh script is started before the drive is detected. Basically all the USB devices have some delay before they will be detected. That's why I set the sleep command to 10 seconds, which should be just fine.
4. There's no need for delaying the boot process, and hence delaying also the start of Kodi. That's why the above command is run in the background instead of foreground. Without this, the whole boot process would take +10s, which isn't a good thing. When it runs in the background, the command simply waits for the 10s deadline, and then it fires and remounts the drive to read only mode.
It's a fair solution, but of course it could be better supported by LibreELEC by allowing to specify the mount flags natively using /etc/fstab, systemd units or udevil config.
Which files? If some temp files go to lost+found, it is not data loss. If you had unstable power grid that caused repeated power failures while your Linux was rebooting, it would have affected only file systems that were being written at the time of failure.
It was some nasty fsck errors, which corrupted many files -- I don't remember what it was saying, but I lost over 30G.
Well. My windows claims that my usb flash devices got errors in them and demands to scan them every time. Windows was never the brightest OS on the planet. File system checks do not remove files. Neither Linux fsck nor Windows chkdsk. If power failure causes physical damage to your disk platers, readonly file system will not protect you from that. Device will be spinning in readonly mode too.
I haven't been using windows for over 10 years, so I don't really know the system. The drive was plugged into a TV, which supported only NTFS based filesystem. Now I bought RPI and was looking for some Kodi based OOTB solution, and I found LibreELEC. I wanted to give it a try, but it has some weird limitations that really affect user experience.
As for removing files by fsck -- it can remove them when you have inconsistency in the filesystem. In my case (ext4), there was some major issues which demanded manual resolving -- something bad happened to the files, I don't know what but it happened. And if it happened once, it can happen again. I really don't want it to happen again in the future.
It is paranoia. File systems have journaling. In last ten years the only damage to ext3/ext4 that I've seen was not caused to power failure. It was caused temporally storage failure on hypervisor and the only impacted file systems were the ones that had stuff writing into them. And nothing of a value was lost. When data loss happened, it was caused by hardware failures and not by power. In those cases device was lost and not just file system.
How often do you turn off your pc forcefully via the power button? Maybe you should try more often? 
I'm reading many linux boards, and I constantly see issues related to corrupted filesystems after power failure or hang of the OS and force rebooting of the system. So, believe me it happens more often than you may think.
You were already been told that Kodi and Libreelec do not write into your attached storage. I suspected that some media library data goes into storage device, but I don't see anything extra on my automounted disk. If they are not writing anything, your device will not have any pending writes at the time of power failure and can be safely powercycled.
The value of 95+% isn't nothing. It still has a 5%- chance to write something -- and "I don't deal in chance" -- it always generates problems. I want to be sure that nothing gets written to the filesystem that I don't want to write.
Replace your USB HDD with devices that have hardware switches for readonly mode, if you don't trust OS and people.
Really? Instead of having just one tiny ro filesystem flag, you suggest to replace the disk and spend hundreds of dollars to have what linux has as a built in feature when dealing with mounting of filesystems?
Anyway, in such case I will have to trust the switch itself, and the people who designed it. Too many possibilities... With the ro flag, I know it will work the way I expect because I've been using it for the past decade. 
You could ask udevil devs to support configuration file includes from different directory than the one storing udevil.conf. From LibreElec perspective they need writable mounts and most of users will want their storage devices mounted in writable mode to manage media files in them. So LibreElec is unlikely to change default automounter configuration for you.
I've been using udevil for years, at least when that project was maintained. The last commit in the official git repo is dated 5 years back. Maybe LibreELEC should switch to some other well maintained alternative? It already uses systemd, and systemd is able to mount local filesystems. I'm pretty fluent with systemd, but I couldn't make it work with LibreELEC. Maybe this project should make some changes in this direction to support systemd local mounts? That would solve all the problems they are when it comes to mounting devices' filesystems.
Or start using iso9660 file system on your devices. That one is automated readonly.
I prefer using the ro flag.
When was the last time you had modern file systems corrupted by power outage? With data being lost.
A couple weeks ago, on my linux box, an ext4 filesystem got corrupted, and some files got damaged, which involved data lost.
Moreover, this Kodi media disk has a NTFS filesystem on it. I once got some power failure, and when I scanned the HDD under windows to fix errors, it removed bunch of the files stored on it.
So yes, filesystems can get damaged and it's a common issue no matter how modern filesystem is in use... I've never encountered such problems when I mount filesystems in read-only mode. So that's why when I know I won't be writing to some disk, I mount it's filesystem read-only just to save myself some troubles.
If you want to pay the price for your paranoia, rebuild libreelec with custom udevil config.
It's not paranoia -- every filesystem, which is mounted in read-write mode, can get damaged when power disappears. Mounting a filesystem as read-only is just a precaution.
It's weird that LibreELEC doesn't allow users to configure mount options of locally attached storage devices. Who should I molest to think about implementing such feature?
So is there no way to just mount the file system as read only?
I tried to use systemd service for it, but it doesn't look like this solution works for local drives which are handled by udevil. Is there a way to change the udevil config?
Is there a way to mount an external USB HDD drive as read only? The purpose of this is to protect the drive's filesystem from being corrupted on power outage. I don't really want to write to that drive and just read movies from it.