Bug 2182206

That's the desired behaviour I'd say. It was set to work this way but then ntfs3 kernel developers changed the way unknown mount options are handled so mount falled back to ntfs-3g. With the kernel 6.2 ntfs3 developers introduced the missing kernel option so that mount now succeeds. We've removed the use of that mount option upstream in the meanwhile, so future udisks releases will do the mount slightly differently. All these changes because of instability of mount options handling in the kernel ntfs3 driver.

In any case ntfs3 is considered stable and been outside of the staging area for some time.

The upcoming UDisks 2.10.0 release (Fedora 39+) will provide a way to set filesystem driver preference for mounting.

Thanks for the explanation. If ntfs3 is to be used by default in the future, would it be better to stop linking /sbin/mount.ntfs to ntfs-3g in Fedora? It has been a bit confusing that auto-mounting and the `mount` command use different drivers.

(In reply to hujq from comment #2)
> Thanks for the explanation. If ntfs3 is to be used by default in the future,
> would it be better to stop linking /sbin/mount.ntfs to ntfs-3g in Fedora? It
> has been a bit confusing that auto-mounting and the `mount` command use
> different drivers.

That's provided by ntfs-3g. I expect to remove this dependency once UDisks 2.10.0 is released and packaged in Fedora.

However, please bear in mind that the ntfs3 kernel driver name means 'ntfs3' filesystem type. Once you remove ntfs-3g, there won't be any /sbin/mount.ntfs and `mount -t ntfs` will fail (unless Fedora kernel still ships the legacy ntfs kernel driver which doesn't seem to be the case). There are three different ntfs filesystem drivers available at the moment.

$ grep NTFS /boot/config-6.1.14-200.fc37.x86_64 
# CONFIG_NTFS_FS is not set
CONFIG_NTFS3_FS=m
# CONFIG_NTFS3_64BIT_CLUSTER is not set
CONFIG_NTFS3_LZX_XPRESS=y
CONFIG_NTFS3_FS_POSIX_ACL=y

The problem with using ntfs3 as default is that there is an issue with permissions for existing folders. Mounting a usual Windows drive results in a bunch of read-only folders, including Documents or Downloads, which one could expect to share and edit from Linux:
https://www.reddit.com/r/archlinux/comments/r325t3/permissions_problems_with_the_new_ntfs3_driver/
In particular, I can no longer sync my keepass database which I store on in Users/$user/Documents. With ntfs-3g it was working as expected. This is not something which should change in the middle of a release.

(In reply to Julian Sikorski from comment #4)
> The problem with using ntfs3 as default is that there is an issue with
> permissions for existing folders. Mounting a usual Windows drive results in
> a bunch of read-only folders, including Documents or Downloads, which one
> could expect to share and edit from Linux:
> https://www.reddit.com/r/archlinux/comments/r325t3/
> permissions_problems_with_the_new_ntfs3_driver/
> In particular, I can no longer sync my keepass database which I store on in
> Users/$user/Documents.

UDisks comes with default set of mount options for each filesystems. E.g. the uid= and gid= options are passed in according to the user that trigerred the mount.
See https://github.com/storaged-project/udisks/blob/master/data/builtin_mount_options.conf
If there's any option that we should add (and that is backwards compatible with all previous kernels) we can do that.
Note that e.g. the "windows_names" cannot be added by default for ntfs3 as it would cause failure with earlier kernel versions.

> With ntfs-3g it was working as expected. This is not
> something which should change in the middle of a release.

Understood, this has been trigerred by the kernel update (6.1 -> 6.2). You may opt for blacklisting the ntfs3 kernel module as a workaround.

According to the reddit post I linked and my experiments back when I first tried ntfs3, there is no option which would help. According to the reddit post, chown and chmod fix the issue but this should not be a requirement imo and I am a bit too worried of unforseen consequences. I even emailed Konstantin back in November 2021 about this but got no response. This was in 5.15 timeframe. In April 2022 there were some discussions about the driver being effectively orphaned. Is it actually maintained these days? And if so, where can I report my issue so that is actually fixed or at least acknowledged? Blacklisting ntfs3 forever is not really a solution.

> there is no option which would help

`noacsrules` works for me. Without it I can't write to Documents and Downloads folders in a Windows 11 filesystem, and with it there's no problem with writing. Strangely the permissions of these folders are shown as `dr-xr-xr-x` in both cases, and the owner:group is the user mounting it.

I just added `noacsrules` to both `ntfs_defaults` and `ntfs_allow` in `/etc/udisks2/mount_options.conf`, and the used mount options are now (rw,nosuid,nodev,relatime,uid=1000,gid=1000,iocharset=utf8,windows_names,noacsrules,uhelper=udisks2)

I'm not sure if it's backward compatible or if there are other unwanted effects of this option, like making everything writable for other users too or breaking the permissions in Windows.

> If there's any option that we should add (and that is backwards compatible with all previous kernels) we can do that.
> Note that e.g. the "windows_names" cannot be added by default for ntfs3 as it would cause failure with earlier kernel versions.

In that case, would it be able to fallback to ntfs-3g like it does now?

I remember trying noacsrules back in 5.15 timeframe and it not helping. I can test again. Having said that, the option seems on the way out:
https://github.com/Paragon-Software-Group/linux-ntfs3/commit/267a36ba30a7425ad59d20e7e7e33bbdcc9cfb0a

I tested noacsrules on a different machine with kernel 6.2.9 and it does appear to work:
$ sudo mount -t ntfs3 -o defaults,noacsrules /mnt/windows
$ mount | grep ntfs
/dev/nvme0n1p4 on /mnt/windows type ntfs3 (rw,relatime,uid=0,gid=0,iocharset=utf8,noacsrules)
$ touch /mnt/windows/Users/xxx/Documents/test
no error

I have now tried the approach mentioned in comment #7 and I am happy to report it works as well.

(In reply to Julian Sikorski from comment #8)
> I remember trying noacsrules back in 5.15 timeframe and it not helping. I
> can test again. Having said that, the option seems on the way out:
> https://github.com/Paragon-Software-Group/linux-ntfs3/commit/
> 267a36ba30a7425ad59d20e7e7e33bbdcc9cfb0a

Oh well, thanks for the heads-up! This rules out adding 'noacsrules' to the default set of options. In fact, seeing this, it only reassures the need to keep the default options to minimum.

(In reply to hujq from comment #7)
> > If there's any option that we should add (and that is backwards compatible with all previous kernels) we can do that.
> > Note that e.g. the "windows_names" cannot be added by default for ntfs3 as it would cause failure with earlier kernel versions.
> 
> In that case, would it be able to fallback to ntfs-3g like it does now?

No, it will return error when the filesystem is available. We don't want to silently fall back to a different driver when higher-priority one is available yet fails for some reason. The current behaviour in UDisks 2.9.x was just a temporary hack.

Note there are multiple reports of data corruption, apparently caused by ntfs3.ko,
therefore caused by this switch of the default.  See:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/2DNJUQOP3M264GKTLCC5MGG7T6ZFEOJV/

Ouch, thanks for bringing this up, we don't watch the particular filesystem driver issues out there. I've heard various complaints about ntfs3 and I think I heard equal number of complaints against ntfs-3g. From upstream perspective supporting new filesystem drivers that are out of staging is the suggested approach forward while distributors still have freedom of choice of their own.

Quick stroll over Google and various forums, my impressions about ntfs3:
 - NTFS compression looks like a problem
 - dirty bit, needs a "force" mount option that we intentionally don't want to support in udisks, resulting in a readonly mount
 - hibernated Windows OS with the filesystem accessed in the meantime would lead to corruption after resume
 - ACL issues described above

We still have a couple of weeks to switch back to ntfs-3g for F39 if we wanted to. Thoughts?

ntfs-3g will refuse to mount hibernated Windows disks:
https://github.com/tuxera/ntfs-3g/blob/75dcdc2cf37478fad6c0e3427403d198b554951d/libntfs-3g/volume.c#L96
(see also the ntfs-3g(8) man page notes).  This is a pain to deal with,
but very necessary as there is no conceivable way to "replay" the hibernation
data without Windows.

Apart from that we've found ntfs-3g to be excellent, and we regularly use
it with customers (see virt-v2v) with no corruption issues found.

I do not have any experience with ntfs3.ko, but would be reluctant to support
it with virt-v2v given the hearsay reports I've read online.

It also does not appear that the maintainer(s) are particularly responsive:
https://lore.kernel.org/ntfs3/edcd6eb8-8682-6552-a5f6-584ac103d0e9@gmail.com/T/#u
I have also emailed Konstantin about this very issue back in November 2021 but I got no response either.

Given that I am seeing this problem on two separate dual-booting machines, it does not look like a configuration problem. And given that accessing the Windows drive when dual-booting is not really an edge case, going back to ntfs-3g would be reasonable IMO.

(In reply to Julian Sikorski from comment #15)
> It also does not appear that the maintainer(s) are particularly responsive:
> https://lore.kernel.org/ntfs3/edcd6eb8-8682-6552-a5f6-584ac103d0e9@gmail.com/
> T/#u
> I have also emailed Konstantin about this very issue back in November 2021
> but I got no response either.

Looks like a https://github.com/storaged-project/udisks/issues/1126 that I have no clue so far how to fix.