Why is my external USB hard drive sometimes completely inaccessible?

Question

I have an external USB hard drive, consisting of an 1 TB SATA drive in a Rosewill RX35-AT-SU SLV Aluminum 3.5" Silver USB 2.0 External Enclosure, plugged into my SONY VAIO VGN-NS310F laptop. It is plugged directly into the computer (not through a hub). The drive inside the enclosure is a 7200 rpm Western Digital, but I don't remember the exact model. I can remove the drive from the enclosure (again), if people think it's necessary to know that detail.

The drive is formatted ext4. I mount it dynamically with udisks on my Lubuntu 11.10 system, usually automatically via PCManFM. (I have had Lubuntu 12.04 on this machine, and experienced all this same behavior with that too.) Every once in a while--once or twice a day--it becomes inaccessible, and difficult to unmount. Attempting to unmount it with sudo umount ... gives an error message saying the drive is in use and suggesting fuser and lsof to find out what is using it. Killing processes found to be using the drive with fuser and lsof is sometimes sufficient to let me unmount it, but usually isn't.

Once the drive is unmounted or the machine is rebooted, the drive will not mount. Plugging in the drive and turning it on registers nothing on the computer. dmesg is unchanged. The drive's access light usually blinks vigorously, as though the drive is being accessed constantly. Then eventually, after I keep the drive off for a while (half an hour), I am able to mount it again.

While the drive doesn't work on this machine for a while, it will work immediately on another machine running the same version of Ubuntu. Sometimes bringing it back over from the other machine seems to "fix" it. Sometimes it doesn't.

The drive doesn't always stop being accessible while mounted, before becoming unmountable. Sometimes it works fine, I turn off the computer, I turn the computer back on, and I cannot mount the drive.

Currently this is the only drive with which I have this problem, but I've had problems that I think are the same as this, with different drives, on different Ubuntu machines. This laptop has another external USB drive plugged into it regularly, which doesn't have this problem. Unplugging that drive before plugging in the "problem" drive doesn't fix the problem.

I've opened the drive up and made sure the connections were tight in the past, and that didn't seem to help (any more than waiting the same amount of time that it took to open and close the drive, before attempting to remount it).

Does anyone have any ideas about what could be causing this, what troubleshooting steps I should perform, and/or how I could fix this problem altogether?

Update: I tried replacing the USB data cable (from the enclosure to the laptop), as Merlin suggested. I should've tried that long ago, since it fits the symptoms perfectly (the drive works on another machine, which would make sense because the cable would be bent at a different angle, possibly completing a circuit of frayed wires). Unfortunately, though, this did not help--I have the same problem with the new cable. I'll try to provide additional detailed information about the drive inside the enclosure, next time I'm able to get the drive working. (At the moment I don't have another machine available to attach it.)

Major Update (28 June 2012)

The drive seems to have deteriorated considerably. I think this is so, because I've attached it to another machine and gotten lots of errors about invalid characters, when copying files from it. I am less interested in recovering data from the drive than I am in figuring out what is wrong with it. I specifically want to figure out if the problem is the drive or the enclosure.

Now, when I plug the drive into the original machine where I was having the problems, it still doesn't appear (including with sudo fdisk -l), but it is recognized by the kernel and messages are added to dmesg. Most of the message consist of errors like this, repeated many times:

[    7.707593] sd 5:0:0:0: [sdc] Unhandled sense code
[    7.707599] sd 5:0:0:0: [sdc]  Result: hostbyte=invalid driverbyte=DRIVER_SENSE
[    7.707606] sd 5:0:0:0: [sdc]  Sense Key : Medium Error [current] 
[    7.707614] sd 5:0:0:0: [sdc]  Add. Sense: Unrecovered read error
[    7.707621] sd 5:0:0:0: [sdc] CDB: Read(10): 28 00 00 00 00 00 00 00 08 00
[    7.707636] end_request: critical target error, dev sdc, sector 0
[    7.707641] Buffer I/O error on device sdc, logical block 0

Here are all the lines from dmesg starting with when the drive is recognized. Please note that:

• I'm back to running Lubuntu 12.04 on this machine (and perhaps that's a factor in better error messages).
• Now that the drive has been plugged into another machine and back into this one, and also now that this machine is back to running 12.04, the drive's access light doesn't blink as I had described. Looking at the drive, it would appear as though it is working normally, with low or no access.
• This behavior (the errors) occurs when rebooting the machine with the drive plugged in, and also when manually plugging in the drive.
• A few of the messages are about /dev/sdb. That drive is working fine. The bad drive is /dev/sdc. I just didn't want to edit anything out from the middle.

Solution 1

To determine whether the problem is the drive or the enclosure, remove the drive from the enclosure, install it in a desktop with sufficient power and check the smart status.

For a deeper test, you can check every sector of the drive utilizing tools like ddrescue. ddrescue will report error size during the process and you can attempt data recovery at the same time as in: sudo ddrescue /dev/sdb2 /path/to/recovery.image logfile. List the partitions with sudo lsblk or classic fdisk -l.

If you truly have no interest in the data you can force the output file to /dev/null as in:

sudo ddrescue --force /dev/sdc /dev/null logfile 

and you'll still get a report on any error size on stdout

Tested on Ubuntu 14.04 with GNU ddrescue 1.17 as follows inthis short example using /dev/sdb2 (a 1MB swap partition)

$ sudo ddrescue --force /dev/sdb2 /dev/null logfile


GNU ddrescue 1.17
Press Ctrl-C to interrupt
rescued:      1024 B,  errsize:       0 B,  current rate:     1024 B/s
   ipos:         0 B,   errors:       0,    average rate:     1024 B/s
   opos:         0 B,    time since last successful read:       0 s

Solution 2

I had similar experiences when I was running 12.04 Ubuntu desktop. My hard drive enclosure had 2 options for power, I could either buy an a/c adapter or use 1 mini usb to normal usb cable, or use a mini usb cable into two usb cables. Ideally it needed to be connected to both usb ports to supply ample power. It could transfer data over the usb cable or over eSata.

When using the eSata connection I needed to first supply the drive power so the disk was spinning and then boot the system so the bios would recognize the already spinning disk. Otherwise it would not see the disk in time. I believe this has something to do with the controller for the enclosure.

When I mounted the USB I had very mixed results when plugging the cable first into the enclosure and second into the USB ports. Maybe about half of the time it would mount correctly. If I plugged the usb cables into the pc ports first and then into the enclosure second I had much better results at around 70%. The best results I got with the USB options was using an external power source(a/c adapter) for the enclosure to make sure the disk was spinning and stable before I plugged it in to the machine. Worked pretty much 100%

Not saying that this is exactly your issue, but for me it helped to provide the enclosure power and have the disk spinning before connecting it to have it read be the system. Perhaps the bios or bus speed on your one system is better than the other and it give time for the enclosures controller to start working before it tries to read the disk? And perhaps some time after the enclosure is unplugged the controller resets itself?

Maybe the controller needs to time to decide whether it is just getting power from the USB's or power and data. Maybe its a voltage or amperage issue? Eitherway enclosure controllers seem to be finicky.

Comments

[Admin]

broken/dodgy cable?

[Admin]

Is the Drive SATA II or SATA III? Any BIOS or FIRMWARE Updates?

[Admin]

Can you check the S.M.A.R.T. status of that disk? If it can be recognised anywhere at all.

[Admin]

@Samik Even when the device is recognized, I don't seem to be able to do that.

[Admin]

@EliahKagan from your dmesg logs it can be seen that system repeatedly fails to read the first sector, the READ(10) instruction is failing. So it may be a bad sector growing there.

[Admin]

Eliah did this problem ever get solved? If so, can you post the solution?

[Eliah Kagan]

Thanks for the suggestions. Unfortunately: [1] sudo fdisk -l does not reveal anything about the drive. I wouldn't expect it to, since dmesg doesn't change from reattaching the drive. [2] I cannot manually mount a device that Ubuntu doesn't recognize as being attached at all. (Again, dmesg says nothing.) (This applies to udisks and pmount also.) Remember, it's not that the drive's partitions aren't being seen. The drive isn't being seen. [3] Why would I mount an ext4 volume as vfat?

[Eliah Kagan]

Although I couldn't follow these steps exactly, I believe this answer is both correct and best captures the nature of the problem I was having (though others are of value too, for different scenarios manifesting similarly). Eventually the drive stopped working altogether, I removed it from the (powered) enclosure, found it also didn't work (on multiple machines) when in another (powered) enclosure, and found another drive worked (on multiple machines) in the original enclosure. Since I couldn't get the problem drive recognized again, I didn't attempt to run ddrescue or check SMART status.

[Eliah Kagan]

The last time I powered on the drive I was still able to hear it spinning, yes.