Fuse doesn’t mount Ntfs after testing update 16/03/2024.
Would you care to elaborate?
Have you considered removing the ntfs-3g package and allowing the superior kernel module (ntfs3) to do its job, as intended?
Don’t mind me asking
so you are saying that ntfs-3g (from Paragon) is worse than the one included in 6.6?
I tried to remove ntfs-3g and pac saying that it is needed for partition manager.
The ntfs3 kernel driver (module) was a replacement for the commonly used ntfs-3g usermode driver. Ntfs-3g is now only suggested as a quick-and-dirty workaround if ntfs3 refuses to mount an NTFS volume, due to a dirty bit being present.
Regrettably, many users simply choose to use ntfs-3g instead of correcting any damage indicated by the dirty bit. Ntfs3 actively prevents mounting of an NTFS volume until damage has been corrected, and the dirty bit is cleared. This is a security measure built in to ntfs3 that does not exist in ntfs-3g – indeed, ntfs-3g actively ignores the dirty bit; which means you will not know of any damage to the volume until it’s too late.
You may find [Primer] NTFS on Linux interesting reading when you find time.
Cheers.
2 Likes
Thank you for reply.
I know about superbit but i wonder if reports where people complain that ntfs is damaging their hdds are true (Ntfs3 keeps corrupting my ntfs partitons).
Sometime i need to copy data from ntfs drives.
That is why im curious.
Yes, that post seems like a classic example of a user blaming ntfs3 for not mounting the volume; which is true enough; however, rather than causing damage, ntfs3 is reporting the likelihood of damage by refusing to mount the volume.
A typical indicator is an error something like:
Wrong fs type, bad option, bad superblock
Usually, any damage is arguably superficial; perhaps as a result of an improper shutdown, etc; however, it should still be fixed (in a Windows environment using chkdsk). Again, ntfs-3g ignores the dirty bit, and by extension, also ignores any damage the dirty bit might have indicated.
Some people maintain that EXFAT would be preferable to NTFS – presumably, because they don’t wish to deal with maintenance of NTFS – however, NTFS is without doubt a superior (and journaled) filesystem. In my multiboot system, any NTFS volumes exposed to Linux have served me well for many years; and with no issues relating to ntfs3 since its inception (during 6.x kernels).
It should do no harm to leave ntfs-3g installed; it’s only used if ntfs3 has been manually blacklisted; it that’s the case, the blacklisting file (that you must mave created) only needs to be deleted for ntfs3 to again take precedence.
Leaving ntfs-g3 installed can also be handy to manually mount a volume, when needed, or for any other applications that might optionally use it.
1 Like
NTFS is - and for the foreseeable future - a closed source proprietary file system intended for Microsoft Windows.
For data exchange between systems exfat should be preferred as this is a genuine cross platform file system - and it became open source a few years back.
Never use NTFS for anything important on Linux.
ntfs-3g and ntfs3 It are reverse engineered file systems - they are not suitable for long term use with Linux.
3 Likes
Never use any foreign filesystem for anything important on Linux; that would be safer advice; though sometimes it can be difficult to avoid it.
Windows and Linux can both read exfat, so any data sharing is a breeze with this as stated above.
While it’s nice to banter and express personal opinions of which filesystem to use, we’re yet to see any clarification from the OP beyond their original post regarding the issue they are experiencing.
Aside:- Data sharing is a breeze with NTFS also. More importantly, with NTFS there is a chance to recover data, if needed; with EXFAT, that option does not exist. This is one of the reasons long term storage (or storage of important data) is not recommended on EXFAT. In that respect NTFS is the better choice; though a native Linux filesystem is always preferable wherever possible.
1 Like
Appreciate your answer and wisdom.
Copy files from NTFS Partition and insert to a Linux Partition shouldn’t be the problem anyways.
Because it is just reading the file from the NTFS partition… the problem comes when you delete/move/paste/modify something inside the NTFS Partition.
1 Like
Everyone does his own assumptions here. Ntfs mounting is important for various iso images, you cannot just drop Ntfs. Nothing is wrong with the physical drives and the mounting fails with Timeout and only with Fuse. Also Ntfs-3g is an important dependency and no Kernel Ntfs is blacklisted. Is there a way to blacklist Ntfs-3g?
You could uninstall ntfs-3g, as it’s a userland package.
The Ntfs3 driver, on the other hand, is not a package (it’s a kernel module which can not be uninstalled in that way).
If I understand your issue properly, with the minimal information you have provided, the mount failure is happening only with ntfs-3g. Uninstalling ntfs-3g should immediately allow the kernel driver (ntfs3) to take precedence when mounting your NTFS volume.
Note that mounting using ntfs3 will only fail (with an error) if the volume is damaged (if the dirty bit is present). Otherwise, your volume should mount as expected.
I hope this helps. Cheers.
Can you give us some details? I never heared about that.
I wrote above that Ntfs-3g is a dependency to apps like Testdisk. You are a distro so just remove it your self or give priority to the Ntfs Kernel Driver. Is there a way to do that my self?
If ntfs-3g is required as a dependency for some tools such as testdisk, then it can remain installed.
For ntfs-3g to be the default filesystem driver for NTFS, the ntfs3 kernel driver must first have been blacklisted – If you have never blacklisted ntfs3, then ntfs3 already has priority.
Please post the commands used that generate the errors; and also the exact error message(s) displayed.
I’ve also noticed that the NTFS drive setup that I had within my fstab has stopped working after this update (not sure if it’s kernel or an update elsewhere).
UUID=3A8CA977375BBB18 /mnt/Data ntfs-3g nosuid,nodev,nofail,x-gvfs-show,uid=1000,gid=1000 0 0
The above entry used to work perfectly fine, but now I’ve had to comment it out and I don’t know what it needs to be to make it work again as I use it for a steam library and now it can’t find it at all.
If I go into Files->Other Locations->Data it works now. This drive is a different physical drive which is why I am using the UUID above.
If I leave the fstab entry in, it will not mount the drive saying that “the device is busy”. If I remove it, it will mount ok.
How can I reconstruct it so I don’t need to go into files and mount it where it asks for an admin password, but it should mount automatically using fstab in the place I want it to mount?
Some quick possibilities:
- The UUID has changed (if it has been reformatted)
- You should use the default
ntfs3kernel driver instead ofntfs-3g- this assumes thatntfs3has not been blacklisted by you.
I did go with the flow that the 3G driver is the problem. But after testing WoeUsb-Ng with Ntfsprogs as dependency, it might me the kernel driver after all. I’m thinking potential disaster here.