I am using an external disk with an NTFS file system for my data backups. The last time I backed up my data was on 2024-03-19. After that there was a strange Manjaro update - see below. After the update Manjaro worked as usual, only today, when I wanted to run another backup, it turned out that the external disk with NTFS can’t be mounted any more.
To find out, if the disk has got an error, I started Windows on my (dual boot) PC. With Windows I can acces the disk as usual.
Next I booted Manjaro with the previous kernel 5.13.19-2. With that version I was able to mount the NTFS partition and run my backup (script).
My conclusion: The current kernel 5.15.131-1 causes the problem.
During the update 2 or 3 package conflicts were identified. No matter, whether I chose Package A or B, the system update failed. Then my idea was to delete on my PC one of the 2 conflicting units (their path name was indicated in the error message). After I had done that for all the packages in confict, the system update completed normally and the new Manjaro would boot. Thefore I threw my notes on these packages away and now I cannot tell their names. One of them may have been dbus. Anyway they must have to do with mounting NTFS partitions.
I presume that I can repair the error if I re-install missing packages, but which are the missing ones?
The error is typical of what may be presented when an NTFS volume has not been cleanly unmounted, or if there is damage. The dirty bit is set either way, until maintenance has been properly performed to reset the dirty bit and fix any possible damage.
Using chkdsk in a Windows environment is the recommended method to achieve this.
Simply being able to access the disk in Windows does not indicate that the volume is fine. You need to run chkdsk which will find and fix any damage and clear the dirty bit when successful. The ntfs3 kernel driver, when used, will not mount an NTFS volume suspected of being damaged, until this is done. This is a security measure of ntfs3, and it is by design.
You will find relevant information in the following link.
Note that there is no ‘TL;DR’;
Take some time to read through it and understand the content.
While I can’t comment on kernel 5.15.x regarding this particular issue, you could likely benefit generally from updating to (at minimum) kernel 6.1.x LTS.
For me switching from 6.8 to 6.1 fixed this issue, though my issue is slightly different.
I had internal NTFS shares and an Exfat USB drive that would not mount.
The problem for me wasnt a dirty bit as the drives worked under a different linux install on my laptop.
If you look in the latest “testing” thread it seems the mount options need to be changed as there has been a change in how the NTFS3 nd NTFS-3G drivers are working.
Changing these options worked for my internal drives but i cant find where to edit mount options for thumb drives.
Changing to 6.1 from 6.8 fixed the issue for my USB drive (and the internal drives still work with the new mount options).
Hi @soundoftunder
I read your remarks about the Windows chkdsk command, which I will definitely execute.
However, that does not explain my observation that I can access my NTFS partition with the previous Manjaro kernel 5.13.19-2.
“…you could likely benefit generally from updating to (at minimum) kernel 6.1.x LTS.”
Usually I run the update as it is offered by Manjaro. After that I can see in the boot menu the current kernel version. I do not know how to generate and install a specific kernel such as 6.1.x LTS.
@linux-aarhus
The mount options for my external (NTFS) drive are not in my fstab. I just plug in the drive and the mount happens (or not). I have no idea, how to influence the mount options.
gvfs will do that just fine without further interventions
gvfs mounts removable devices using /run/media/$USER/<uuid-or-label>
removable ntfs- and fat-type file systems will thus be mounted rw with for the active user.
If the file system is clean - there is no need to alter options - if it is not clean then you have a problem.
Don’t use gnome-disks to mount removable devices - it will create entries in fstab.
EDIT:
I had to refresh my memory - ntfs3 driver was officially announced for Linux 5.15 - late 2021.
It is impossible to deduce why it suddenly becomes an issue - more than 2years later.
Besides that - it is wellknown in the Linux Community that NTFS is not always playing nice when mounting in Linux.
We hear next to no complaints on members trying to mount Apples file system - perhaps because everyone knows how Apple works - and by all accounts everyone should know how Microsoft works.
None of them will ententionally make it easy to port their file systems to other platforms - and why should they?
Your reasoning is hardly conclusive, considering the change to ntfs3 has been with us for quite some time. I’m not exactly certain of the timeframe, but I understand the change was made sometime during the kernel 6.x series. Possibly @linux-aarhus can confirm or deny that.
Simply switching to an earlier kernel in this instance may equate to switching to a kernel that doesn’t (yet) include the ntfs3 module. The ntfs3 kernel driver will actively refuse to mount an NTFS volume if a dirty bit is discovered; this is exactly what is designed to do. It’s not a bug, or any other issue to be fixed - it’s a security measure to ensure action is taken to repair the volume, and/or clear the dirty bit, so that ntfs3 will mount it again.
Regarding kernel 6.8.x: Though I haven’t used it yet, I have seen a few reports concerning it (and solutions). For example; the fstab mount options mentioned in the post you quoted are likely due to recent changes requiring different syntax for fstab permissions (which @philm mentioned in a recent post).
Whether it’s otherwise related to ntfs3 is unclear; unless I’ve missed something major.
If kernel 5.13.x didn’t (yet) include the ntfs3 module, but used the older ntfs driver instead, then that would go a long way toward explaining your observation.
I believe that is the case, however, I don’t yet have confirmation either way. I’m not certain exactly which kernel first included the ntfs3 module.
Note that the older ntfs driver simply ignores the dirty bit; and by extension any damage to an NTFS volume is also ignored; and it lets you mount it, regardless.
Well, that’s easily fixed; a little searching and reading would have revealed the Manjaro Wiki (a very useful tool for all of us) and this article:
It’s maybe not related with any kernel version. I’ve had this issue several times, last time was this week.
It usually (for me at least) occurs when i reboot my machine brutally, after a power outage, or when my linux system is frozen and i must reboot with the power button (i have to enable SysRq).
First do chkdsk /f <volume>, (do not forget /f) in windows and reboot to linux
I’m not, hence why i am still looking for the options for mounting USB
An exfat drive i use between 2 linux systems, safely unmounting, gets a dirty bit, which is only discovered on this manjaro install and never on the return trip.
Interesting that only now are people being pointed at the NTFS3 mount options as a fix for internal NTFS drives (as in the link i posted above).
Do not read too much into that - it is and has always been a problem with NTFS in dual-boot environments - and the default answer is always - boot windows and run chkdsk command.
I think that because Linux natively support the NTFS filesystem - users begin to think - hey I can use it for everything - but you cannot - and because it is a reverse engineered driver - it is bound to have issues - it inevitable.
Aside:- Exfat doesn’t support the dirty bit, that’s true, however, chkdsk is still potentially useful to correct errors in the volume. Unfortunately, data recovery of any kind (example, data in bad sectors) may be non-existent for exfat; just as that much is true for vfat formats (exfat is only an extension of fat32, afterall). Exfat was originally conceived for interoperability (a mutual sharing format) between hfs+ and Microsoft formats. It didn’t progess much past that initial intention, afaik.
I ran the chkdsk command as you suggested but it has not solved the problem. I can no longer access my windows partition or my ntfs usb stick. I should be most grateful for instructions as to how to solve this problem.
Thanks for the link but I don’t see what I should do so I’ve reverted to the 6.7.12-1 kernel and now all my Windows partitions can be mounted as before. Curiously, on my other computer running Manjaro I have not been offered the update to the troublesome 6.8.4-1 kernel.
Yes, kernels have been updated within the last 24/48 hours that fixed some issues. I haven’t been affected (using kernel 6.6) so I cannot comment on what exactly has been tinkered with in the newest iterations.
