[SUGGESTION] Remove ntfs-3g from the repository

lpr1 · 2026-08-03 10:50:25

Since ntfs support is now part of the linux kernel itself, I am suggesting removal of the ntfs-3g.

As an person who does not follow linux kernel developement very closely, I wasn't aware of the fact mentioned above. In last 1-2 (or more?) years or so, my NTFS partition kept getting corrupted periodically when writing to it. Removed ntfs-3g, no longer have any corruptions since.

If this idea is considered bad, or that there are some use cases where ntfs-3g can still get useful (idk?), maybe at least mentioning it on the https://wiki.archlinux.org/title/NTFS-3G page, warning users about potential corruption issues and so on?

PS: It can always be part of AUR.

Last edited by lpr1 (2026-08-03 10:54:18)

Lone_Wolf · 2026-08-03 11:13:31

There are actually 2 kernel drivers for NTFS one of which has been present for years already.

The ntfs-3g driver is a FUSE (Filesystem in Userspace) driver which function differently then kernel drivers.
Personally I have better xp with ntfs-3g then with ntfs3 . Haen't tried the ntfs one yet as it is very new.

Moderator Note
moving to Applications & Desktop Environments

Last edited by Lone_Wolf (2026-08-03 11:14:17)

lpr1 · 2026-08-03 12:02:26

Lone_Wolf wrote:

There are actually 2 kernel drivers for NTFS one of which has been present for years already.
The ntfs-3g driver is a FUSE (Filesystem in Userspace) driver which function differently then kernel drivers.
Personally I have better xp with ntfs-3g then with ntfs3 . Haen't tried the ntfs one yet as it is very new.
Moderator Note
moving to Applications & Desktop Environments

Alright, but now (or for few years already) kernel drivers work in userspace out of the box. So, then, maybe posting a warning on ntfs-3g, I honestly thought my drive was bad because of all the corruption it caused for me.

So maybe add it to the https://wiki.archlinux.org/title/NTFS-3G , some sort of information/warning, because afterwards I did read on multiple posts users experiencing same issue (corruption) with ntfs-3g.

seth · 2026-08-03 12:11:24

but now (or for few years already) kernel drivers work in userspace

No and no.
Kernel drivers don't work in userspace, they work in kernel space - and the ntfs drivers in the kernel have been outright slapstick and you'd have been w/o NTFS writing support for a while even during the recent years.

Speaking of which: FS corruption from NTFS writes will happen because
a) the FS is still open (not properly umounted/released on windows or esp. because of windows fast-start, 3rd link below) - ntfs-3g is simply more lenient in still allowing write access to those, but you *have* to make sure to never re-open any filesystem anywhere
b) the filesystem not being properly synced before the drive loses power (during shutdown or because you just yanked it from the system)

If you have references for systematic writing bugs in NTFS-3G it will be necessary to cite them (here but more importantly on the wiki) - "I recall having read reports that this is maybe a thing in more cases" is simply FUD.

V1del · 2026-08-03 12:27:41

Most often the problem with ntfs-3g is speed as it is in userspace. Writing corruption has never been an issue here in the last 17 years of using NTFS with this driver. ntfs3 had lots of corruption issues when it first got introduced 5 years ago those stabilized somewhat after a year or so, but still scary warnings occasionally depending on what it read where. I am driving the new ntfs driver now and haven't noted anything off so far.

But to the point I can't say I had more corruptions with ntfs-3g so maybe something more quantifiable would help. And the mount helper situation is quite special with that package installed, so it's even possible that depending on how you were mounting your drive that it even picked ntfs3 instead of ntfs-3g and simply a change in the mount symlink presence after removing ntfs-3g might have made it use the newer ntfs instead of ntfs3 or so...

cryptearth · 2026-08-03 14:01:35

no matter the driver: writing onto ntfs from linux is just wrong - and everybody doing it deserves issues
in difference to exFAT the specs of ntfs were never made public and every driver except microsofts own is based on reverse enegineering
aside from that the complex NT security is way too different from rather simple posix - hence ntfs acl are way different from posix simple user/group/other read/write/execute

if you want to exchange data either use network protocols likt http or ftp - or FAT/exFAT

Tiikerihai · 2026-08-03 14:19:38

NTFS3 cannot be used to safely write NTFS drives, I know from experience that this causes massive corruption over time. I discovered widespread file corruption after about 1 year. NTFS drives on Linux should only ever be mounted RO unless the data on them is worthless to you. By the way, in my case I only used the drive with Windows PE and Linux, never in an actual Windows install. So the corruption I got was exclusively from Linux driver.

Last edited by Tiikerihai (2026-08-03 14:22:47)

lpr1 · 2026-08-04 02:13:13

seth wrote:

but now (or for few years already) kernel drivers work in userspace
No and no.
Kernel drivers don't work in userspace, they work in kernel space - and the ntfs drivers in the kernel have been outright slapstick and you'd have been w/o NTFS writing support for a while even during the recent years.
Speaking of which: FS corruption from NTFS writes will happen because
a) the FS is still open (not properly umounted/released on windows or esp. because of windows fast-start, 3rd link below) - ntfs-3g is simply more lenient in still allowing write access to those, but you *have* to make sure to never re-open any filesystem anywhere
b) the filesystem not being properly synced before the drive loses power (during shutdown or because you just yanked it from the system)
If you have references for systematic writing bugs in NTFS-3G it will be necessary to cite them (here but more importantly on the wiki) - "I recall having read reports that this is maybe a thing in more cases" is simply FUD.

Ok, but you get what I wanted to say, there's no special requirement in userspace anymore for kernel drivers, it works out of the box. Understood.

V1del wrote:

Most often the problem with ntfs-3g is speed as it is in userspace. Writing corruption has never been an issue here in the last 17 years of using NTFS with this driver. ntfs3 had lots of corruption issues when it first got introduced 5 years ago those stabilized somewhat after a year or so, but still scary warnings occasionally depending on what it read where. I am driving the new ntfs driver now and haven't noted anything off so far.
But to the point I can't say I had more corruptions with ntfs-3g so maybe something more quantifiable would help. And the mount helper situation is quite special with that package installed, so it's even possible that depending on how you were mounting your drive that it even picked ntfs3 instead of ntfs-3g and simply a change in the mount symlink presence after removing ntfs-3g might have made it use the newer ntfs instead of ntfs3 or so...

That's interesting you've mentioned speed, that might be the reason why people (including me) are experiencing corruptions when doing everything from file manager (mount, unmount, write etc.), while both software and led indicator act like writting is finished, it might be that it actually isn't and drive is unmounted before operation is completed.
Reagrdless of the reason, point is, user experience is what matters, and ntfs-3g provides bad one with normal use (not using sync etc., simple file manager use).

cryptearth wrote:

no matter the driver: writing onto ntfs from linux is just wrong - and everybody doing it deserves issues
in difference to exFAT the specs of ntfs were never made public and every driver except microsofts own is based on reverse enegineering
aside from that the complex NT security is way too different from rather simple posix - hence ntfs acl are way different from posix simple user/group/other read/write/execute
if you want to exchange data either use network protocols likt http or ftp - or FAT/exFAT

In that case, if we want to look things from that angle, all ntfs drivers should be removed, from both kernel and repositories in every distribution. I disagree with your view.

Tiikerihai wrote:

NTFS3 cannot be used to safely write NTFS drives, I know from experience that this causes massive corruption over time. I discovered widespread file corruption after about 1 year. NTFS drives on Linux should only ever be mounted RO unless the data on them is worthless to you. By the way, in my case I only used the drive with Windows PE and Linux, never in an actual Windows install. So the corruption I got was exclusively from Linux driver.

That's interesting, I did not hit 1 year mark yet, but I do occasional writes to NTFS file system. In general, most (if not all) of the data that go to the NTFS partition is "worthless" to me, it is not of importance, and if it is, it usually have backup.

cryptearth · 2026-08-04 05:55:21

lpr1 wrote:

In that case, if we want to look things from that angle, all ntfs drivers should be removed, from both kernel and repositories in every distribution. I disagree with your view.

well, if you want to phrase it this way, yes, that's exactly what i mean
let's face it: the NT security model with it's SIDs and very complicated fine-grained permissions (had you recently have a look at win10/11 explorer what about a dozen different permissions can be set on files and folders?) along with the traditional base attributes "system", "archive", "hidden" and "read-only" is way more complicated and can't properly mapped to the rather simple posix permissions of user:group and the three base permissions read/write/execute for owner/group/others - this alone requires either what most drivers do: just set root:root and 0777 for the entire filesystem - or a very sophisticated additional mapping (which, to my knowledge, exists but from what i read is still only an attempt of a partial resolve)

aside from all that: as noted by others: for various reasons windows usually don't proper "close" the volumes - as it just doesn't expect that local fixed disk volumes gets accessed by any other os than itself (that's what this "secure eject" does for removable media: properly flush caches and cleanly unmount and close the volume (and powers down spinning rust) - hence one should always use it) - which leads to file corruptions even windows itself sometimes is not able to recover

another issue is case-insensitivity: this often catches games off guard whose devs use different CamelCase spelling throughout thier code
on windows on ntfs it doesn't matter: linux, LINUX and LiNuX are all the same file - on a posix case-sensitive filesystem these are three different files
the wiki has an entire page just about that one topic of using ntfs from linux - and the problems don't stop there

as i already stated: to me, everyone who mounts a ntfs volume read/write just deserves all these issues
if at all i only access ntfs read-only from a ventoy stick to by pass security to rescue friends files when thier system stopps working
personal i avoid ntfs whereever possible - and for transfer files among friends i use exFAT (or network where available)
and quite honestly: i can't even think of one good reason why Torvalds ever agreed to have a ntfs driver in-tree

seth · 2026-08-04 06:48:46

are experiencing corruptions when doing everything from file manager (mount, unmount, write etc.), while both software and led indicator act like writting is finished, it might be that it actually isn't and drive is unmounted before operation is completed.

umount will sync and sync will block - if whatever you use to manage disks does not inform you about the success or status of umounting a device (umount will usually fail it files are still accessed) that is a you problem.
Also file writing is generally asynchronous, leading to the complains about the weird behavior of the progress bar (moves to 100% quickly and then stalls because it follows the local read operation) but I'm not aware of major reports that some GUI would finish the dialog before the operation has actually completely finished. This is true whether you write to some slow FUSEFS, some remote FS or vfat on some cheap usb key at the end of its life.

Ftr: windows closes the FS when you "securely remove" is or windows is properly shut down. The main cause of inconsistent FS on dual boot systems is that windows by default does NOT shut down but enters hibernation for its "fast start" feature.

In that case, if we want to look things from that angle, all ntfs drivers should be removed

Reading is still fine and on proper usage occasional writes are extremely unlikely to cause any problems.
Treating NTFS like a first-class POSIX filesystem just raise the chances that you'll occasionally fall into some cracks.

V1del · 2026-08-04 08:52:59

@lpr1 what I intend to get at and since we haven't seen hard data on this. How certain were you that the drive was actually handled by ntfs-3g? The fact that removing the package seems to help could have been an unintended side effect, as ntfs-3g sets up a few compatibility symlinks (that come from the time where the in kernel ntfs driver was read-only and not very good) that might get interpreted by e.g. udisks and it potentially opting for the "known to be occasionally corrupting" ntfs3 instead.

As for the entire "people that use ntfs deserve issues" to me that's an incredibly selfish/black and white take that really doesn't hold at all. Having the option if you ever have to deal with it is a good thing and as someone that actually actively uses such a system for a long time I can very confidently say that the only time I've had routine corruption here was with ntfs3 in it's early days.

What you should have however if you routinely deal with this, is have at least some form of a Windows system somewhere you can do proper chkdsks with regardless. I'd agree with you if you don't have a Windows anymore and don't envision a certain drive to ever see Windows again - in that case it likely makes sense to format that to something more POSIX friendly. But there are usecases for this and it's nice to have the option. e.g. I actively share my steam library and media files on a common NTFS partition, though the last time I had to boot into Windows for some game has been quite a while -- but I'd like to retain the option -- and so far have not had any issues for a few years now, despite bigger writes happening quite often (on game updates for example)

Last edited by V1del (2026-08-04 08:54:49)

Tiikerihai · 2026-08-04 09:58:53

lpr1 wrote:

That's interesting, I did not hit 1 year mark yet, but I do occasional writes to NTFS file system. In general, most (if not all) of the data that go to the NTFS partition is "worthless" to me, it is not of importance, and if it is, it usually have backup.

Just to be clear I don't know exactly how long it took for the corruption to start, about 1 year in is when I discovered mangled files that caused functionality issues. One of the signs of things going really wrong was the inability to delete stuff from the NTFS drive. Individual files were fine, a folder with files in it was usually also fine but when I had a big nested directory structure then deleting it became problematic.

Arch Linux

#1 2026-08-03 10:50:25

[SUGGESTION] Remove ntfs-3g from the repository

#2 2026-08-03 11:13:31

Re: [SUGGESTION] Remove ntfs-3g from the repository

#3 2026-08-03 12:02:26

Re: [SUGGESTION] Remove ntfs-3g from the repository

#4 2026-08-03 12:11:24

Re: [SUGGESTION] Remove ntfs-3g from the repository

#5 2026-08-03 12:27:41

Re: [SUGGESTION] Remove ntfs-3g from the repository

#6 2026-08-03 14:01:35

Re: [SUGGESTION] Remove ntfs-3g from the repository

#7 2026-08-03 14:19:38

Re: [SUGGESTION] Remove ntfs-3g from the repository

#8 2026-08-04 02:13:13

Re: [SUGGESTION] Remove ntfs-3g from the repository

#9 2026-08-04 05:55:21

Re: [SUGGESTION] Remove ntfs-3g from the repository

#10 2026-08-04 06:48:46

Re: [SUGGESTION] Remove ntfs-3g from the repository

#11 2026-08-04 08:52:59

Re: [SUGGESTION] Remove ntfs-3g from the repository

#12 2026-08-04 09:58:53

Re: [SUGGESTION] Remove ntfs-3g from the repository

Board footer