How can I fix an inconsistent NTFS file system without Windows?

Question

I have a Dell laptop that came with Windows from the factory. Since then, I have installed Linux and replaced the hard drive with an SSD. The NTFS partition is inconsistent (a result of bad sectors on the HDD) and needs to be fixed, but I cannot boot into Windows to run chkdsk.

How do I fix this problem? Until I do, I cannot move my NTFS partition to expand space on my root filesystem, which is critically low.

EDIT:

All of my partitions were cloned from my dying HDD to my SSD via Clonezilla. There are no bad sectors on the SSD, but the NTFS partition is still in an inconsistent state.

Solution

If the computer has nothing but Linux, you should not be using NTFS. There are no good Linux tools for repairing NTFS damage. (The Linux ntfsfix tool just does some very basic checks and then flags the filesystem as needing more attention from Windows.) Thus, in the long term your goal should be to switch from NTFS to a Linux-native filesystem. In the short term, you should use a Windows emergency disk to repair the filesystem. (Such emergency disks are widely available, but I don't happen to have any URLs handy. Maybe you can find one by searching Microsoft's site.) It's conceivable that you could use ntfsclone to make a backup, too; see the --rescue option in its man page. I've never tried this, though.

Overall, I'd say you should do the following:

1. Use a Windows emergency disc, ntfsclone, or any other tool necessary to gain access to the partition.
2. Copy the files from that partition to another disk. You can do this in either Linux or Windows, depending on what's convenient and how you got access to the disk.
3. Create a Linux-native filesystem (ext2/3/4fs, ReiserFS, XFS, JFS, or maybe even Btrfs) on the partition.
4. Copy the files back to the original (but freshly-prepared) partition.

Comments

[Rudolph]

I think my answer over here could explain it: superuser.com/questions/665214/…

[ganesh]

Is deleting and recreating the NTFS partition with mkfs.ntfs an option? -- Alsom Rudolph has a good point about reliability. A HDD which shows bad sectors is a very bad sign. Make sure that you have backups.

[Rod Smith]

I read the question as saying that the hard disk with bad sectors is no longer in use, but damage from the bad sectors persists on the NTFS volume that's been copied to the SSD. If this reading is incorrect, then I definitely agree with Hennes. A disk with bad sectors is like a slice of bread with mold; the problem will only get worse with time.

[Demi]

Update: I managed to boot into Windows and run chkdsk. My partition now works.

[Demi]

Tried that. no luck.

[Mikko Rantalainen]

2.5. Overwrite the whole partition with bad blocks with something (e.g. dd if=/dev/zero of=... bs=1M or at last dd bs=4K). That will fix the bad blocks if the HDD still has internal physical reserve blocks available. If not, do not use that drive to store any data you want to keep. The smartctl -x may allow checking the remapped sector count.

[Rod Smith]

I missed the reference to bad blocks in the original post. The original disk should be thrown away; any disk with bad blocks is unreliable. Such problems tend to get worse with time. Thus, step 2.5 should be "Buy a new disk." The suggestion of using dd to zero it out will be a temporary band-aid, at best; it will cause the disk to map out the current set of bad blocks, but such problems tend to get worse, so the problem is almost certain to recur.

[Mikko Rantalainen]

It's possible that a disk contains one or two bad blocks because of manufacturing errors. In that case the disk is okay and remapping is the correct fix. This is no different from an LCD display with a dead pixel. However, I do agree that if new bad blocks appear after using the disk, it should be thrown away.

[Rod Smith]

All modern disks automatically map out bad blocks, up to some predetermined limit (the number of sectors set aside for this purpose). Thus, "one or two" bad blocks won't even show up. If you're seeing bad blocks, you've exceeded the design limits of the disk and have many more bad blocks than that. Such a disk should be thrown away. The only times I've seen bad blocks appear on disks, the entire disk has become completely useless in somewhere between hours and a few months.

[Mikko Rantalainen]

Bad blocks do show up because not even the disk firmware can know that a block is bad before suitable data is written to it and later a read command follows to read the same block back. I know because I had just that situation for one HDD. That disk had a single bad block that got remapped once I overwrote that sector with new data. The way HDD detects a bad block is that after reading a block, it checks the internal checksum for that block and if the checksum does not match, the read is automatically retried a few times. Read error is reported if repeated read cannot get the checksum to match

[Mikko Rantalainen]

I wrote "suitable data" because sometimes the bad block may have only a bit error (e.g. one bit in 4096B physical sector is always zero) and if the data to be written happens to contain suitable bit for that error, the problem is never seen. This is very similar to RAM problems where only some very specific bit pattern fails.

[Rod Smith]

I understand what you're saying, Mikko; but in my experience, I've had bad blocks show up from time to time on disks I've used, and be remapped. EVERY TIME I've noticed such problems, the disk has been COMPLETELY DEAD in 6 months or less. IN MY EXPERIENCE, trying to recover a disk once you notice bad blocks is a hopeless and dangerous endeavor.

[Mikko Rantalainen]

I would claim that trusting any single device to keep your data is a dangerous endeavor. I agree that a device with even a single remapped bad block has higher probability of failing than a device with zero bad blocks. However, due to nature of these devices, any single device may fail at any moment without any issues beforehand. Always keep a backup on an another device.