Chkdsk found no errors but Dolphin will not mount ntfs partition

I have a 1TB Sata SSD that is in a HDD caddy adapter with a USB cable that I plug in to my laptop running Manjaro to store files on. Today I plugged it in and it shows up in Dolphin and in blkid -o list from command line but when I click on the partition name in the Dolphin Removable Devices listing I get this error in Dolphin:

An error occurred while accessing ‘ntfs-share’, the system responded: The requested operation has failed: Error mounting /dev/sdc7 at /run/media/flex/ntfs-share1: wrong fs type, bad option, bad superblock on /dev/sdc7, missing codepage or helper program, or other error

I get this in dmesg:

ntfs3: sdc7: It is recommened to use chkdsk.
ntfs3: sdc7: volume is dirty and “force” flag is not set!

I loaded up Win 10 in a VM and ran chkdsk x: /r /x as advised here.

Win 10 using chkdsk reported no errors on that partition.
This SDD has several other partitions… exFAT and EXT4 and Dolphin is able to mount them fine.

I tried to clear the dirty bit like this, I it looks like it should have worked:

[flex@thinkpad ~]$ sudo ntfsfix -d /dev/sdc7
Mounting volume… OK
Processing of $MFT and $MFTMirr completed successfully.
Checking the alternate boot sector… OK
NTFS volume version is 3.1.
NTFS partition /dev/sdc7 was processed successfully.

But when I then try to open that NTFS partition from Dolphin I get the same errors in Dolphin and in dmesg.

This just started happening today, I have used this SSD in that sata/USB caddy many times before and Dolphin never had any problem with that NTFS partition before.

Finally…
I am able to mount the ntfs partition just fine in Manjaro from command line like this:
sudo mount /dev/sdc7 /mnt/ntfs-share/
Furthermore, my main system drive has an NTFS partition which Manjaro/Dolphin can mount just fine.

My Questions:

  1. Since Chkdsk reported no problems then why is dolphin still unable to mount this partition?
  2. Perhaps the drive does have some kind of failure, if so how can I confirm this?
  3. Do I need to set the force flag, will it be safe to do that?

Cheers,

Flex

Windoze things will be windoze … and I see multiple reports of people needing to run chkdsk particularly from recovery mode.

Example;

But ultimately these questions are likely better pointed to those kinds of support venues.

It was also advised not to use ntfsfix:

So, you’ve effectively cleared the dirty bit with ntfsfix and presumed that chkdsk would magically still work as expected.

All I can suggest is using fsutil to first check the status of the dirty bit.

If it has been cleared, set it again with fsutil, and after a reboot perform a typical scan/repair (chkdsk /f) on the NTFS partition (successful completion of a chkdsk repair will automatically clear the dirty bit).

If this fails to solve the issue, only then perform a check/repair for bad sectors (the /r option).

Regards.

@soundofthunder
I have made some more tests. Just trying to open the NTFS partition in Manjaro Dolphin is what is setting the Dirty bit and giving me the errors I reported above.

I booted up my Win 10 VM. Running this command confirmed the Dirty bit was set…

C:\Windows\system32>fsutil dirty query G:
Volume - G: is Dirty

I tried chkdsk /f G: and windows reported:

Windows has scanned the file system and found no problems.
No further action is required.
0 KB in bad sectors.

Now when I try to open that NTFS partition in Dolphin I get the same error as above.

After that I repeated the fsutil command which confirmed the dirty bit was set again and I then tried chkdsk G: /r /x which again found no problems as before but again trying to open the partition in dolphin gave the same errors with this in dmesg:

[ 1563.008694] ntfs3: sdc7: Mark volume as dirty due to NTFS errors
[ 1563.008811] ntfs3: sdc7: Failed to load $BadClus (-22).

I found one other mention of this $BadClus (-22) error on bbs.archlinux.org. The discussion mentions trying chkdsk /r /x /b to rebuild the $BadClus metadata in the NTFS partition which for some reason Windows has no problem with and neither does Manjaro if I use the mount command from the terminal? That discussion questions if maybe ntfs3 has a bug in it and to try using ntfs-3g instead?

use ntfsfix with switch -d on the problematic partition.

$ sudo ntfsfix -d /dev/sdXY

This might indicate the bad sector scan/repair failed to complete, or was unable to repair the problem. If the latter, it’s always possible that the disk cannot be repaired. Also possible is a faulty controller; in which case testing using a direct connection (not using the caddy) might produce better results.

ntfs-3g solves nothing; it will however, ignore the dirty bit if present. Many seem to mistake this for a solution, simply because ntfs-3g may allow an NTFS partition to mount when ntfs3 might not.

1 Like

I had bad experience with ntfs3, which corrupted my data whenever i performed renaming function - and the corruption would even happen on files not involved in renaming operation too.

ntfs-3g would be my choice - but when upgrading kernel, sometimes the upgrade would reset my preference, and revert the handler to ntfs3 without my realization. As a result, data corruption happens.

If you solely use the SSD on your Manjaro, you should consider to format it to ext4, or exFAT if you want to it to be cross-compatible with other OS.

Linux doesn’t have a tool to scan SSD.
You have to use Win OS to run some sector scan test to confirm the health status of your SSD.

Not sure about that. :wink: Check man smartctl; think this can check for errors.

Might need to install smartmontools first. sudo pacman -Syu smartmontools

I’m using GSmartControl, the GUI version of Smartctl.

For HDD, GSmartControl can perform self test and retrieve SMART status.
However, for SSD, GSmartControl can perform none.

chkdsk g: /x /b /v

It does display smart, wear, reserve, logs, selftests, errors, temp, unsafe shutdowns and pretty much everything on my nvme disk.

1 Like

Just to recap from my OP. I have a Crucial 2.5" Sata SSD with about 6 partitions on it. I was using it to dual boot Windows and Linux but at the moment I am using it in a USB Sata caddy as a kind of portable USB storage drive. Recently this happened that when I plug it in to Manjaro I can no longer access the Windows/NTFS partitions but all the other partitions are unaffected. I ran chkdsk on the drive in Win 10 and no errors were found.

I took advice in this thread and installed smartcl in Manjaro. However I was not able to get smartctl to work when my crucial Sata SSD was connecting via the USB to Sata adapter caddy.

I finally found another machine I could put the SSD in to connect directly via a sata connection and run smartctl from there and below are the results. It does give a warning Warning: ATA error count 0 inconsistent with error log pointer 1 but I don’t think that is a major hardware fault?

smartctl -a /dev/sda

root@zgemmah7:~# smartctl -a /dev/sda
smartctl 7.0 2018-12-30 r4883 [armv7l-linux-4.10.12] (local build)
Copyright (C) 2002-18, Bruce Allen, Christian Franke, www.smartmontools.org

=== START OF INFORMATION SECTION ===
Model Family: Crucial/Micron BX/MX1/2/3/500, M5/600, 1100 SSDs
Device Model: CT1000MX500SSD1
Serial Number: <>
LU WWN Device Id: 5 00a075 1e4b3e949
Firmware Version: M3CR033
User Capacity: 1,000,204,886,016 bytes [1.00 TB]
Sector Sizes: 512 bytes logical, 4096 bytes physical
Rotation Rate: Solid State Device
Form Factor: 2.5 inches
Device is: In smartctl database [for details use: -P show]
ATA Version is: ACS-3 T13/2161-D revision 5
SATA Version is: SATA 3.3, 6.0 Gb/s (current: 6.0 Gb/s)
Local Time is: Sat Dec 28 12:50:53 2024 GMT
SMART support is: Available - device has SMART capability.
SMART support is: Enabled

=== START OF READ SMART DATA SECTION ===
SMART overall-health self-assessment test result: PASSED

General SMART Values:
Offline data collection status: (0x82) Offline data collection activity
was completed without error.
Auto Offline Data Collection: Enabled.
Self-test execution status: ( 0) The previous self-test routine completed
without error or no self-test has ever
been run.
Total time to complete Offline
data collection: ( 0) seconds.
Offline data collection
capabilities: (0x7b) SMART execute Offline immediate.
Auto Offline data collection on/off support.
Suspend Offline collection upon new
command.
Offline surface scan supported.
Self-test supported.
Conveyance Self-test supported.
Selective Self-test supported.
SMART capabilities: (0x0003) Saves SMART data before entering
power-saving mode.
Supports SMART auto save timer.
Error logging capability: (0x01) Error logging supported.
General Purpose Logging supported.
Short self-test routine
recommended polling time: ( 2) minutes.
Extended self-test routine
recommended polling time: ( 30) minutes.
Conveyance self-test routine
recommended polling time: ( 2) minutes.
SCT capabilities: (0x0031) SCT Status supported.
SCT Feature Control supported.
SCT Data Table supported.

SMART Attributes Data Structure revision number: 16
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE
1 Raw_Read_Error_Rate 0x002f 100 100 000 Pre-fail Always - 0
5 Reallocate_NAND_Blk_Cnt 0x0032 100 100 010 Old_age Always - 0
9 Power_On_Hours 0x0032 100 100 000 Old_age Always - 641
12 Power_Cycle_Count 0x0032 100 100 000 Old_age Always - 902
171 Program_Fail_Count 0x0032 100 100 000 Old_age Always - 0
172 Erase_Fail_Count 0x0032 100 100 000 Old_age Always - 0
173 Ave_Block-Erase_Count 0x0032 100 100 000 Old_age Always - 6
174 Unexpect_Power_Loss_Ct 0x0032 100 100 000 Old_age Always - 161
180 Unused_Reserve_NAND_Blk 0x0033 000 000 000 Pre-fail Always - 29
183 SATA_Interfac_Downshift 0x0032 100 100 000 Old_age Always - 0
184 Error_Correction_Count 0x0032 100 100 000 Old_age Always - 0
187 Reported_Uncorrect 0x0032 100 100 000 Old_age Always - 0
194 Temperature_Celsius 0x0022 081 038 000 Old_age Always - 19 (Min/Max 0/62)
196 Reallocated_Event_Count 0x0032 100 100 000 Old_age Always - 0
197 Current_Pending_Sector 0x0032 100 100 000 Old_age Always - 0
198 Offline_Uncorrectable 0x0030 100 100 000 Old_age Offline - 0
199 UDMA_CRC_Error_Count 0x0032 100 100 000 Old_age Always - 0
202 Percent_Lifetime_Remain 0x0030 100 100 001 Old_age Offline - 0
206 Write_Error_Rate 0x000e 100 100 000 Old_age Always - 0
210 Success_RAIN_Recov_Cnt 0x0032 100 100 000 Old_age Always - 0
246 Total_Host_Sector_Write 0x0032 100 100 000 Old_age Always - 3631127882
247 Host_Program_Page_Count 0x0032 100 100 000 Old_age Always - 33383203
248 FTL_Program_Page_Count 0x0032 100 100 000 Old_age Always - 46218916

SMART Error Log Version: 1
Warning: ATA error count 0 inconsistent with error log pointer 1

ATA Error Count: 0
CR = Command Register [HEX]
FR = Features Register [HEX]
SC = Sector Count Register [HEX]
SN = Sector Number Register [HEX]
CL = Cylinder Low Register [HEX]
CH = Cylinder High Register [HEX]
DH = Device/Head Register [HEX]
DC = Device Command Register [HEX]
ER = Error register [HEX]
ST = Status register [HEX]
Powered_Up_Time is measured from power on, and printed as
DDd+hh:mm:SS.sss where DD=days, hh=hours, mm=minutes,
SS=sec, and sss=millisec. It “wraps” after 49.710 days.

Error 0 occurred at disk power-on lifetime: 0 hours (0 days + 0 hours)
When the command that caused the error occurred, the device was in an unknown state.

After command completion occurred, registers were:
ER ST SC SN CL CH DH


00 ec 00 00 00 00 00

Commands leading to the command that caused the error were:
CR FR SC SN CL CH DH DC Powered_Up_Time Command/Feature_Name


ec 00 00 00 00 00 00 00 00:00:00.000 IDENTIFY DEVICE
ec 00 00 00 00 00 00 00 00:00:00.000 IDENTIFY DEVICE
ec 00 00 00 00 00 00 00 00:00:00.000 IDENTIFY DEVICE
ec 00 00 00 00 00 00 00 00:00:00.000 IDENTIFY DEVICE
c8 00 00 00 00 00 00 00 00:00:00.000 READ DMA

SMART Self-test log structure revision number 1
Num Test_Description Status Remaining LifeTime(hours) LBA_of_first_error

1 Short offline Completed without error 00% 421 -

SMART Selective self-test log data structure revision number 1
SPAN MIN_LBA MAX_LBA CURRENT_TEST_STATUS
1 0 0 Not_testing
2 0 0 Not_testing
3 0 0 Not_testing
4 0 0 Not_testing
5 0 0 Not_testing
Selective self-test flags (0x0):
After scanning selected spans, do NOT read-scan remainder of disk.
If Selective self-test is pending on power-up, resume after 0 minute delay.

root@zgemmah7:~#

I tried two other commands in Manjaro but I’m not sure what the output means!

sudo hdparm -N /dev/sdc

[flex@thinkpad ~]$ sudo hdparm -N /dev/sdc

/dev/sdc:
SG_IO: bad/missing sense data, sb: 70 00 04 00 00 00 00 0a 00 00 00 00 4b 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
max sectors = 1953525168/1(1?), HPA setting seems invalid (buggy kernel device driver?)

sudo gdisk /dev/sdc

[flex@thinkpad ~]$ sudo gdisk /dev/sdc
GPT fdisk (gdisk) version 1.0.10

Partition table scan:
MBR: protective
BSD: not present
APM: not present
GPT: present

Found valid GPT with protective MBR; using GPT.

Command (? for help): ?
b back up GPT data to a file
c change a partition’s name
d delete a partition
i show detailed information on a partition
l list known partition types
n add a new partition
o create a new empty GUID partition table (GPT)
p print the partition table
q quit without saving changes
r recovery and transformation options (experts only)
s sort partitions
t change a partition’s type code
v verify disk
w write table to disk and exit
x extra functionality (experts only)
? print this menu

Command (? for help): v

No problems found. 3437 free sectors (1.7 MiB) available in 2
segments, the largest of which is 2014 (1007.0 KiB) in size.

Command (? for help):

But still if I try to open the windows/NTFS partitions from Dolphin file manager it gives me an error. This is what I see in dmesg.

[57681.622231] ntfs3: sdc7: It is recommened to use chkdsk.
[57681.625922] ntfs3: sdc7: volume is dirty and “force” flag is not set!
[57685.955489] ntfs3: sdc3: It is recommened to use chkdsk.
[57685.960794] ntfs3: sdc3: volume is dirty and “force” flag is not set!

If I try to mount the Windows partition manually from the Manjaro command line it works fine:

sudo mount /dev/sdc7 /mnt/public

Did a recent update change something in Dolphin I wonder? Or maybe I need to just reformat that whole drive because it has some software corruption? I would much appreciate if anyone can advise me?

ntfs is not a native Linux filesystem but a proprietary Microsoft filesystem.

It has been mentioned over and over - do not use ntfs outside Microsoft Windows - if you must have cross-platform data-exchange use a supported filesystem - fat32 (limited to 4G filesize) or exFAT (no limitation in filesize).

The kernel driver [ntfs3] is reverse engineered by [Paragon Software] and it will refuse to mount or mount read-only if the filesystem reports the slighest error. Paragon offers a free ntfs driver - I cannot say if it is worth it - I don’t use ntfs.

The [ntfs-3g] driver is a bit more relaxed and is preferred by some over the kernel driver.

This behaviour is by-design - it protects the foreign filesystem from further corruption - it is to safeguard your data.

2 Likes

I hear you and thanks for the advice and feedback. But this is one of those situations where I don’t care that I have at least two workarounds that might be more appropriate. I still want to know why suddenly Dolphin won’t mount the Windows partition on that SSD when it was able to do so a few weeks ago.

As an academic exercise it would be interesting to be able to diagnose if it is a hardware or software fault. Why is ntfs3 not happy with it? Is it maybe the partition table or some metadata etc.

I can backup the data off that drive, format and re-partition it again and report back if that fixed the issue. Would be nice to rule out a hardware fault altho I think smartctl has done that already.

Cheers.

The output of this means little, as it stands; though we can see that the disk is properly configured as GPT, so that’s something. Printing (p) the partition table might have given a useful overview of the partitions on the disk; and (i) might have given more detailed information of a particular partition, if needed.

This indicates (to me) that you have removed the dirty bit from these two NTFS filesystems; resultant from using ntfsfix (or similar) despite the general warnings.

As probably already mentioned, you could use fsutil to force the dirty bit on those NTFS filesystems; and then run chkdsk.

With the dirty bit set chkdsk will run the necessary checks/repairs properly. Without it set, chkdsk functionality may be impaired.

You could certainly run chkdisk set to check for bad sectors. Remember that each time you run chkdsk, if it completes successfully, the dirty bit is also cleared.

If you wish to run another scan/repair or bad sector scan/repair, you will need to force the dirty bit again before proceeding.

You could certainly try that; of course you should check the consistency of any NTFS filesystems again with chkdsk, when finished.

This in particular from your earlier provided outputs:

shows that you have bad sectors (bad clusters).

Are these repairable? Maybe, sometimes, using the appropriate chkdsk commandline. But, not always; it depends on the extent of damage.

Dolphin only knows what the system tells it. In this case, that a dirty bit indicates that NTFS filesystems are likely damaged. Dolphin likewise relays the error to you.

You have two Windows tools to experiment with. For academic purposes, knock yourself out.

The only variation from that already suggested is:

Do not use a Windows VM in this instance; try to test in a regular Windows environment, with the disk in question connected directly to a SATA connector on the mainboard rather than within a USB enclosure with a possibly questionable controller.

Ultimately, this seems the easiest. If you choose the NTFS route (again) remember to test it with chkdsk (and fsutil as needed).

If you must have a Microsoft compatible filesystem to work with, then EXFAT (as suggested by @linux-aarhus ) is certainly a viable option; albeit not as robust as NTFS, many consider EXFAT a more troublefree alternative.

Regards.

1 Like

I have no academic interest in ntfs on Linux - why and how it fails - You Do What You Got To Do

:slight_smile:

  • ntfs is for Windows
  • apfs and hfs+ is for Apple
  • ext2, ext3, ext4, btrfs, f2fs, zfs, xfs and more is for Linux

Then there is FAT which, to my knowledge is opensource (Microsoft patented using long file names with FAT (vfat or FAT32)) and exFAT which Microsoft kept proprietary until 2019 where it was included in the Linux kernel.

exFAT in the Linux kernel? Yes! - Microsoft Open Source Blog
exFAT - Wikipedia

While the EFI specification says FAT32 this only pertains to the possibility of using long filenames and FAT16 work equally good for the $esp.

exFAT being in the Linux kernel does not guarantee problem free function as Microsoft still owns patents on key functionality of the filesystem. It is nonetheless a better alternative, with respect to platform interoperability, than ntfs where the specification is proprietary.

1 Like