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”.
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).
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
# 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.
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?
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, usingtype takes minimal exertion; and I prefer it.
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
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.
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 mountmounts 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.
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.
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.