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.
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.
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
note: there is also exfat which handles really large memory usb/sdcards etc. typically 128Gb or bigger.
requires exfatprogs to be installed.
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.
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 ):
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).
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
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
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.
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.
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 drivermount -t /dev/xxxx
- symlinked to default driverRegardless, using type 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
Any suggestions what’s missing?
I do appreciate any input. Thanks.
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 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.
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
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.
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.