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

lpr1 · Today 09:11:39

cryptearth wrote:

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

At the end that is your view, the reality of the situation is, ntfs3 does not cause those issues, while ntfs-3g does, so that is the main point of this whole thread regardless of the personal view on the matter and facts you've mentioned above. In most cases, I was able to repair file system from the mess ntfs-3g made.

seth wrote:

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.

Yes, I am aware of that fact (moving to 100% and stalling there, or falsely reporting "completed" when it's actually not), hence why I always give major extra time (double, tripple or even more than what should be average time on the drive in question) to complete the process, exactly for that reason = to avoid corruption and to ensure writting has completed. So, with all that caution, and the fact that removing ntfs-3g resolves the issue, I wouldn't call it a "me problem", it's more of a file manager issue, but I am leaning towards ntfs-3g for the reasons mentioned above.
That is the thing, I never treated NTFS as "first-class POSIX filesystem", I did not clarify that before, so your assumption stands, as you can see, I treat it as an very fregile FS with lot's of caution when writing in it, hence why I came to the conclusion it must be a ntfs-3g fault.

V1del wrote:

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

Well, that is a good point, what is exactly causing corruption I am not sure indeed. What I am sure about is the fact that after removing ntfs-3g package = issue disappears, so that package have something to do with the issue for sure as far as I'm concerned.

You are right, that can be viewed as selfish, but, my main point is, that after 2-3 years the issue is not addressed, and it's important issue given the impression I got from those "other people having same exact issue and same solution", so in my honest opinion, software that creates such an big issue (and it is a big issue, unmountable corrupted partition) for so long, without addressing it, does not deserve to be in the official repository. That is my view anyway, is it selfish? Maybe. Is it aimed at betterment of thge project? Yes, no doubt.

That's (chkdsk) exactly how I managed to repair partition most of the time after all linux attempts fail. So I see your point of having an option, hence why I suggested some sort of warning instead of outright removal at later posts, while I still hold the opinion that quality of the software must meet certain criteria, and I can't call software high quality if such big issue is not addressed for so long.

Tiikerihai wrote:

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.

I will see, I do not write a lot of data to it to begin with, however, that is also an issue, with such a rare use-case I was facing issues with ntfs-3g package installed (to be precise), after removal, even with heavier use (for testing purposes), issue does not happen. Now, we will see after year(s) of usage for sure, so far, it's good.

cryptearth · Today 10:21:03

please avoid full-quotes

tl;dr: if your question is "do you support my proposal to remove ntfs-3g from the official repos (and maybe mive to aur)?" - you have a FULL ACK from me

dimich · Today 11:00:10

lpr1 wrote:

hence why I always give major extra time (double, tripple or even more than what should be average time on the drive in question) to complete the process, exactly for that reason = to avoid corruption and to ensure writting has completed.

Unmount filesystem from console. After umount command completes, it's safe to eject the drive.

seth · Today 11:15:39

removing ntfs-3g resolves the issue, I wouldn't call it a "me problem", it's more of a file manager issue, but I am leaning towards ntfs-3g … can be viewed as selfish, but, my main point is, that after 2-3 years the issue is not addressed, and it's important issue given the impression I got from those "other people having same exact issue and same solution"

Taking any kind of broad action based upon nothing but an unsubstantiated claim of anecdotal coincidence would be outright silly.
For all we know the change could have be completely unrelated to the package removal and relate to changes in your behavior, the used drives, bugfixes in bus drivers or actually ntfs3.
As since you mentioned "file-managers": as indicated before, udisks defaults to ntfs3, so unless you're explicitly re-configuring that you have corrupted the filesystem using that (ntfs3) while ntfs-3g were some inert bytes on your root partition.

=> Re-install ntfs-3g and analyze the situation, starting with "is it being used at all".
If you *are* using ntfs-3g now, see whether there are any errors/warnings logged, the issue re-emerges and whether it follows some kind of pattern (wrt the affected files or circumstances wrt. reboots and drive removals, resp. the drives involved)
If you think you've encountered reports supporting your hypothesis, please reference them.

lpr1 · Today 12:09:15

dimich wrote:

lpr1 wrote:
hence why I always give major extra time (double, tripple or even more than what should be average time on the drive in question) to complete the process, exactly for that reason = to avoid corruption and to ensure writting has completed.
Unmount filesystem from console. After umount command completes, it's safe to eject the drive.

Sure, but that's not the point of this thread, you can't expect that use case from every user, it's unconvinient.

seth wrote:

removing ntfs-3g resolves the issue, I wouldn't call it a "me problem", it's more of a file manager issue, but I am leaning towards ntfs-3g … can be viewed as selfish, but, my main point is, that after 2-3 years the issue is not addressed, and it's important issue given the impression I got from those "other people having same exact issue and same solution"
Taking any kind of broad action based upon nothing but an unsubstantiated claim of anecdotal coincidence would be outright silly.
For all we know the change could have be completely unrelated to the package removal and relate to changes in your behavior, the used drives, bugfixes in bus drivers or actually ntfs3.
As since you mentioned "file-managers": as indicated before, udisks defaults to ntfs3, so unless you're explicitly re-configuring that you have corrupted the filesystem using that (ntfs3) while ntfs-3g were some inert bytes on your root partition.
=> Re-install ntfs-3g and analyze the situation, starting with "is it being used at all".
If you *are* using ntfs-3g now, see whether there are any errors/warnings logged, the issue re-emerges and whether it follows some kind of pattern (wrt the affected files or circumstances wrt. reboots and drive removals, resp. the drives involved)
If you think you've encountered reports supporting your hypothesis, please reference them.

I wouldn't say it's anegdotal or unsubstantional, this is real issue, and I am telling you it's happening, will you accept that fact or not is up to you, but "vblame the user" approach would never solve any issue anyways..., this IS real issue for at least 3 years now, and simple sear ch can prove that to you (same 3exact issue, different file manager):
https://www.reddit.com/r/linux4noobs/co … _the_time/

I did read whole thread above, and multiple others with same issue, it's a common sense that we can conclude it is not a fault of file manager and that the main way to resolve the issue is to remove ntfs-3g package, that is factual, there is no doubt about it. The user "Sinaaaa" gave a proper response, he was pointing out at KDE bug, but that is not the case, since I do not use dolphin or KDE but files (nautilus).

I would love to test that, but I do not have time now, and also, there were 2 times I was unable to recover partition, resulting in formating NTFS partition and re-doing a lot of things I am not willing to do again. I think there is enough evidence that ntfs-3g package is the problem for whatever reason, I am not going into details about it because I do not know. What is important is that the issue is written here, weter it will be investigated and addressed or ignored, it's not up to me, so far it was ignored.

@cryptearth I don't like to cut off context of the message when it's not needed, if there is a real reason to avoid full quotes, I will do it.

seth · Today 12:13:47

It *is* anecdotal as long as all you provide is a personal record (sample size: 1) and unsubstantiated w/o any hard data that at least rules out that ntfs-3g is not even involved.
Nobody is saying that nothing happened to you (ie that you're lying) but that with what you've provided so far you're simply jumping to conclusion based on little more than absolutely nothing.

https://www.reddit.com/r/linux4noobs/comments/1adxmey/linux_corrupts_a_ntfs_partition_most_of_the_time/ wrote:

Here is some more info on what I've and I'm doing.
I mount my NTFS drive from dolphin (Not default mount yet) and it uses the ntfs3 new driver:
/dev/nvme0n1p5 on /media/[my_name]/Stuff type ntfs3 (rw,nosuid,nodev,relatime,uid=1000,gid=1000,windows_names,iocharset=utf8,uhelper=udisks2).

-- qed

lpr1 · Today 12:25:15

seth wrote:

It *is* anecdotal as long as all you provide is a personal record (sample size: 1) and unsubstantiated w/o any hard data that at least rules out that ntfs-3g is not even involved.
Nobody is saying that nothing happened to you (ie that you're lying) but that with what you've provided so far you're simply jumping to conclusion based on little more than absolutely nothing.
https://www.reddit.com/r/linux4noobs/comments/1adxmey/linux_corrupts_a_ntfs_partition_most_of_the_time/ wrote:
Here is some more info on what I've and I'm doing.
I mount my NTFS drive from dolphin (Not default mount yet) and it uses the ntfs3 new driver:
/dev/nvme0n1p5 on /media/[my_name]/Stuff type ntfs3 (rw,nosuid,nodev,relatime,uid=1000,gid=1000,windows_names,iocharset=utf8,uhelper=udisks2).
-- qed

Ok, I also linked wrong thread, for the life of me I can't find the thread I did 7-8 months ago with users suggesting removal of ntfs-3g and OP doing it and resolving the issue. My bad for not reading and assuming that is the same thread (it was a reddit post I'm sure). Anyway, the solution suggested by that user solved the issue for me as well, same as for the OP.

Well, I am not the developer, if action of doing things to X solves the issue, I think it's resonable to assume that "X" is the problem. It can happen that the most logical assumption would be wrong, but I'm not sure how likely that is. Either way, someone with more time, knowledge and will should investigate it and potentially address it if it happens to be an issue.

Wild Penguin · Today 15:29:21

Either way, someone with more time, knowledge and will should investigate it and potentially address it if it happens to be an issue.

Ummm... no, that is not how things work. Unless you mean with "someone" you, yourself, personally.

I've red trough this thread and the problem here for troubleshooting and finding any bug is that there is nothing substantial here for any developer to work on about. They (any developer working on any problem or bug) will need enough information to at least roughly pinpoint the issue in the driver, reproduce, make a test case and then fix. "I changed drivers and it fixed my problems on my end, hence driver X has a problem" is not a helpful statement at all.

I recommend you read trough these (all of these!) with some thought:

- https://wiki.archlinux.org/title/Genera … leshooting
- https://gist.github.com/Hashino/6d54ba5 … d0326997da
- https://www.catb.org/~esr/faqs/smart-questions.html

I'm not posting these links to be condescending. They are all excellent sources, I've red trough all of them and learned to become a better troubleshooter and at asking questions because of them (except the one in the gist, but it seems solid and I will read it later).

Then you will understand you absolutely need to provide relevant logs at minimum from the time of the issue (among other things) and, preferentially, be able to reproduce the issue. Come back with that information if you can reproduce the issue.

I would also like to point out - having scouring around the net about other people's experiences about all the NTFS drivers - is that ntfs-3g has been historically regarded as the most stable one (however, things have been moving along a bit and ntfs3 may be just as stable these days). This re-enforces the need to you specifically diagnosing and getting the relevant information about the problem - and, since we do not know of anyone else how to reproduce the issue, reproduce the issue yourself (so that more information can be gathered).

Also, there are many other reasons besides (some of) the Linux NTFS drivers which can cause corruption - all of which are much more likely than a bug in the driver(*):

Windows and Linux interoperating; namely,
unclean demounts,
illegal characters (from Window's pov),
symlinks,

Overall, the corruptions you have experienced could have been produced by anything (else than the driver). It could have been cosmic rays for all we know.

Last edited by Wild Penguin (Today 15:30:29)

seth · Today 15:29:56

Please avoid bloating the thread w/ pointless full quotes.

Would you mind to point out/directly link what the supposed solution for the OP in that thread ended up being?

shutdown the system, and boot into windows and fixed it

???
Using chkdsk is the suggested and preferred solution, no matter how the filesystem was corrupted.
(pointed out along the ntfs-3g provided ntfsfix, https://wiki.archlinux.org/title/NTFS-3 … ilesystems )

Wrong thread or not, that leaves us at the status-quo ante, we've seen *nothing* to put any substance behind your claim, so you would have to provide that.
My money is btw. on you using and having indeed used ntfs3 because that is the default and has caused trouble (at least when it was newly introduced to the kernel) - I frankly don't see where yours would be the "most logical assumption" based on everything (as little as is) you've provided so far.

Provide some hard data on the situation or live with this being perceived as uninformed FUD.

jbosboom · Today 17:38:10

I regularly use ntfs-3g to transfer files to/from Windows computers using USB flash drives and spinning rust hard drives connected by USB-SATA adapters. I've mounted partitions manually using mount and udisksctl and automatically from Thunar. I've also mounted filesystem images through loop devices with udisksctl. I haven't had any problems at all. Even the performance is tolerable.

I would be disappointed if ntfs-3g were removed from the repositories. The ntfs3 kernel implementation has a history of bugs. The new kernel implementation (confusingly just called "ntfs") was merged in 7.1, the current stable series, so I don't trust it yet. I'm sure it had some testing before merging and during the RCs, but most normal end users wait for the release and they'll find new bugs. I'll keep using ntfs-3g until the new kernel implementation has baked for a couple series.

As for "just use exFAT", when people bring drives (not microSD/etc.) to me they're usually formatted NTFS and full disk images of Windows computers are always NTFS.

So this is a "ntfs-3g works great for me" post to oppose the "ntfs-3g (maybe) didn't work for me" posts in this thread.

V1del · Today 18:40:30

The "selfishness" comment was directed at cryptearth who thinks that you shouldn't even want to have this usecase of being able to write to an NTFS drive from linux, which I strongly disagree with.

The curiosity in me is what's trying to identify whether it was indeed up to ntfs-3g, because I'd find corruption from it to be curious because I can not at all reproduce this (and ntfs-3g has existed for much longer than any of the other options), I'm fine if you don't want to expose your data to the potential danger, but experience of it creating routine corruption runs strongly against mine (and apparently a few others experience) I know that there's some special code in udisks that will prefer ntfs3 that AFAIK only triggers when ntfs-3g's compat symlinks are present, so I'm trying to identify whether you were actually running ntfs3 as that has been known for quite a few corrupting factors

Last edited by V1del (Today 18:42:25)

seth · Today 18:49:15

Just mounting the filesystem as usual (or used to), chcking what driver/mount options is actually in use and umounting it w/o writing anything is very unlikely to cause any data corruption *except* if the filesystem is already open in a hibernating windows - then really anything can happen.

xerxes_ · Today 19:28:06

Some time ago I also found error/corruption on ntfs formated external usb drive, used for backup. It was like Tiikerihai describe it: in deep subpath there was some file(s) (but not many) that I couldn't copy and later find out I also couldn't delete it. I though that drive is failing and I copied everything I could to new drive. Fortunately those files was not important. I don't know what driver to blame: ntfs3 or ntfs-3g. Most probably some time system hanged/crashed and I was unable to safely unmount the drive.
Beside that drive with ntfs filesystem I have second external drive and pendrive and with these 2 I don't have (known) problems yet.
With second drive I had a story recently: in some dir I had file and folder named the same but different case and mounted it on windows, entered to that dir and in the same time I find out I have a problem, but fortunately nothing bad happened - I was renaming that file but when I finished (pressed enter) the name of the folder was changed. All was done in totalcmd, not windows file manager. The files in that folder are still readable, but I will be testing them for sure.
As for unmounting the drive: I look in top io ops to be about 0,0 io for few seconds (10s should be enough) and than I think I can umount drive; on (almost) idle system I think it's good measure. I agree that unmounting is blocked and have to wait for data sync, even on graphical file manager.
For me I don't think that ntfs-3g should be removed; don't like it - don't use it. And it's hard dependency of clonezilla and partclone.

Last edited by xerxes_ (Today 19:41:41)

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

#13 Today 09:11:39

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

#14 Today 10:21:03

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

#15 Today 11:00:10

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

#16 Today 11:15:39

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

#17 Today 12:09:15

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

#18 Today 12:13:47

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

#19 Today 12:25:15

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

#20 Today 15:29:21

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

#21 Today 15:29:56

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

#22 Today 17:38:10

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

#23 Today 18:40:30

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

#24 Today 18:49:15

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

#25 Today 19:28:06

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

Board footer