Remounting from read-only to read-write allows editing but prevents creating new files

[robspearman]

Repro steps (most recently tested on Rocky Linux 8, ntfs-3g-2021.8.22-2):

Become root user. File test.txt does not exist on NTFS partition at /dev/sdb1.

1. mount -t ntfs-3g -o ro /dev/sdb1 /mnt/disk
2. touch /mnt/disk/test.txt touch: cannot touch '/mnt/disk/test.txt': Read-only file system [this is expected]
3. mount -o remount,rw /dev/disk
4. touch /mnt/disk/test.txt touch: cannot touch '/mnt/disk/test.txt': No such file or directory

At this point you can edit existing files, just not create new ones. I expect to be able to create new files as is the case with other filesystem types.

[jpandre]

At this point you can edit existing files

Currently you cannot really update a file on a file system mounted as read-only and remounted as read-write, because of a security measure preventing from actually writing to the device. The updates are only effective in the cache, and after unmounting they are lost.

I expect to be able to create new files as is the case with other filesystem types.

This is currently not supported, by may be possible under some circumstances with a few caveats.

The Linux kernel does not inform ntfs-3g of the remounting, so ntfs-3g discovers the change when receiving requests such as create(2), mkdir(2), etc. on file systems supposed to be mounted read-only. On such requests it may be possible to recheck whether the file system is safe to be reopened read-write. There are however concerns about the cached data which have a much longer span on read-only mounts.

For some reason, when the device is a loop device, the remount starts a new ntfs-3g process which cannot modify the parameters of the existing one, so the remounting cannot be implemented. A similar behavior is also observed on a non-Linux kernel, even with block devices, and I cannot check the behavior on MacOS.

More investigation is needed.

[jpandre]

Some new developments on this :

This issue is caused by a weakness in fuse which affects all file systems based on fuse. See https://sourceforge.net/p/fuse/mailman/message/37679352/

Guessing from within ntfs-3g a change from read-only to read-write is sometimes late. It can also be unsafe, in particular when there are several concurrent read-only mounts.

The changes from read-write to read-only cannot be guessed that way, and the read-only state cannot be enforced. In particular the access time stamps cannot be frozen.

So, no glimpse of a reasonable fix until fuse notifies the remounting.

[robspearman]

Thanks for investigating. I don't see an existing issue on the libfuse github project about this?

[jpandre]

The issue is within the kernel side of fuse, not in libfuse (libfuse will however have to be upgraded when the remount notification is implemented).