NETGEAR is aware of a growing number of phone and online scams. To learn how to stay safe click here.
Forum Discussion
rhabbott
Jun 05, 2010Aspirant
Accessing USB drive with Linux
I have a NV+ with external USB drive formatted in EXT3 where backup is copied to this drive. Power supply crapped out in NV+. :-( Plugged the USB drive into a Linux system (Fedora 9) which should...
kernst
Jun 16, 2010Aspirant
EDIT: The instructions below for using debugfs are still valid, but the ext2 FUSE module allows "native" access to the files (e.g., using Nautilus or Finder), which is a whole lot less painful.
I've had this problem twice, and I'm being bitten by it again as I type this: an inaccessible ext3-formatted external which has a complete offline mirror of my ReadyNAS. Fortunately this time, my ReadyNAS is just unplugged for the moment because I'm doing some rearranging in the "server room."
The last time this happened to me I was able to transfer a lot of data off of the external (onto another hard drive) by using the Linux debugfs utility. I specifically remember having to use the '-c' (open filesystem in "catastrophic" mode) when invoking debugfs:
Where "/dev/sdb1" is the device file for the ext3 filesystem on your external.
I know you know this already, but for the benefit of other, less-experienced readers--if you're not sure of the device file, try looking at the output of:
The sudo part may not be required if you're not on Ubuntu, but it's increasingly common these days. You will need to run as the 'root' user in any case. debugfs opens the device read-only by default, so you don't have to worry about making it any worse.
After opening the device (you'll know it worked if it doesn't throw up any errors), I used the cd, ls, and rdump commands at the debugfs: prompt to dump most of the files I needed to another mounted disk. So you aren't surprised at where debugfs tries to dump the files, it helps to start in your desired destination directory in the shell before running debugfs.
(EDIT: If it ain't broke, fix it till it is. In retrospect, there was probably nothing wrong with this drive to begin with, other than the 16K block size.) Since this failed external was only a backup, I had the luxury of being able to take some rather bold steps in my recovery efforts the last time. I do recall that (in my case) no amount of fscking would fix the filesystem, nor was the filesystem "magically" readable again when I got back home and plugged it into the ReadyNAS again (months later). I also recall trying several different vintages of bootable recovery CDs (e.g., SystemRescueCD, KNOPPIX) to rule out some incompatibility caused by the (older) ext3fs driver used on the ReadyNAS--no dice. At some point, I also ran badblocks -sv /dev/icefile (e.g., /dev/sdb1) and it didn't find any physical problems with the disk, so I ruled that out, too.
I can't imagine bit-rot or disk corruption happening this quickly--in a matter of weeks or months--but I guess I can't rule it out because it is a bargain-bin Hitachi external, so who knows. I'll go through some of the same steps again and report back here if the results are any different this time.
I've had this problem twice, and I'm being bitten by it again as I type this: an inaccessible ext3-formatted external which has a complete offline mirror of my ReadyNAS. Fortunately this time, my ReadyNAS is just unplugged for the moment because I'm doing some rearranging in the "server room."
The last time this happened to me I was able to transfer a lot of data off of the external (onto another hard drive) by using the Linux debugfs utility. I specifically remember having to use the '-c' (open filesystem in "catastrophic" mode) when invoking debugfs:
sudo debugfs -c /dev/sdb1
Where "/dev/sdb1" is the device file for the ext3 filesystem on your external.
I know you know this already, but for the benefit of other, less-experienced readers--if you're not sure of the device file, try looking at the output of:
sudo fdisk -l
The sudo part may not be required if you're not on Ubuntu, but it's increasingly common these days. You will need to run as the 'root' user in any case. debugfs opens the device read-only by default, so you don't have to worry about making it any worse.
After opening the device (you'll know it worked if it doesn't throw up any errors), I used the cd, ls, and rdump commands at the debugfs: prompt to dump most of the files I needed to another mounted disk. So you aren't surprised at where debugfs tries to dump the files, it helps to start in your desired destination directory in the shell before running debugfs.
(EDIT: If it ain't broke, fix it till it is. In retrospect, there was probably nothing wrong with this drive to begin with, other than the 16K block size.) Since this failed external was only a backup, I had the luxury of being able to take some rather bold steps in my recovery efforts the last time. I do recall that (in my case) no amount of fscking would fix the filesystem, nor was the filesystem "magically" readable again when I got back home and plugged it into the ReadyNAS again (months later). I also recall trying several different vintages of bootable recovery CDs (e.g., SystemRescueCD, KNOPPIX) to rule out some incompatibility caused by the (older) ext3fs driver used on the ReadyNAS--no dice. At some point, I also ran badblocks -sv /dev/icefile (e.g., /dev/sdb1) and it didn't find any physical problems with the disk, so I ruled that out, too.
I can't imagine bit-rot or disk corruption happening this quickly--in a matter of weeks or months--but I guess I can't rule it out because it is a bargain-bin Hitachi external, so who knows. I'll go through some of the same steps again and report back here if the results are any different this time.
Related Content
NETGEAR Academy

Boost your skills with the Netgear Academy - Get trained, certified and stay ahead with the latest Netgear technology!
Join Us!