udisks 2.9.4 and ntfs3: unable to mount NTFS partition

[tgurr]

udisks is unable to mount a NTFS partition with kernel 5.15 trying to make use of the new ntfs3 kernel driver. While manually mounting via

mount -t ntfs3 /dev/sdb5 /mnt/music

works:

/dev/sdb5 on /mnt/music type ntfs3 (rw,relatime,uid=0,gid=0,iocharset=utf8)

udisks does not.

Terminal:

LC_ALL="C" udisksctl mount -b /dev/sdb5
Error mounting /dev/sdb5: GDBus.Error:org.freedesktop.UDisks2.Error.Failed: Error mounting /dev/sdb5 at /run/media/tgurr/Daten: unknown filesystem type 'ntfs3,ntfs'

Dolphin:

These errors happen after I uninstalled the FUSE userspace driver/package ntfs-3g_ntfsprogs. If I install it again udisks mounts the NTFS partition with no errors, but uses the FUSE driver instead of ntfs3:

/dev/sdb5 on /run/media/tgurr/Daten type fuseblk (rw,nosuid,nodev,relatime,user_id=0,group_id=0,default_permissions,allow_other,blksize=4096,uhelper=udisks2)

which it shouldn't.

Additional info:

$ mount --version
mount aus util-linux 2.37.2 (libmount 2.37.2: btrfs, namespaces, assert, debug)

[tgurr]

Looks like it's related to the windows_names mount option already mentioned in the comments of the pull request #917 (comment). If I create the file /etc/udisks2/mount_options.conf and copy over the lines from the example minus the windows_names mount option

[defaults]
ntfs_defaults=uid=$UID,gid=$GID
ntfs_allow=uid=$UID,gid=$GID,umask,dmask,fmask,locale,norecover,ignore_case,compression,nocompression,big_writes,nls,nohidden,sys_immutable,sparse,showmeta,prealloc

udisks is able to mount the partition with ntfs3

/dev/sdb5 on /run/media/tgurr/Daten type ntfs3 (rw,nosuid,nodev,relatime,uid=1000,gid=1000,iocharset=utf8,uhelper=udisks2)

[tbzatek]

Yes, this is expected. The kernel ntfs3 driver has changed how unknown mount options are handled, now returning an error. So the udisks functionality is back as it used to be, requiring either the legacy ntfs kernel driver or handling this via fuse.

See also #917 (comment)

Either the kernel ntfs3 maintainers should clean up their mess or an extra workaround in udisks would need to be put in place. There's a large discrepancy in the concept of filesystem signature and kernel filesystem driver name.

[tgurr]

Problem is like this the new filesystem is pretty much useless, at least on the desktop for regular users not being able to mess with fstab and trying to make use of the convenient udisks usage of modern desktops.

Either the kernel ntfs3 maintainers should clean up their mess or an extra workaround in udisks would need to be put in place. There's a large discrepancy in the concept of filesystem signature and kernel filesystem driver name.

I suppose if noone reports a bug upstream to clarify the situation, preferrably someone like you involved in the userspace and the internals and how to handle these edge cases and point out this change is a real issue then this will go nowhere. Would be nice to see this worked around in udisks for the time being as 5.15 is now released as it is, can't udisks be changed to only check for and apply the windows_names mount option for != ntfs3 filesystems / mount actions?

[tbzatek]

Problem is like this the new filesystem is pretty much useless, at least on the desktop for regular users not being able to mess with fstab and trying to make use of the convenient udisks usage of modern desktops.

Yes, I agree. Same situation for existing /etc/fstab records and users or scripts calling the mount command. They all fail here since the detected ntfs signature doesn't match the required ntfs3 filesystem driver name.

I suppose if noone reports a bug upstream to clarify the situation, preferrably someone like you involved in the userspace and the internals and how to handle these edge cases and point out this change is a real issue then this will go nowhere. Would be nice to see this worked around in udisks for the time being as 5.15 is now released as it is, can't udisks be changed to only check for and apply the windows_names mount option for != ntfs3 filesystems / mount actions?

Yes, a discussion with the kernel maintainers will be needed to get some guarantees before proceeding with any kind of workarounds in udisks.

The primary problem here is to detect which driver gets used and which mount options should be used. Right now the default mount options in udisks are tied to the filesystem signature. That was not a real problem so far, even for the exfat case where three different drivers were used over time (even though short-lived).

Existing mount options for the ntfs filesystem type were selected to reach a degree of safety, E.g. the windows_names option is important in terms of compatibility and interoperability between different platforms. So that needs to stay as it is.

Another concern to deal with is an eventual driver rename from ntfs3 back to ntfs. We need to know which implementation is actually used and what mount options to supply.

Same situation for removed or deprecated mount options, the filesystem driver should retain backwards compatibility. It was not a real problem with any filesystem driver until now.

[marcosfrm]

https://lore.kernel.org/ntfs3/CAC=eVgQKOdNbyDf2Qf=O9SnG=6nAGZ-nyuwOosf7YW5R3xbVLw@mail.gmail.com/

Did not help unfortunately.

[jackghg]

so, is it fixed now ?

[marcosfrm]

Nope.

[jackghg]

So the choice is either wait for the kernel and all the distros to fix this or add a line to the default config ?

[jackghg]

I saw this: https://www.phoronix.com/scan.php?page=news_item&px=EXT4-New-Mount-API-Usage
is this related to the delay of the fix ?

[tbzatek]

Please stick to the ntfs-3g for now, it is a proved and stable solution.

[tbzatek]

So to get things moving, here's a quick summary what needs to be done. No timeframe though, we're rather busy with other stuff.

• fs: Return BD_FS_ERROR_NOFS on unknown filesystem libblockdev#687
• mount options: Differentiate between filesystem signature and filesystem driver #945
• poke util-linux to add some mount dry-run (via the new kernel mount API?) or other way of guessing what filesystem driver will be used
• the actual hack, or a clean solution in case of mount option definition priorities are implemented

[jackghg]

Do you really want to wait a year for someone to "Differentiate between filesystem signature and filesystem driver" ???
Any why anyway ? if the partition is ntfs (new or old signiature) and if the kernel >= 5.15 it uses the new drivers, where is the problem ?

[vinceFR7528]

pour remplacer ntfs-3g par le module ntfs3 du kernel >=5.15
vérifier que le module ntfs3 est présent par la commande modinfo ntfs3

1. montage automatique d'une partition ntfs
   le problème vient du fait que udisks utilise par défaut l'option "windows_names" et que le module ntfs3 ne comprend pas cette option donc udisks se retourne vers ntfs-3g pour faire le montage

il suffit de supprimer l'option "windows_names" pour que le module ntfs3 fonctionne, pour cela en tant que root éditer et corriger le fichier /etc/udisks2/mount_options.conf
s'il n'existe pas le créer par la commande suivante :
cat >>/etc/udisks2/mount_options.conf <<EOF
[defaults]
ntfs_defaults=uid=\$UID,gid=\$GID
EOF

optionnellement supprimer le package ntfs-3g, s'il n'a pas de dépendance

2. montage manuel avec la commande "mount" automatique donc sans l'option -t ntfs3
   en tant que root il faut créer le fichier /usr/sbin/mount.ntfs par la commande
   cat >/usr/sbin/mount.ntfs <<EOF
   #!/bin/sh
   exec mount -t ntfs3 "\$@"
   EOF
   chmod 755 /usr/sbin/mount.ntfs

Et voilà!

-- English
to replace ntfs-3g with the ntfs3 kernel module >=5.15
check that the ntfs3 module is present with the modinfo ntfs3 command

1. automatic mounting of an ntfs partition
   the problem comes from the fact that udisks uses the "windows_names" option by default and that the ntfs3 module does not understand this option so udisks turns to ntfs-3g to do the mount
   just remove the "windows_names" option for the ntfs3 module to work, for that as root edit and correct the file /etc/udisks2/mount_options.conf
   if it does not exist, create it with the following command:
   cat >>/etc/udisks2/mount_options.conf <<EOF
   [defaults]
   ntfs_defaults=uid=\$UID,gid=\$GID
   EOF

optionally remove the ntfs-3g package, if it has no dependency

2. manual mounting with the automatic "mount" command so without the -t ntfs3 option
   as root you must create the file /usr/sbin/mount.ntfs by the command
   cat >/usr/sbin/mount.ntfs <<EOF
   #!/bin/sh
   exec mount -t ntfs3 "\$@"
   EOF
   chmod 755 /usr/sbin/mount.ntfs

Et voilà!

[Polynomial-C]

Come on guys, please give us at least something to play/test with. Mark it experimental and/or hide it behind some configure option that is default disabled, but please give us something.

[AlexFolland]

Please keep begging for volunteers to work for you out of issue tickets.

[Polynomial-C]

Believe me, if I could give you that kind of resource, I'd do it right away.

[jackghg]

You are right, this should have been done in a week, its incredible its taking so much time. i understand that udisks should be stable and clean but its taking too much time.

[tbzatek]

Some news floating around: https://lore.kernel.org/lkml/da20d32b-5185-f40b-48b8-2986922d8b25@stargateuniverse.net/

Whatever this kernel story ends up with, the current plan for differentiating filesystem signature and filesystem driver name still stands, it's an important piece of functionality that will keep us prepared for similar situations with inconsistent driver names in the future.

If somebody still wants to experiment with ntfs3 on their own risk, the possibility to override default mount options was there since the 2.9.0 release: http://storaged.org/doc/udisks2-api/latest/mount_options.html, see also #932 (comment).

[vinceFR7528]

or just read my post above #932 (comment)

[jackghg]

will it work without ntfs3 now ? at next release ?

[vinceFR7528]

Yes, it's ok now.

[jackghg]

ok, thanks guys ! it will take some time before it reaches a distro i guess...

[vinceFR7528]

I actually tested the latest update on Arch Linux 5.15.55-2-lts distro with ntfsprogs-ntfs3 package which modified /usr/sbin/mount.ntfs, after removing the ntfs_defaults patch in /etc/udisks2/mount_options.conf, so it's already at least in a distro and in the kernel. Isn't it?

[jackghg]

I actually tested the latest update on Arch...

I know there are workarounds but id rather wait for the new version...

[Firestar-Reimu]

will ntfs3 support windows_names option or that should be deprecated?

[tbzatek]

will ntfs3 support windows_names option or that should be deprecated?

That's a question for the kernel driver maintainers. No need to deprecate anything in UDisks, ntfs and ntfs3 are separate filesystems and with the linked change above the option sets are separate as well.

[HanabishiRecca]

Paragon-Software-Group/linux-ntfs3@1d07a9d