"wrong fs type, bad option, bad superblock on /dev/sdb1" error mounting HDD

So this may be stupid, but I can’t mount my Toshiba external hard drive (with NTFS filesystem).
At least not as usual. The error is:

wrong fs type, bad option, bad superblock on /dev/sdb1, missing codepage or helper program, or other error

What is strange to me, compared with other cases (1) (2) (3), is that:

  • I’m able to mount another external hard drive with the NTFS3 filesystem
  • I’m able to mount THIS external hard drive too with sudo, typing: mount /dev/sdb1 /mnt in terminal

How is it be possible?
How can I mount THIS hard drive “normally” without sudo and without getting the error?
Thank you.

It seems to work with sudo, so:
What is “usual”?

That it mount without sudo, as it always did before this error. Isn’t it the normal behaviour of every external HHD?

not for me - mount always needs admin rights

this command:

would always fail without sudo

perhaps the file system on the drive needs to be checked and repaired?
Only Windows tools can do that reliably.

I always mount my external hard drives without opening a terminal and typing a command with sudo.

I still mount other external HHD just by clicking the button on the notification when you insert the USB or by the context menu right-clicking its name in Dolphin (KDE). Never had that error.

so that would be the actual answer to the question:
What is “usual”? :face_with_peeking_eye:

But I’m not qualified to answer - I do not have or use NTFS drives and only have read about these kinds of problems and how people are solving them.

Then you use udisks2 as backend. ntfs3 is the default there. And yes the error is somewhat misleading, but it has to do with ntfs being in a dirty state from windows.

There are 2 drivers: ntfs-3g and ntfs3. Both are different


  • userspace driver
  • force remove dirty bit by default
  • has default option which is called recover and this removes the dirty bit instantly.


  • kernelspace driver
  • doesn’t remove dirty bit by default
  • has an equivalent parameter to recover option: force. That means it will ignore the dirty bit, but disabled by default.

Note that both approaches can be dangerous, since this dirty bit is meant for checking the FS on the next mounting process, so usually on Windows. Linux does not and is not able to check the consistency of your data when using ntfs.

1 Like

What I understand you are saying is that your NTFS drive no longer mounts automatically as it did before, due to the error you described above.

Using ntfs3 that error is by design; it’s a security measure; a warning to correct possible damage that was detected. Until that is done, ntfs3 will actively refuse to mount that volume.

Perhaps this article will give you some insight into NTFS and how it works (and doesn’t work) with Linux. Please, read it and understand:


1 Like

Since this is now happening with 3 out of 3 hard drives, is it correct to think that it was a system update that caused these errors to appear?

It seems so. See issues with auto-mount of ntfs filesystem using Kernel 6.8 for a note about it. Changing /etc/fstab permissions syntax seems to fix it.

Another (temporary) solution might be to revert to an earlier kernel (6.6 for example).

Regarding the comment from @Nachlese :point_down: - It may seem unlikely that all three volumes would develop an error simultaneously, but it’s certainly not impossible if (for example) the machine had a forced hard reset.

Indirectly, perhaps.
Are you sure your NTFS file systems are indeed clean? Free of errors.
Better check using Windows chkdsk.
Only then look for other causes.

1 Like

After a full system update, I was getting the same error while opening my internal NTFS partition; which was automatically mounted every time before the update.

I found these commands in the comment section of this youtube video

sudo fsck -y /dev/<your partition name here>
sudo ntfsfix /dev/<your partition name here>
sudo mkdir -p /media/<name for it>
sudo mount /dev/sda1 /media/<same name in previous line>

use lsblk to find the partition name.

But this fix was temporary. After every boot it didn’t automatically get mounted. So I searched on the internet and found this

Caution: I don’t know if this fix is safe or not

It is not.

  • fsck cannot check ntfs file systems - it’s not the right tool for the job
  • ntfsfix also cannot do what it’s name seems to promise
    All it does it to remove the “dirty” bit from a file system that is marked as having errors or not cleanly unmounted.

The effect is that you can then mount it again and can continue using it - but any error that was there is still there.
You have effectively done the equivalent of covering the “Check Engine” light in your car and pretend that it is not on and the reason for it being on is no longer present.

The only real way to check and fix ntfs file systems is to use native Windows tools.


thanks for clearing it out. I’ll do that…


btw, I have an internal ssd in my laptop, where 2 partitions are ext4 and one is NTFS. Is there any way to use the chkdsk without installing windows or without removing the ssd and connecting it to other laptop?

Yes there is. Please see:

Scroll down until you find the section What if I don’t have Windows?, and some alternate possibilities to run chkdsk are listed.

Consider reading the entire article, as it looks like you might benefit from it.

I hope this helps. Cheers.