Unable to mount fat or ntfs drives after updating

[misantroop]

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.

[soundofthunder]

@misantroop

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

You might find this information useful for future reference:

• [Primer] NTFS on Linux

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

[derk]

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

[Aragorn]

@soundofthunder

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

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

[soundofthunder]

@Aragorn

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

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.

[foko]

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):

Unable to mount fat or ntfs drives after updating

See if the following helps… sudo pacman -S ntfs-3g sudo bash -c 'echo "blacklist ntfs3" > /etc/modprobe.d/disable-ntfs3.conf' Reboot after the changes.

And then this one (it worked ):

After last update with manjaro-hotfix my system needs password for mount any devices

sudo nano /etc/polkit-1/rules.d/99-manjaro.rules and add the following: polkit.addRule(function(action, subject) { if (action.id.indexOf("org.freedesktop.udisks2.") == 0 && subject.isInGroup("wheel")) { return polkit.Result.YES; } }); polkit.addRule(function(action, subject) { if (action.id == "org.freedesktop.login1.power-off" || action.id == "org.freedesktop.login1.reboot" || action.id == "org.freedesktop.login1.hibernate" || action.id == "org.fr…

[cscs]

@foko

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

And then this one (it worked ):

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.

---

@foko

I got an error after trying to burn the latest Manjaro ISO to a USB stick using the program “disks”

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.

Burn an ISO File

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).

[philm]

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

[Kobold]

@philm

The kernel changed default ntfs driver from FUSE one to ntfs3.

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

@Stephix

Same issue with kernel 6.8.1-1-MANJARO for a microSD card with extfat file system (not encrypted).

sudo mount /dev/sdc1 /mnt/disk/
[sudo] Mot de passe de steph : 
FUSE exfat 1.4.0 (libfuse3)
fuse: mount failed: Device or resource busy

Journalctl message:

mars 21 18:45:31 steph-bureau udisksd[2183571]: fuse: mount failed: Device or resource busy
mars 21 18:45:31 steph-bureau udisksd[2183571]: FUSE exfat 1.4.0 (libfuse3)
mars 21 18:45:31 steph-bureau kernel: /dev/sdc1: Can't open blockdev

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

[medmedin]

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.

[megavolt]

@medmedin

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

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

@medmedin

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

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.

[medmedin]

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?

[soundofthunder]

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.

[raguse]

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.

[medmedin]

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.

[soundofthunder]

@medmedin

for apps which use mount command for multiple types it will break mounting NTFS devices with the new ntfs3 driver.

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.

[Stephix]

I don’t understand what the problem is!

Fuse, permissions…?

/etc/mtab doesn’t change between linux67 and linux68

gvfsd-fuse /run/user/1000/gvfs fuse.gvfsd-fuse rw,nosuid,nodev,relatime,user_id=1000,group_id=1000 0 0

But with linux68, pcmanfm gives on a laptop:

Error mounting /dev/mmcblk0p1 at /run/media/steph/0123-4567: Unknown error when mounting /dev/mmcblk0p1

[soundofthunder]

@Stephix

/etc/mtab doesn’t change between linux67 and linux68

gvfsd-fuse /run/user/1000/gvfs fuse.gvfsd-fuse rw,nosuid,nodev,relatime,user_

From post #44:
Migrate your mount options:

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

So, that seems to suggest changing your options from:

gvfsd-fuse /run/user/1000/gvfs fuse.gvfsd-fuse rw,nosuid,nodev,relatime,user_id=1000,group_id=1000 0 0

to something like:

gvfsd-fuse /run/user/1000/gvfs fuse.gvfsd-fuse rw,nosuid,nodev,relatime,uid=1000,gid=1000 0 0

See post #44 in this thread.

[Stephix]

Yes I red it and investigated…
I didn’t found the file concerned for a removable microSD (idem as an USB stick I suppose).
Not /etc/fstab, nor /etc/fuse.conf.

[cfinnberg]

Hi. For everyone having problems with an exfat unit, check that you have exfatprogs installed and not exfat-utils. I also was having problems until I found the (quite old, but unnoticed) explanation.