Error when mounting an NTFS partition

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.

In this forum I found a contribution that deals with exactly my error message “Error mounting NTFS HDD: Wrong fs type, bad option, bad superblock” , however, it is focused on a HW problem, therefore I believe that the solution is irrelevant for my problem. See

The strange system update done after 2024-03-19:

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?

Hi @jolexin

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.

I hope this helps.


1 Like

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

Instead of handling the changed mount options you revert to a kernel which still uses the old options.

You will have to deal with it sooner or later - so educate yourself now …

1 Like

I changed the mount options for the internal drive.
But i am yet to find USB mount options to change.

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.

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.

Don’t use fstab to mount removable devices.

fstab is for static file system information - thus not applicable for USB

 $ cat /etc/fstab
# /etc/fstab: static file system information.

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.

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.

Edit:- Now confirmed, thanks to @linux-aarhus :point_down:

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:

I hope this helps.


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


The following article might interest you also, considering that you already put into practice the essence of the article’s main theme. :slight_smile:


1 Like

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

exfat does not have a dirty bit - not that I know of - only ntfs - and only set if system is hibernating or has Windows Fast Startup enabled.

It was opensourced a couple of years back - so I am fairly certain the kernel module adheres to specification.

If you have problems with data getting courrupted, you may benefit from using a kernel > 6.1 and disable writecache for USB → [root tip] [How To] Disable write cache for USB storage devices

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.

My exfat USB drive (not mounting) exhibits the same results as an NTFS USB drive (also not mounting).

Only one of these has a dirty bit so it cannot need a chkdsk in both cases.

I hope the OPs problem is solved by chkdsk because it can be nothing else.

Sorry for the sidetrack.

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.

Hello @soundofthunder! Yes, the Windows Chkdsk command did indeed solve the problem.

Glad to help.

I marked my post above as the solution; or the post that lead to the solution. Feel free to change that if you disagree.


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.

1 Like

Without knowing the particulars of your issue all I can suggest is that you read and understand the following article;

…and if you experience further issues, please open your own thread so that others can help you, if needed. Cheers.

and, Welcome to the Manjaro community.

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.