2

Note: This situation is evolving. Please see the output at the end of this question for the current situation.

I'm using Linux Mint 14. Recently, I repartitioned one of my hard drives, and I backed up all my data to an external USB 500GB drive. Now I am trying to copy that data back.

However, the drive is behaving strangely. When I plug it in, it shows up on my desktop:

USB drive on desktop

... but when I right click and select to view "Properties", underneath the "Permissions" tab, it says:

The permissions of "USB500" could not be determined.

The permissions of "USB500" could not be determined

Also, it shows that 359.7 GB of the drive is used, which is about the right amount for the data I backed up:

Data used

... but, when look into the drive, most of the files are not visible to me. For example, when I look at the properties of the "dave" directory, where most of my files are backed up, it says it's only 1.3 MB in size:

folder properties

There should be more like 300GB in that folder.

Why are most of my files seemingly missing when the data used on disk is so much larger? Why is the permissions not determined?

Most importantly, what is the safest process for me to diagnose problems and retrieve the data off this disk?


Update: This output was requested in an answer below:

$ mount | grep USB500
/dev/sdd1 on /media/dave/USB500 type ext4 (rw,nosuid,nodev,uhelper=udisks2)

When I ran the following command, I got a huge stream of lines that ended with Input/output error (too many to reproduce here, but they're all basically the same):

$ sudo find /media/dave/USB500 -ls | less
find: `/media/dave/USB500/dave/.guayadeque': Input/output error
find: `/media/dave/USB500/dave/.compiz-1': Input/output error
find: `/media/dave/USB500/dave/.anthy': Input/output error
find: `/media/dave/USB500/dave/.compiz': Input/output error
find: `/media/dave/USB500/dave/Apache_Logs': Input/output error
find: `/media/dave/USB500/dave/.avidemux': Input/output error
find: `/media/dave/USB500/dave/.dvdrip': Input/output error

On the one hand, this seems to indicate a possible hardware failure(?). On the other hand, it is listing all the files I'm hoping to recover... so is it possible they are accessible? I really hope so...


Update 2: I tried running fsck in hopes of repairing the drive and recovering at least some data, but I got this response:

$ sudo fsck -y /dev/sdb
fsck from util-linux 2.20.1
e2fsck 1.42.5 (29-Jul-2012)
fsck.ext2: Attempt to read block from filesystem resulted in short read while trying to open /dev/sdb
Could this be a zero-length partition?

Sometimes the drive does not seem to mount, I have not determined a pattern as to what causes it to become un-mountable. After turning it off and on, or after a reboot, I seem to be able to get it back.

I removed the hard drive from it's USB interface and connected it to the computer's internal P/SATA bus, but it seemed that the drive behaved exactly the same, with identical symptoms.

I believe this drive is dying, so right now the goal is to try to find some way to access the data that should be there just long enough to copy as much of it as possible. Suggestions on how I might do that would be most appreciated. There are actually just a few key directories I would like to access, so hopefully, if the failure is not too global, I might be able to get what I need.


Update 3: I'm currently running the following command. I started it a day ago, and it's still going. I hope it is doing something useful. If anyone can confirm for me what the output below indicates about its progress, that would be very helpful.

$ sudo ddrescue -r3 /dev/sdb /home/dave/RECOVERY/usb500.image
/home/dave/recovery_usb500.logfile


Press Ctrl-C to interrupt
Initial status (read from logfile)
rescued:         0 B,  errsize:       0 B,  errors:       0
Current status
rescued:         0 B,  errsize:    500 GB,  current rate:        0 B/s
   ipos:     5366 MB,   errors:       1,    average rate:        0 B/s
   opos:     5366 MB,     time from last successful read:       1 d
Splitting failed blocks...
4
+50

I think your next steps depend on how valuable the data on the drive is.

If its fairly valuable, your next step should be to stop attempting recovery and instead contact a data recovery firm. Hopefully it's just the electronics on the PCB failing, in which case they ought to be able to do a full recovery relatively inexpensively.

If you're not going to do that, your goal should be to get an image of as many sectors as you can from the failing drive. (You'll need a drive larger than 500GB to store it, but that shouldn't be a problem).

If you have an exactly identical drive (that works), you could try borrowing the PCB from the working drive. You'll want to practice swapping the PCBs on drives that don't contain important data first, to make sure you know what you're doing.

Otherwise, you can try tools like dd_rescue/myrescue/gddrescue/etc. It may be that the drive works for a bit, then completely dies, in which case you'll have to do many passes, getting more sectors each reset/power cycle.

Once you have an image of the drive, your next step is to make a copy of that image, and work on the copy.

I'd suggest you try to fsck the copy, then loop mount it.

  • Thank you for these suggestions. I am currently running ddrescue, and it has been going for over a day. I can hear the disk running, and it is still generating output at the command line, but I can't discern if it is doing anything truly useful. I've added the output to my question. – Questioner Jun 4 '13 at 10:30
3

It looks like you either made a backup with a different user, or that the permissions now assigned to the drive are different.

First you should note the result of:

mount | grep USB500

(and probably extend your question with that) After that can mount the drive read only by doing:

sudo mount -o remount,ro /media/dave/USB500

and get a listing of what is on there again as root:

sudo find /media/dave/USB500 -ls | less

and try to see if all the data is there and if there are ownership/permission problems on the data.

  • This. My first guess would definitely be a ugid mismatch problem between the two installs. It's reasonably easy to write a short script to map from one to the other if you have both the new and old /etc/passwd and /etc/group files, and the usernames and group names are identical (only the IDs being different). – a CVn May 27 '13 at 12:44
  • @MichaelKjörling I agree that it smells of a reinstall, but the OP did not mention that, just a repartition. You are of course right that it is easy (just by changing the order of making the users) to get different UIDs even when installing the same distro and revision. – Anthon May 27 '13 at 12:48
  • I read the opening paragraph as involving a reinstallation, but looking at it again you are right it does not have to involve one. That said I still would take a close look at ugids first. ls -nl is your friend, too (don't know if find's -ls has a switch similar to ls's -n). – a CVn May 27 '13 at 12:53
  • Thank you for responding. I ran the commands you suggested, and added their output to my question. I hope there is a way the files can be recovered. Please let me know if the new output reveals any way forward. – Questioner May 27 '13 at 17:54
  • 1
    Input/Output Errors is certainly not good, but does not have necessarily mean that the data is no longer there. I have that sometimes with my external drive the USB ports are not recovering until a reboot. Have you rebooted (full cold start, after power off)? Do you have a chance to hook the drive up to another system. – Anthon May 27 '13 at 18:00
2

Even if you have an exactly identical drive, it's possible the firmware are just a few versions off and it will still puke. However, there are a few things you can do. If you suspect the drive failed due to a power surge, there is what's known as a Crowbar Circuit that often dies and prevents the drive from functioning so the data itself doesn't get harmed. Each manufacturer has a different circuit on their boards, though, so it would be up to you to determine where it is and how to remove it (snips or solder sucker).

The easier route, and I know this sounds absurd but I have personally tested this (I used to write software to wipe hard-drives and also worked on a team designing tech to bring them back), you can put it in the freezer overnight, and plug it in the next day. Often the platters or arm get out of whack or off-balance, and the constricting nature of the cold can often allow them to perform just long enough to get your data.

Lastly, if you feel adventurous and are willing to spend a little time and a tiny bit of money (for the USB-TTL 5v module), you can communicate with the drive, attempt to flash a new firmware, and see if that brings it back. A guide (which I have performed and DOES work) is here: http://www.overclock.net/t/457286/seagate-bricked-firmware-drive-fix-with-pics

  • 1
    Also try 1.) plugging drive directly in the computer, skipping the USB madness. 2.) Getting the same exact drive and replacing the logic board on the faulty drive. – David May 31 '13 at 17:04
  • Or, replacing the platters. – Jacob Coleman Jun 3 '13 at 20:36
0

Have you tried to recover the data? If not you can check the link for file recovery: Data Recovery Using dd_rhelp

(Sorry I'm not sure if it's correct to provide alternate solution)

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.