Wrong fs type, bad option, bad superblock

OS: Manjaro XFCE 24.0.1

Manjaro was out of hibernation with sda5 mounted.
After a few missed type pwd, it locked the session, so instead of waiting 10min I unplugged the laptop and rebooted.
After reboot, logging when I tried to mound sda5 under Thunar I got this error:

Error mounting /dev/sda5 at /run/media/x245/DOCS: wrong fs type, bad option, bad superlock on /dev/sda5, missing codepage or helper pgm, or other error.

Tried:
sudo ntfsfix /dev/sda5
same error.

Then tried with option -d
sudo ntfsfix -d /dev/sda5

and voilà.

REF:

I am glad it worked for you, but it is actually very debatable if cleaning the dirty bit with this tool is a good strategy. In theory, the filesystem can still have errors. Me personally i would boot windows and check it from windows (i assume you are dualbooting, cause it is the only reason to use ntfs with linux)

chkdsk /f x:

The reasoning behind this consideration is already in the topic you linked.

3 Likes

In future, it’s recommended to only use the official M$ too chkdsk (in a Windows environment) to repair an NTFS volume.

You may think you just fixed the problem with ntfsfix - in fact, all you have done is to remove the so-called dirty bit - if any damage existed before, it still exists - only chkdsk can safely repair a M$ proprietary NTFS volume.

The ntfs3 kernel driver actively prevents an NTFS volume from mounting when damage is discovered. When the damage is successfully repaired by chkdsk the dirty bit is also removed, and ntfs3 will again mount the volume.

Please see the following article (and bookmark it):

All that is required from you is to read and understand.

I hope this helps. Cheers.

2 Likes

You can log into a TTY as root and run faillock --user <username> --reset. Obviously replace <username> with the actual username.

2 Likes

@soundofthunder
chkdsk (in a Windows environment)
You take the assumption, that one can boot under Windows.
In my case it’s an internal hdd ntfs, without windows.

If you don’t need to share it with windows, why is it ntfs?

2 Likes

There is always the Hirens Boot PE live disk.
https://www.hirensbootcd.org/download/

Used to dual-boot, also ntfs can be read across OS, which is not the case of ext4 for instance.

Then probably best to move to a native filesystem if possible.

What OS do you need to share with? AFAIK only windows uses ntfs natively, and you don’t have it installed. If you move the drive to a new computer then if necessary a live USB will be able to read it.

Anyway it’s your computer, I’m not trying to tell you what to do. :smiley:

1 Like

I also made the assumption that you might read and understand the link I gave you. It’s important when dealing with NTFS under Linux. I’ll now make the presumption that you didn’t bother.

Other options exist; booting with a Windows DVD/ISO/USB (you can download an ISO free); creating a ‘Windows To Go’ USB; or a suitable bootable Windows PE disk project containing chkdsk.exe.

So, yes, my presumption that one can boot to a Windows environment to perform such repairs, is not only accurate, but rather easy for the average user to achieve.

Note that the helpful suggestion from @Teo to use a Hiren’s Boot PE is no longer recommended. Hirens contains an open source GUI app made in 2006 (named ‘Microsoft Check Disk’); it has no relationship to Microsoft other than it’s name and intended use.

However this app does not contain any authentic M$ utilities and cannot be guaranteed to be effective or safe.

@Teo suggests using a Hiren’s Boot PE disk; as also suggested in the NTFS on Linux link previously given:

Be aware that Hiren’s contains an open source (GUI) app named ‘Microsoft Check Disk’ (developed by Chris Hall in 2006). It has no connection to Microsoft other than similar naming and functionality, and cannot be guaranteed to be effective or safe.

It is recommended to use the authentic M$ utility chkdsk.exe, which is only available from the commandline when the Hirens disk boots into the Windows PE environment of the Hiren’s Boot PE disk.

If you want an NTFS volume to share data with Windows - if you ever need to - an external USB disk is probably a better alternative. You could then repurpose that internal disk as storage for Linux - as I believe @dmt was alluding to - and perhaps format it as EXT4.

Sorry you took so, I plainly meant what it is, your solution assumes a Win boot versus what I expect and expected plain Linux easy one such as ntfsfix and wanted to share it, but was un-aware of your remark:

You may think you just fixed the problem with ntfsfix - in fact, all you have done is to remove the so-called dirty bit - if any damage existed before, it still exists - only chkdsk can safely repair a M$ proprietary NTFS volume.

I do keep it mind, thanks

Unfortunately, I see that chkdsk.exe under wine is not a option;

chkdsk in wine

P.S. There are more reasons for me to stick to ntfs vs ext4, for instance path name limit of 255 UTF-16 chars versus 255 bytes.

That’s the max filename length.

The max path length seems to be unlimited for EXT4, unlike NTFS.

32,767 characters with each path component (directory or filename) up to 255 characters long

2 Likes

Most welcome.

No, chkdsk is not an option in WINE. However, I have already given you other viable options:

You can use a bootable Windows PE disk, or a Windows Setup ISO, or a Windows To Go USB. Each of these options will allow you to boot into a Windows environment and run chkdsk on the NTFS partition.

  • A Windows To Go is a full Windows installation, that you can create on a USB drive.
  • The Windows PE or Windows Setup methods will allow to boot into a Windows commandline environment.

See my linked article under What if I don’t have Windows?.

All of these options are available to you; however, may require a little more research on your part. There is also a wealth of information in the link I originally gave you which will be of benefit.

Do you have access to a Windows 7/8/8.1/10 DVD/ISO/USB?

Cheers.

I have not even noticed there is such gui thing.
What i meant was the real, console only, microsoft chkdsk from a command line from windows. I have the HirenPE image from last year, based on Windows 10 and it is there. I see now there is a newer version based on Win 11, but i highly doubt they have stripped exactly this from the original recovery environment. I am currently on slow and expensive mobile internet so i will leave someone else to download the 3 GB and test :slight_smile:

chkdisk from HirensPE from last year - looks legit

X:\Windows\System32>chkdsk /?
Checks a disk and displays a status report.


CHKDSK [volume[[path]filename]]] [/F] [/V] [/R] [/X] [/I] [/C] [/L[:size]] [/B] [/scan] [/spotfix]


  volume              Specifies the drive letter (followed by a colon),
                      mount point, or volume name.
  filename            FAT/FAT32 only: Specifies the files to check for
                      fragmentation.
  /F                  Fixes errors on the disk.
  /V                  On FAT/FAT32: Displays the full path and name of every
                      file on the disk.
                      On NTFS: Displays cleanup messages if any.
  /R                  Locates bad sectors and recovers readable information
                      (implies /F, when /scan not specified).
  /L:size             NTFS only:  Changes the log file size to the specified
                      number of kilobytes.  If size is not specified, displays
                      current size.
  /X                  Forces the volume to dismount first if necessary.
                      All opened handles to the volume would then be invalid
                      (implies /F).
  /I                  NTFS only: Performs a less vigorous check of index
                      entries.
  /C                  NTFS only: Skips checking of cycles within the folder
                      structure.
  /B                  NTFS only: Re-evaluates bad clusters on the volume
                      (implies /R)
  /scan               NTFS only: Runs an online scan on the volume
  /forceofflinefix    NTFS only: (Must be used with "/scan")
                      Bypass all online repair; all defects found
                      are queued for offline repair (i.e. "chkdsk /spotfix").
  /perf               NTFS only: (Must be used with "/scan")
                      Uses more system resources to complete a scan as fast as
                      possible. This may have a negative performance impact on
                      other tasks running on the system.
  /spotfix            NTFS only: Runs spot fixing on the volume
  /sdcleanup          NTFS only: Garbage collect unneeded security descriptor
                      data (implies /F).
  /offlinescanandfix  Runs an offline scan and fix on the volume.
  /freeorphanedchains FAT/FAT32/exFAT only: Frees any orphaned cluster chains
                      instead of recovering their contents.
  /markclean          FAT/FAT32/exFAT only: Marks the volume clean if no
                      corruption was detected, even if /F was not specified.

The /I or /C switch reduces the amount of time required to run Chkdsk by
skipping certain checks of the volume.

X:\Windows\System32>chkdsk c:
The type of the file system is NTFS.
Volume label is Windows-SSD.

WARNING!  /F parameter not specified.
Running CHKDSK in read-only mode.

Stage 1: Examining basic file system structure ...
  381952 file records processed.
File verification completed.
 Phase duration (File record verification): 6.33 seconds.
  20742 large file records processed.
 Phase duration (Orphan file record recovery): 0.00 milliseconds.
  0 bad file records processed.
 Phase duration (Bad file record checking): 2.73 milliseconds.

Stage 2: Examining file name linkage ...
  255 reparse records processed.
  594146 index entries processed.
Index verification completed.
 Phase duration (Index verification): 15.16 seconds.
  0 unindexed files scanned.
 Phase duration (Orphan reconnection): 801.82 milliseconds.
  0 unindexed files recovered to lost and found.
 Phase duration (Orphan recovery to lost and found): 2.81 milliseconds.
  255 reparse records processed.
 Phase duration (Reparse point and Object ID verification): 7.75 milliseconds.

Stage 3: Examining security descriptors ...
Security descriptor verification completed.
 Phase duration (Security descriptor verification): 56.63 milliseconds.
  106098 data files processed.
 Phase duration (Data attribute verification): 2.68 milliseconds.
CHKDSK is verifying Usn Journal...
  35812136 USN bytes processed.
Usn Journal verification completed.
 Phase duration (USN journal verification): 232.94 milliseconds.

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

  81122303 KB total disk space.
  57480160 KB in 208100 files.
    214072 KB in 106099 indexes.
         0 KB in bad sectors.
    490379 KB in use by the system.
     65536 KB occupied by the log file.
  22937692 KB available on disk.

      4096 bytes in each allocation unit.
  20280575 total allocation units on disk.
   5734423 allocation units available on disk.
Total duration: 22.63 seconds (22631 ms).
Failed to transfer logged messages to the event log with status 6.

X:\Windows\System32>ver

Microsoft Windows [Version 10.0.19041.1]

X:\Windows\System32>

That ‘app’ may not. But hirens does. Just like other windoze PE things.

You just have to … use them.

As far as I know nothing has changed with hirens in this regard.

(so whomever is making these ‘recommendations’ is either mistaken or misquoted)

I suppose all things being equal I would rather people spin up their own PE, but hirens has been around long enough to be vaguely trustworthy, and we have already touched on the example of a windoze install not existing.

Yes, it’s located at \Programs\ChkDskGUI\chkdsk.exe.

Despite sharing the same filename, and a similarity in both naming and functionality, the (GUI) “Microsoft Check Disk” app (created by Chris Hall in 2006) has no connection to Microsoft.

The HBCD_PE_x64.iso is recent:

SHA256:8c4c670c9c84d6c4b5a9c32e0aa5a55d8c23de851d259207d54679ea774c2498.

However, it seems the mechanism used to verify the claim failed to take into consideration the boot.wim file itself when searching for chksdk.exe, and only returned the GUI app that existed - with the same filename.

I had assumed a scaled down image might have been in play. In this case, I’m happy to have my mistake corrected. Although I haven’t needed to use a Hirens disk (for chkdsk) in a few years, I recall it being convenient for a number of other tasks on occasion.

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