External HDD (ntfs I think) will not mount

I have a moderately elderly WD “My passport ultra” external drive. And today I tried to mount it to see if it was still OK. I wouldn’t have been too surprised if there had been hardware errors while spinning up, but there weren’t (so that’s good). There were however some errors in dmesg:

[1037340.384549] sd 10:0:0:0: [sdi] Spinning up disk...
[1037345.030711] ses 10:0:0:1: Wrong diagnostic page; asked for 1 got 8
[1037345.030718] ses 10:0:0:1: Failed to get diagnostic page 0x1
[1037345.030721] ses 10:0:0:1: Failed to bind enclosure -19
[1037346.065167] .ready
[1037346.123967] sd 10:0:0:0: [sdi] 1953458176 512-byte logical blocks: (1.00 TB/931 GiB)

And then when I try to mount it I get

[1038433.077761] ntfs3(sdi1): Looks like $AttrDef is corrupted (size=36000).

I have tested 2 different USB cables & ports with the same result.

Info from fdisk:

Command (m for help): p
Disk /dev/sdi: 931.48 GiB, 1000170586112 bytes, 1953458176 sectors
Disk model: My Passport 259F
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: D5096138-6540-4FDE-9415-0AF57256C418

Device     Start        End    Sectors   Size Type
/dev/sdi1   2048 1953456127 1953454080 931.5G Microsoft basic data

Installed NTFS packages:

$ pacman -Qs ntfs
local/libntfs-3g 2026.7.7-1
    NTFS-3G core library
local/ntfs-3g 2026.7.7-1
    NTFS FUSE driver
local/ntfsprogs 2026.7.7-1
    NTFS userspace utilities

The disk used to work, and has only ever been used on Linux systems (and I think only Manjaro).

Can you plug the disk in a Windows system? If so, run:

chkdsk C: /f

You can add /r to check for defective sectors (much slower) if you suspect there are physical damages:

chkdsk C: /f /r

And the issue will be probably solved. In Linux there is Ntfsfix for these tasks, but its not usually recommended. Much safer chkdsk on a Windows computer.

The cause of your issue? It could be a power outage, unplugging before the file recording has finished, a writing failure, etc.

If you don’t have windows anymore, throw an iso on a ventoy flash drive

I’m sure this goes without saying … but I’ll say it anyway, just in case.
Make sure you know which drive letter to use in the chkdsk command. C: is your system disk, not your external drive.

Ooopppsss… that’s right. My fault. :+1:

That actually depends a bit of what and how is booted. In some PE live images the system disk is X so C could be an external one. It has to be checked.

A slight correction; and a reminder that chkdsk should be run from an administrative (elevated) Command/PowerShell prompt:


a) Scan for file system errors and correct them, if possible:

chkdsk /f x:
  • Substitute x for the correct drive letter
  • The disk must be locked; a reboot may be necessary

b) Scan for file system errors and bad sectors; repair if possible:

chkdsk /r x:
  • /r includes the /f functionality – /f is not needed.
  • Scanning for and repairing bad sectors can potentially take days, and can not be interrupted without great risk to your disk.

There are many more parameters than can be used with chkdsk, however, the two noted above are most common.

See the source of truth: :point_down:

The ntfs3 is likely a reference to the kernel driver and it will be used if not blacklisted.

I suggest you try adding a file /etc/modprobe.d/blacklist-ntfs3.conf with content

blacklist ntfs3

Detach the disk and reattach

Thanks for the suggestions. I’ll try on a machine with a slightly simpler topology than this one. I’m not comfortable enough with MS drive letters to risk it on a machine with many hard drives and mount points.

Here’s what I’ve found.
Hiren’s Boot CD won’t touch it.

  1. Refuses to mount.
  2. chkdsk /r F: in an admin shell, fails with:
Cannot find handle to event log.

(Message from memory not copied).

Backlisting ntfs3 works (presumably using the userspace driver).

Does this diagnosis make sense to anyone else?
That the userspace ntfs driver 10 years ago had a bug that resulted in some field not being correctly maintained. This field is required by the newer kernel driver and also by the real Windows driver, but not by the userspace driver.

That was to be expected.

The kernel driver has changed a lot in recent kernel iterations and the mentioned attribute $AttrDef may not have been read previously.

Remember this: the ntfs driver (in any version, user space or kernel) is a reverse engineered driver and without proper file system specification from the vendor (Microsoft) issues like this is to be expected.

Especially because the kernel driver takes priority unless blacklisted by the system administrator as in :backhand_index_pointing_right: You are the sysadmin.

Thanks,
I’ve marked your method as the solution.