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

Support
1

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.

2

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

3

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

4

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.
chkdsk …

5

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.

6

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.

7

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

ntfs-3g

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

ntfs3

  • 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
8

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:

Cheers.

1 Like
9

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?

10

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.

11

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