2

A friend brought this WD My Passport external harddrive to me to see if I could recover her files. The device is "not working" after a power outage. As per her testimony, when the device is connected Windows "recognizes" the drive (whatever that means) but she "cannot see her files".

On my Ubuntu 14.10 machine, I get this far:

$ lsusb
Bus 004 Device 002: ID 1058:0748 Western Digital Technologies, Inc. My Passport 1TB USB 3.0

These two devices showed up while the drive was connected but disappeared after it was removed:

crw-rw----  1 root disk       21,   3 Jan 11 19:30 sg3
crw-------  1 root root       21,   4 Jan 11 19:30 sg4

I may have missed something else in /dev/ or in one of the subdirectories. I don't know if the following file is related as it remains even after unplugging the drive:

$ ls -la /dev/usb
crw-------  1 root root 180, 0 Jan 11 19:00 hiddev0

I disassembled the casing hoping to get a SATA or IDE interface to the drive, but the device has the USB 3.0 connection right on the PCB. There are what appear to be a few empty jumpers (like those found on older IDE drives) but they are not accessible from the outside of the casing.

What would be the next step to try to mount this drive? Ideally I'd like to dd its contents to a safe place then fsck with a bit of prayer. I'm not sure if the device is formatted FAT or NTFS as Western Digital seems to sell devices with either partition type. Might I do any additional damage if I try to mount /dev/sg3 or /dev/sg4 as the wrong type of FAT or NTFS?

Edit: The devices at/dev/sg3 and /dev/sg4 will not mount. Here is the result of the mount attempt:

$ ls -la | grep sg
drwxr-xr-x   2 root root           140 Jan 11 20:43 bsg
crw-r--r--   1 root root        1,  11 Jan 11 19:00 kmsg
crw-rw----   1 root disk       21,   0 Jan 11 19:00 sg0
crw-rw----+  1 root cdrom      21,   1 Jan 11 19:00 sg1
crw-rw----   1 root disk       21,   2 Jan 11 19:00 sg2
crw-rw----   1 root disk       21,   3 Jan 11 20:43 sg3
crw-------   1 root root       21,   4 Jan 11 20:43 sg4

$ mkdir ~/inbal

$ sudo mount -t ntfs /dev/sg
sg0  sg1  sg2  sg3  sg4  

$ sudo mount -t ntfs /dev/sg4 ~/inbal
[sudo] password for dotancohen: 
Error reading bootsector: Illegal seek
Failed to sync device /dev/sg4: Invalid argument
Failed to mount '/dev/sg4': Illegal seek

$ sudo mount -t ntfs /dev/sg3 ~/inbal
Error reading bootsector: Illegal seek
Failed to sync device /dev/sg3: Invalid argument
Failed to mount '/dev/sg3': Illegal seek

$ sudo mount -t vfat /dev/sg4 ~/inbal
mount: /dev/sg4 is not a block device

$ sudo mount -t vfat /dev/sg3 ~/inbal
mount: /dev/sg3 is not a block device
5
  • The drive should appear as /dev/sd… (sd letter), and (sd letter number) for the partitions. If you get some partitions then you can use fsck etc.
    – ctrl-alt-delor
    Jan 11, 2015 at 18:36
  • @richard: Thanks, I think that I've found the device under /dev/sg3 or /dev/sg4. I've updated the question.
    – dotancohen
    Jan 11, 2015 at 18:46
  • Attempting to mount the disk will usually not damage its contents. You should be explicit about the file format, for example using the -t flag with mount and an appropriate format, i.e., mount -t ntfs /dev/sg3 /mnt. Usually if the format isn't right, the OS will complain. Once you do mount it though, a dd should be fine to dump the contents.
    – user98877
    Jan 11, 2015 at 19:54
  • 2
    @franklin, I'd be doing the dd w/o mounting the disk. In fact I'd probably mount the disk READ ONLY first to access any possible damage.
    – mdpc
    Jan 11, 2015 at 20:00
  • @mdpc you're absolutely right. No mount is necessary to dd. Is OP trying to mount it to assess damage or to actually perform dd?
    – user98877
    Jan 11, 2015 at 20:03

1 Answer 1

Reset to default
1

I know this is an old question, and this answer should actually be a comment for which I do not have enough reputation, but I think one should give some kind of warning here:

Even an attempt to mount read-only can cause write accesses to the drive!

Best example is mounting a Reiserfs partition read-only (!): This will alter at least one byte on the disk as can easily be verified by compairing partition images taken before and after the mount. Just seen again with Reiserfs version 3.6.24. I guess that it is some sort of mount counter that is increased there.

I saw similar with older NTFS drivers, but there the changes on disk were reverted after unmounting the partition again. Please note: We are talking about read-only mounts!

So, when trying to rescue a disk, dd (or similar) comes before any mount attempts, even read-only ones.

Another obstacle in the case described in the question is the fact that the kernel was not able to establish any block devices to access the drive.

As you can see from the ls listings of /dev, the sg* files are character devices. These are used to communicate with the device on a lower level using SCSI commands. See for example the SCSI-Generic-HOWTO. Such devices can not be used in mount commands.

If there is no block device for that drive visible in /proc/partitions, the majority of diagnostic and rescue tools like Smartmontools, hdparm, testdisk, and even dd are ruled out.

I fear you need a really good wizard for that.

You must log in to answer this question.

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