Error mounting NTFS HDD: Wrong fs type, bad option, bad superblock

Support
1

Hi,

For a few weeks I’ve been unable to mount an internal NTFS Hard drive.

Throughout this post, all installations of manjaro use manjaro-kde-22.1.3-230529-linux61.iso as my starting point.

After a fresh Manjaro install today, the NTFS disk was mountable and I could use it. After getting the OS up to date and rebooting, the drive is no longer mountable. This is actually a reproduction of the error after installing manjaro a second time to a different drive. The NTFS HDD is still mountable in LiveCD, windows 10, and fresh installs. Only after updates does it seem to fail. Chkdsk sees no fault, NTFSFix says only chkdsk can fix it.

I have three ideas for the source:

  • It’s a flaw in one of the updates, which is why I am writing here. I don’t write operating systems and couldn’t begin to imagine what part of these updates is causing it to suddenly fail.
  • Some other issue during reboot.
  • My network admin is firewalling certain parts of my online updates, causing the little bit of code for NTFS to work on my computer to not get to my computer, leaving it nonfunctional. This network suffers from severe packet loss (20% to 80%) during any sustained download and likes to take 1-5 second breaks every few minutes. Let me know if checksums exist for something like that.

This error occured previously after my NVME had been replaced by RMA. I made a fresh Manjaro install to the NVME and the NTFS HDD mounted fine at first. One day I returned, and it mounted no more, presenting the error in the title. I took off my manjaro NVME and booted into Win10. The drive mounted fine in Win10, and Chkdsk said nothing was wrong. I thought the odds of a second failed NVME drive were incredibly unlikely. I tried a Manjaro LiveCD, and the NTFS HDD mounted fine, which made me suspicious of my NVME once again that hosted my Manjaro install. One day I began some updates, and during the update download, the drive suddenly began to mount again. That was until I rebooted after finishing the updates, and it stopped mounting. I try mounting the drive every day to see if there is really some intermittent cause, and every day it fails. Maybe western digital really sent another bad NVME that was corrupting my Manjaro, it’s been known to happen.

To rule that out, I reinstalled Manjaro to a traditional SSD that I’ve used for years, earlier today, bringing me to the first paragraph, and the issue reproduced after updating and rebooting.

If there is any log or command line suggestions to get information regarding the hardware, please let me know. I made the switch from Win7 to linux only a few months ago and am still unfamiliar with many parts of it and what knowledge readers may want.

Some troubleshooting I took from a guide in a similarly titled support thread in this forum, a guide I can’t link according to forum rules apparently. It’s on itslinuxfoss.

  • After writing mount into the cmd to “identify the problem filesystem”, the device does not display. It’s not mounted after all.
  • Writing blkid /dev/sdb2 produces nothing, zero lines. The device number is found in the full error by Dolphin: An error occurred while accessing 'Thrasher', the system responded: The requested operation has failed: Error mounting /dev/sdb2 at /run/media/rainy/Thrasher: wrong fs type, bad option, bad superblock on /dev/sdb2, missing codepage or helper program, or other error. KDE Partition Manager also displays that partition address.
  • nano /etc/fstab produced only 3 lines, of which I have 4 mounted devices, not including what should be the 5th?: the NTFS drive. Nothing references it here. I had to reopen the console because I don’t know how to exit nano, and the hotkeys written below don’t tell me.
  • fsck /dev/sdb2 said I didn’t have permission to open the location. sudo fsck /dev/sdb2 actually did nothing, returning only one line containing fsck from util-linux 2.39.3.

And yet, dolphin sees the device. KDE Partition Manager sees the drive, and sees the ntfs-type partition named /dev/sdb2. It’s real, it’s there, it wont mount.

Thanks for reading, I apologize for the wall. I may not find time to read the thread again until after work tomorrow (18h), but I greatly appreciate any suggestions or acknowlegdement. If there’s no hope for a solution, I’d like to know too. I may try some other linux distributions to see if they fare better, however the NTFS compatibility I hear is a very core component close to linux’s kernel, which would probably be the same on other distros.

2

Hi @rainyaura and welcome to the Manjaro community

This error usually indicates that the NTFS filesystem is damaged.

1. Fix the error using chkdsk

If an error exists on the NTFS filesystem, it should be corrected within a Windows environment; which can be achieved by launching an administrative command prompt and using the chkdsk command:

chkdsk /f x:

x: denotes the drive letter of the disk as it appears in Windows.

If a Windows installation is not available, chkdsk may also be run from a bootable Windows installer, or the downloadable Hiren’s BootCD PE; as one possible example.

2. Blacklist the ntfs3 kernel module, and use ntfs-3g (Optional)

Install ntfs-3g:

# Check whether the `ntfs-3g` package is installed
pacman -Qi ntfs-3g

# Install the `ntfs-3g` package, if needed
sudo pacman -S ntfs-3g

Blacklist ntfs3:

echo 'blacklist ntfs3' | sudo tee /etc/modprobe.d/disable-ntfs3.conf
  • To reverse this decision at any time delete disable-ntfs3.conf:
sudo rm /etc/modprobe.d/disable-ntfs3.conf
  • The ntfs-3g package may remain installed, if desired, as the ntfs3 kernel driver will take precedence if it is not blacklisted.

A note on blacklisting ntfs3 in favour of ntfs-3g:

The ntfs3 kernel driver can appear to fail if damage; or, rather, an indicator of damage; to an NTFS formatted drive is found (commonly referred to as a dirty bit).

ntfs-3g, however, ignores this dirty bit and mounts the NTFS partition, regardless.

Important to note is that the NTFS filesystem may still be damaged. ntfs-3g allows you to continue using your drive blissfully unaware that a problem still exists.

Blacklisting ntfs3 when it fails to mount an NTFS filesystem, and using ntfs-3g instead, can allow the partition to be mounted – but that’s all it does – any indicator of damage to the drive is completely ignored; and loss of data is possible.

Any actual damage to the NTFS filesystem still needs to be repaired using the methods previously outlined, in a Windows environment.

I hope this helps. Cheers.

Notes:

Writing blkid /dev/sdb2 produces nothing, zero lines.

blkid requires elevated privileges, like this:

sudo blkid

… which will output details of all attached disks/partitions.

  • You can also use lsblk which does not require sudo. See man lsblk.

nano /etc/fstab does not include the NTFS drive. Nothing references it here.

A typical /etc/fstab default entry for NTFS resembles:

UUID=xxxxxxxxxxxxxxxx /mnt/thrasher ntfs defaults 0 0

For detailed configuration:

  • See NTFS-3G if using ntfs-3g.
  • See NTFS if using the ntfs3 kernel driver.

Important: The mountpoint folder must be manually created:

sudo mkdir /mnt/thrasher

  • Find the correct UUID (xxxx-etc) using sudo blkid

  • Removable drives (such as USB) are not required to have an entry in /etc/fstab – use the taskbar widget instead.

I had to reopen the console because I don’t know how to exit nano, and the hotkeys written below don’t tell me.

They do tell you. Keep in mind that ^ represents the ctrl key in nano:

So: ctrl+x to exit nano; then Y to save the file, or N to close without saving, and press enter to finally exit.

fsck /dev/sdb2 said I didn’t have permission to open the location. sudo fsck /dev/sdb2 actually did nothing, returning only one line containing fsck from util-linux 2.39.3.

  • fsck should not be used to repair an NTFS filesystem.
  • fsck should only be used on an unmounted Linux disk, and requires elevated privileges. It’s also best run from a Manjaro Live Installer.

the NTFS compatibility I hear is a very core component close to linux’s kernel, which would probably be the same on other distros.

Manjaro (and most other Linux distributions) have recently switched to the ntfs3 kernel module/driver. If an indicator of damage is found, it will rightfully refuse to mount the NTFS filesystem. This is a safety feature; the damage must be properly repaired before ntfs3 will allow the drive to mount.

Previously, ntfs-3g was commonly used instead, which skips the check for damage and mounts the disk – however, it does not repair it – this means you might continue using the drive blissfully unaware that you could be allowing even more damage to accumulate.

2 Likes
3

I would also like to add:

Do not use ntfs on linux unless you absolutely HAVE to. If you want a shared partition between the 2 operating systems, use exFat.

NTFS is microsoft closed source and things can happen when kernels gets updated as you noticed right here.

For ExFat however the source code is available so things like this most likely will never happen.

If you keep having your ntfs mounted it WILL, mark my words, act up again. Maybe not to this extent, but it will act strangely from time to time. Worst case scenario, corrupt data.

4

No, this a not a recommendable entry. Please read Archlinux wiki.

https://wiki.archlinux.org/title/NTFS-3G

A typical entry in your example would be

UUID=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx  /mnt/thrasher  ntfs-3g   uid=userid,gid=groupid,umask=0022    0       0

whereas “userid” and “groupid” have to be replaced by the correct values which could be taken from /etc/passwd, for example.

5

Yes, if ntfs-3g is actually used. Noted. :wink:

6

Wow, thank you for the thorough reply! And thanks for reading and responding to each part of the wall :sweat_smile:. It was informative, educational, and kind of inspiring.

  • It looks like the guide wasn’t clear about blkid requiring higher priviledges, good to know.
  • Indeed it looked like I missed ^X in the corner of Nano’s controls. That was my mistake.
  • /etc/fstab still doesn’t seem to show the disk, maybe because it’s not formally mounted to a manual mountpoint, I’ve just been clicking it every time in Dolphin and that puts it on.

Now as for the primary issue: I performed both of your suggestions, and the partition once again mounts. Chkdsk couldn’t find any issue, the disk worked fine in windows. It’s probably the alternative ntfs-3g kernel module from your Suggestion 2. that’s letting it work. Checking if ntfs-3g was installed said it was installed in May, which is older than this computer, so I figured that was incorrect and installed it anyways with the second step. I am kind of confident that if Chkdsk says things are good, than ntfs-3g is probably safe for the time being.

Thank you and @bedna for the caution for using the NTFS volume in these circumstances. I will very much keep it in mind. I’m just 1.1TiB short of extra space currently to move all 4.5TiB so I can reformat the disk. I’ll look into exFat though and maybe plan for it. There’s some files I may be able to cut down.

For anyone’s curiosity, below is the Chkdsk output. As for the thread, it was promptly solved, thank you very much. I hope someday I can learn enough about this OS to be just as helpful :rofl:

(c) Microsoft Corporation. All rights reserved.

C:\Windows\system32>chkdsk /f E:
The type of the file system is NTFS.
Volume label is Thrasher.

Stage 1: Examining basic file system structure ...
  435968 file records processed.
File verification completed.
 Phase duration (File record verification): 6.35 seconds.
  28993 large file records processed.
 Phase duration (Orphan file record recovery): 0.00 milliseconds.
  0 bad file records processed.
 Phase duration (Bad file record checking): 0.16 milliseconds.

Stage 2: Examining file name linkage ...
  16287 reparse records processed.
  480462 index entries processed.
Index verification completed.
 Phase duration (Index verification): 1.12 minutes.
  0 unindexed files scanned.
 Phase duration (Orphan reconnection): 77.03 milliseconds.
  0 unindexed files recovered to lost and found.
 Phase duration (Orphan recovery to lost and found): 3.75 seconds.
  16287 reparse records processed.
 Phase duration (Reparse point and Object ID verification): 22.60 milliseconds.

Stage 3: Examining security descriptors ...
Security descriptor verification completed.
 Phase duration (Security descriptor verification): 16.89 milliseconds.
  22248 data files processed.
 Phase duration (Data attribute verification): 0.15 milliseconds.
CHKDSK is verifying Usn Journal...
  37647384 USN bytes processed.
Usn Journal verification completed.
 Phase duration (USN journal verification): 248.99 milliseconds.

Windows has scanned the file system and found no problems.
No further action is required.

   5723036 MB total disk space.
   4668899 MB in 384525 files.
    161712 KB in 22249 indexes.
         0 KB in bad sectors.
    721179 KB in use by the system.
     65536 KB occupied by the log file.
1078554392 KB available on disk.

      4096 bytes in each allocation unit.
1465097471 total allocation units on disk.
 269638598 allocation units available on disk.
Total duration: 1.29 minutes (77748 ms).```
2 Likes
7

This topic was automatically closed 3 hours after the last reply. New replies are no longer allowed.