Accessing USB drive with Linux

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:

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.

Oh... crap... this is a showstopper. (EDIT: Not so much, turns out. FUSE with fuse-ext2 works on Mac OS X and Linux to access ext3 filesystems with 16K blocks. See below for details.)

From forum post "Restore via Linux fails" (viewtopic.php?p=112519#p112519):

That means the data volume was created using RAIDiator 4 with a 16KB block size, and PCs can only handle 4KB. So that filesystem can only be mounted on architectures with a >=16KB page size. x86 won't cut it.

My external's ext3 filesystem definitely uses the 16K block size. From the output of dmesg following mount -t ext3 /dev/sdb1 /mnt/tmp on a Linux PC:

EXT3-fs: bad blocksize 16384.

Welp, I guess that's that. If you have access to an IA64, Sparc, Alpha, or another ReadyNAS handy (and possibly a newer Mac, possibly using MacFUSE and fuse-ext2), you might have a chance at reading off the data. Using fuse-ext2 with FUSE on Linux is also rumored to work, but I'm skeptical. (I'll follow up here if the Linux or Mac FUSE + fuse-ext2 actually works.) I guess the lesson learned here is to format the external using another Linux machine (to ensure the "least common denominator" 4K block size) before plugging it into the ReadyNAS and using it for backups--if you want it to be accessible from other machine architectures.

From what I gather reading the other ReadyNAS forums posts, 16K block size (supported by the Sparc ReadyNASes, like my NV+) became the default with RAIDiator 2.6 Linux kernels due to performance issues at 4K. So there's a possibility that either 4K will come back as an option in a later kernel, or else the Linux kernel will learn to deal with large block sizes irrespective of the machine architecture (patches for 2.6.2x kernels are mentioned here).

Other potentially useful resources on the interwebs:

• ReadyNAS forums: V4.1.5 Radiator - any chance 4K block size will return?


• serverfault.com: How do I mount ext2 or ext3 filesystems on OSX?


• serverfault.com: Mount an ext3 partition with a 16k blocksize?

[SOLUTION?] I can confirm that the fuse-ext2 module enables at least read-only access to ext3 filesystems with 16K block sizes, such as those created using Frontview on a ReadyNAS NV+ to format an external USB drive. I was able to mount and read files off my external drive with OS X 10.4 on a PowerPC Mac and Ubuntu 9.10 on a PC.

Tested software configuration:

• Mac OS X 10.4.11 (Tiger)


• MacFUSE 2.0.2 (installed using the .dmg here)


• fuse-ext2 0.0.7 (installed using the .dmg here)


• Ubuntu Linux 9.10 (Karmic)


• Ubuntu fuseext2 package, version 0.3-1, from the "universe" repository


• Official Ubuntu fuse-utils and libfuse2 packages, version 2.7.4-1.1ubuntu4.3

Instructions for Mac OS X:

1. Install MacFUSE, then install fuse-ext2 (a reboot was not required)


2. Determine the device file for the external USB drive and ext3 filesystem using Disk Utility. Mine was /dev/disk2s1.


3. Open Terminal and create a folder as a mountpoint--somewhere--for the ext3 filesystem. It doesn't matter where. Even /Volumes is okay, but OS X will remove the folder in /Volumes once you've unmounted the filesystem using Finder.
   

   mkdir "/Volumes/External Drive"



4. Open Terminal and run the following:

   fuse-ext2 -o ro /dev/disk2s1 "/Volumes/External Drive"



5. A new disk icon should appear on the desktop. Unmount it in the usual way when you're done.


Instructions for Linux (Ubuntu/Debian):

1. Ensure the "universe" repository is enabled in "Software Sources" (not required for Debian 5.0 "Lenny") and refresh the package listing if necessary (sudo apt-get update in a console). Install the fuseext2 package, which should pull down all the required dependencies:

   sudo apt-get install fuseext2



2. Determine the device file for the external USB drive and ext3 filesystem using fdisk (dash ell). Mine was /dev/sdb1.

   sudo fdisk -l



3. Create a mount point somewhere:

   mkdir ~/mnt/external



4. Run the following in a console (shell):

   sudo fuseext2 -o ro,allow_other /dev/sdb1 ~/mnt/external



5. Browse to the mount point using your file manager of choice. Use fusermount -u to unmount when you're done:

   sudo fusermount -u ~/mnt/external



Notes:

• The permissions on the external drive may not allow a normal user on the host computer access to all of the files. The easiest way around this is to copy the files somewhere else from inside a root shell (sudo -s), then change the permissions on the copies to (at least) 755 (rwxr-xr-x) for folders and 644 (rw-r--r--) for files.


• I did not test fuse-ext2's experimental read/write support, which is enabled using -o rw+ at the command line. Read the man page for more details.


• On a vanilla Debian system, you probably won't need to use sudo; just run those commands while logged in to a terminal as 'root.'


• For other Linux distros, use your package manager to search for "fuse" and/or "ext2" and install the appropriate package. (Debian "oldstable" [Etch] did not seem to have a fuse-ext2 package at all.) The other steps are the same, with the possible exception of the exact name of the "fuseext2" binary.

When doing this on my Mac I keep getting this error:

fuse-ext2: version:'0.0.7', fuse_version:'27' [main (../../fuse-ext2/fuse-ext2.c:324)]
fuse-ext2: enter [do_probe (../../fuse-ext2/do_probe.c:30)]
fuse-ext2: Error while trying to open /dev/disk3 (rc=2133571347) [do_probe (../../fuse-ext2/do_probe.c:34)]
fuse-ext2: Probe failed [main (../../fuse-ext2/fuse-ext2.c:340)]

Any idea on what goes wrong?

Experiencing same error, any ideas of a fix?

Snow Leopard, 1.5tb hd from ReadyNAS Ultra 6, 4.2.13, XRaid-2.

koikoi wrote:

When doing this on my Mac I keep getting this error: fuse-ext2: version:'0.0.7', fuse_version:'27' [main (../../fuse-ext2/fuse-ext2.c:324)] fuse-ext2: enter [do_probe (../../fuse-ext2/do_probe.c:30)] fuse-ext2: Error while trying to open /dev/disk3 (rc=2133571347) [do_probe (../../fuse-ext2/do_probe.c:34)] fuse-ext2: Probe failed [main (../../fuse-ext2/fuse-ext2.c:340)] Any idea on what goes wrong?

I have the same issue. My ReadyNAS went "corrupt root" on me and I attempted to do this to pull the data off.

One thing you'll notice is that there is no partition on your mounted disk (and its the same with mine). The example says "disk2s1", so a partition is required. You've entered "disk3" -> this has no partition information.

Either there is some issue with fuse where it doesn't show the parition, or the ReadyNas corrupted the partition so it can't be read.

This just worked for me - absolutely incredible. After 5 months I am currently copying files as we speak.

The only requirement is Ubuntu on a PC (I just downloaded it and burned a startup disk and installed a dual boot - it was crazy easy).

http://home.bott.ca/webserver/?p=306

Simple step by step guide to mounting Sparc-based ReadyNAS Drives in x86-based Linux:

Tested on brand new install of Ubuntu 10.10 (32bit x86), no other dependencies- 23rd Jan 2011

In a terminal window:

(1) sudo su
(2) apt-get install fuseext2
(3) apt-get install lvm2
(4) modprobe fuse
(5) vgscan
(6) vgchange -ay c
(7) fuseext2 -o ro -o sync_read /dev/c/c /mnt

That's it!!!
You can now see the mounted files in the /mnt directory

Sorry to revive an ancient thread, but I wanted to follow up on this....

I'm trying to access files from one of my ReadyNAS drives mounted via USB on my Mac. Using MacFuse as described, I can mount and view the root filesystem by mounting disk7s1. However, my shares appear as broken symbolic links pointint to /c/share-name. There are no files in /c. I've also mounted this under Linux on a friend's computer and followed the instructions there. It works as expected and I can view my shares and the files in /c without a problem.

What am I doing wrong on the Mac side? Is there some special configuration option I need to give to fuse-ext2 for this to work? Has anyone else managed to get this working correctly? I'm imagining that it has something to do with the non-standard block sizes...?