1

This drive has been working fine for a while, but I recall having had some slight trouble getting it mounted in the past. Anyway, it was disconnected from the machine for some time and when I reconnected it and tried to mount it again with ntfs-3g, I got the following error:

Failed to mount '/dev/sdb1': Input/output error
NTFS is either inconsistent, or there is a hardware fault, or it's a
SoftRAID/FakeRAID hardware. In the first case run chkdsk /f on Windows
then reboot into Windows twice. The usage of the /f parameter is very
important! If the device is a SoftRAID/FakeRAID then first activate
it and mount a different device under the /dev/mapper/ directory, (e.g.
/dev/mapper/nvidia_eahaabcc1). Please see the 'dmraid' documentation
for more details.

So I plugged the drive into a Windows machine and ran chkdsk. While I don't have the output of chkdsk readily available, there were no obvious warning/error messages and I understood the output to have been indicative of a successful run. I could also mount, read, and write to the disk from within Windows Explorer.

I dismounted the drive, then plugged it back into the Debian box. Attempting to mount it had the same effect as the first time.

I plugged the disk into an OSX machine, which was able to read from (but obviously not write to) the drive. Plugging it back into the Windows machine seemed to indicate that all was well. After a few minutes however, the drive (mounted in Windows) became unresponsive and Windows Explorer gave me alternating error messages along the lines of "invalid parameters" and "access denied" (with no further detail!).

So I'm a little bit lost at this point. I can still read from the disk from several machines and write to it from Windows, but Debian still won't mount it. Any suggestions?

2
  • 1
    With the disk mounted on a Windows box, I'd do a chkdsk /F x:....that should clear up the problems and let you mount it.
    – mdpc
    Sep 3, 2014 at 6:15
  • @mdpc I've done that a few times, and it fixes the problem for the windows and OSX machines, such that I can mount and read/write from the drive properly - but this continues to happen when I plug the drive into the Debian box.
    – Libbux
    Sep 4, 2014 at 1:17

1 Answer 1

Reset to default
1

"Input/output error" points to a low-level problem that likely has little to do with the filesystem.

It should show up in dmesg and the output of smartctl -x /dev/sdX may also provide clues.

You can also try to strace -f -s200 ntfs-3g [args] 2>&1 | less to see which syscall hits the i/o error.

The root cause is probably one of the following:

  • defective SATA cable in Debian box;
  • problem with power supply or SATA power cable in Debian box;
  • failing disk;
  • bug in ntfs-3g causing it to try accessing beyond the end of the device (perhaps coupled with some weirdness in the specific NTFS volume you have that is somehow not affecting the other implementations);
  • defective RAM in Debian box.

If you post the output of the above commands, it may be possible to say which.

5
  • I can't use SMART since the drive is in an enclosure (although I've used it through enclosures before, this is weird), but I was able to mount it today. I don't know why it started working, but it did. I can't really speak for the integrity of the drive however, so I'll probably be picking up another drive or two for safety.
    – Libbux
    Sep 7, 2014 at 18:09
  • You could try smartctl -d usbcypress or -d usbjmicron or -d usbsunplus -- maybe one of them works with your enclosure.
    – András Korn
    Sep 7, 2014 at 18:37
  • None of those work either. I will post an update on the SMART status here if I take the drive out of the enclosure and plug it directly into a machine.
    – Libbux
    Sep 7, 2014 at 20:25
  • 1
    And dmesg is also silent about the i/o error? You can look up earlier errors in kern.log (or wherever your kernel log messages are sent).
    – András Korn
    Sep 7, 2014 at 21:27
  • This eventually worked, but I've just rebooted the server and encountered the issue again. This time, dmesg doesn't appear to be as silent: [ 1534.338657] sd 4:0:0:0: [sda] Bad block number requested (And so on for a very, very long time). What you said aboutntfs-3g trying to access blocks beyond the end of the device seems plausible, but I don't know why that would be. (Edit: another note of clarity, this time the server lost power -- but this appears to be a recurring issue, even with 'nice' reboots)
    – Libbux
    Oct 14, 2014 at 3:41

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .