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
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.
In future, itâs recommended to only use the official M$ tool 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):
@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.
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.
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;
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?
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
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.
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.
