Unable to mount fat or ntfs drives after updating

Support
33

You are getting it wrong.

If the disk(s) are in a unclean state - then Windows is not shut down completely - thus leaving the file systems in a so-called ‘dirty’ state.

Depending in the driver in use - kernel driver ntfs3 vs user-land ntfs-3g the system may refuse to load the file system - caused by the ‘dirty’ state.

This is not a flaw in the kernel - it is a security measure - much in the same sentiment which causes btrfs to refuse to write to a filesystem with errors - a measure designed to not alter data beyond repair.

So it is not a fault caused by an update - it is a fault caused by an improper Windows shutdown - a shutdown which is not improper from a Windows perspective but a fault caused by you - the user - trying to access a foreign file system which cannot be opened for rw.

34

The point is that the introduction of the ntfs3 module was in to the Linux kernel.
So regardless of the other foundations of the statements here the idea of laying blame on Manjaro was doubly (if not triply, etc) misguided.

1 Like
35

This won’t hinder Windoze to mark the FS dirty when hibernating (instead of shutting down)!

36

Yes, but it would mount them read-only. That’s an important nuance.

Also, the reason why ntfs3 is the default nowadays is that it’s GPL’d, and therefore it’s in the kernel. ntfs-3g is licensed differently, and the GPL forbids inclusion in the kernel because the license for ntfs-3g is not compatible with the GPL — just as in the case of zfs.

37

This broke my installation, had to timeshift restore.

Also same issue here. Checked the drive on a Windows machine, it was removed properly and not in a dirty state.

38

You might find this information useful for future reference:

Otherwise, I dare say the current thread has passed its use-by-date; and is deserving of some closure… @Aragorn

2 Likes
39

note: there is also exfat which handles really large memory usb/sdcards etc. typically 128Gb or bigger.
requires exfatprogs to be installed.

40

I would agree, but seeing as there appears to be a renewed interest in this thread, let’s see where it goes… :wink:

1 Like
41

Fair comment; and perhaps the closure is premature. Either that or I’ve had my fill of NTFS for a time, due to writing the aforementioned primer. :man_shrugging:

2 Likes
42

The same happened to me after upgrading.
I realize this after trying to mount a NTFS drive in Pcmanfm.
I also had another problem, I got an error after trying to burn the latest Manjaro ISO to a USB stick using the program “disks”.

So I tried this solution (didn’t work):

And then this one (it worked :smile:):

43

These are different problems/solutions.

The first one swaps ntfs3 module for ntfs-3g.

The second one duplicates deprecated functionality (certain polkit rules) from a discontinued package.

Some methods are more supported than others.

I wouldnt suggest Rufus.

I dont think unetbootin would work.

But imagewriter, ventoy, and dd should all work, among others.

Yes the wiki suggests rufus for windoze, I have no idea why, especially considering the dev of rufus at one time actively sabotaged manjaro ISOs (maybe still does, I wouldnt know, because I dont usually keep tabs on garbage). :person_shrugging:

44

The kernel changed default ntfs driver from FUSE one to ntfs3.
These two are not fully compatible, mainly as far as mount options go. If you have custom mount options in the fstab (or any other application, such as VeraCrypt) they need to be changed.

Symptoms:
Mount fails with: Device or resource busy
DMESG reports: Can't open blockdev

Solution:
Migrate your mount options:

  • allow_other → umask=000
  • default_permissions → [drop]
  • user_id=1000 → uid=1000
  • group_id=1000 → gid=1000
4 Likes
45

Are you sure its only related to ntfs? Someone used exfat and had this mounting errors too.

I hope i don’t run into errors, with my Veracrypt exfat :thinking:

46

This problem of failing to mount NTFS started with kernel 6.8, and according to Arch wiki, ntfs3 requires the file system type to mount.

So in /etc/fstab I simply changed type from auto to ntfs3 and all my NTFS partitions auto-mounted at boot,

Changed

/dev/disk/by-uuid/0A36AFE336AFCE4F /mnt/0A36AFE336AFCE4F auto defaults,nofail,x-gvfs-show,x-gvfs-name=C 0 0

to

/dev/disk/by-uuid/0A36AFE336AFCE4F /mnt/0A36AFE336AFCE4F ntfs3 defaults,nofail,x-gvfs-show,x-gvfs-name=C 0 0

but I don’t know how to handle external NTFS pluggable USBs.

I tried adding udev rule to set ntfs3 as the default driver but it doesn’t work.

And because Kernel 6.9 will completely remove ntfs-3g, it needs adjusting many things to adopt the new modifications.

Edit:
Even some apps like KDE Partition Manager and Gnome Disks fail to mount an unmounted NTFS partition with kernel 6.8.

1 Like
47

File: /etc/udisks2/mount_options.conf

# define order of filesystem driver priorities for the actual mount call,
# required definition for non-matching driver names
ntfs_drivers=ntfs3,ntfs

Examples: /etc/udisks2/mount_options.conf.example

And no, they remove the old old ntfs legacy driver which read-only support and not ntfs-3g. This ntfs driver is kernel driver right, but ntfs-3g is not, it is a userspace driver on top of fuse. It will still be there, just symlinked to ntfs as alias.

3 Likes
48

Seems adding /etc/udisks2/mount_options.conf worked for extenal USBs, and also mounting NTFS partitions using udisksctl.

But mount command still require specifying mount -t ntfs for it to work. Is there any hack to make it work without specifying type, like how it’s done on kernel 6.7?

49

Specifying the filesystem type seems like good practice to me rather than relying on internal guessing. If one, for example, has ntfs-3g installed then specifying the type obviously allows to choose the driver to use to mount a particular device; although, I suppose it could be optional, and dependent otherwise on whichever driver is default.

  • mount -t ntfs3 /dev/xxxx - kernel driver (module)
  • mount -t ntfs-3g /dev/xxxx - user mode driver (package)
  • mount -t ntfs /dev/xxxx - symlinked to default driver
  • mount -t /dev/xxxx - symlinked to default driver

Regardless, using type takes minimal exertion; and I prefer it.

2 Likes
50

Does anyone know how to tell veracrypt application to mount a NTFS container correctly with kernel 6.8 (not via fstab)?

  • I tried to pass on some mount parameters suggested here in the configuration of veracrypt settings or when mounting manually and so far no luck mounting it. I can mount it read-only with ntfs-3g.

  • Also when removing ntfs-3g package it says ´unknown filesystem type ntfs´ with of course /dev/loop0: Can't open blockdev

Any suggestions what’s missing?

I do appreciate any input. Thanks.

51

Specifying the type as a user is acceptable, but for apps which use mount command for multiple types it will break mounting NTFS devices with the new ntfs3 driver.

If no -t option is given, or if the auto type is specified, mount will try to guess the desired type. Mount uses the blkid or volume_id library for guessing the filesystem type; if that does not turn up anything that looks familiar, mount will try to read the file /etc/filesystems, or, if that does not exist, /proc/filesystems.

52

But, will it? An app using mount (as you quote suggests) will use blkid or the other methods mentioned, sequentially, to guess the filesystem.

Does blkid rely on the filesystem type name given by the driver, or does it reference the predefined fstype names internally, such as ntfs for example?

If the latter, then all an app must do is: read “ntfs” from blkid, and request that mount mounts the NTFS volume using the default NTFS filesystem driver (whether that be ntfs3, ntfs-3g or duck_soup); effectively what mount does already, unless I’m mistaken.

If I am mistaken, then I suppose appropriate symlinks should remedy the situation in lieu of apps that haven’t yet caught up.

I don’t think the ntfs3 kernel module is the villain.