How to Rescue Data Off the Disk Inside a WD MyBook Live NAS

Got a WD MyBook Live NAS with a broken NAS circuit board? Want to rescue your data off the standard 3.5” SATA disk inside the NAS enclosure? Tried mounting the block device on your Linux system and just got the kernel saying EXT4-fs (sdg4): bad block size 65536?

This article summarizes what I had to find out while I was in that situation.

Why you can’t just mount the filesystem

The Linux kernel driver for the ext4 filesystem only handles filesystems with a block size between 512 and PAGE_SIZE. On the common PC architectures x86_64 (64bit) and i386 (32bit), PAGE_SIZE is 4096 (4K). The filesystem on the WD MyBook Live hard disk has a block size of 65536 (64K), though, suggesting the WD MyBook Live comes with a CPU with a PAGE_SIZE of 65536.

So we cannot use the Linux kernel driver to read that ext4 filesystem on a normal PC/laptop.

Fortunately however, the userspace implementation libext2fs (used by debugfs(8)) is not limited by the kernel’s PAGE_SIZE and can therefore read the filesystem.

Update 2016-09-10: Chris Turchin suggests an even cooler approach: using the fuse driver for ext3 which allows mounting the filesystem like you mount any normal filesystem. I have not tried this fuse based approach, but the idea sounds quite promising and I will definitely follow up on it when I next find myself confronted with a 64K block size ext4 filesystem on a system with a smaller PAGE_SIZE. The following text still describes the steps I followed in 2012 to read the data off the disk using debugfs(8)/libext2fs.

What you need

  • Tools to extract the disk from the NAS enclosure

  • PC/laptop running a reasonably recent version of Linux (GPT support required)

  • A way to attach the disk from the NAS enclosure to that PC/laptop (e.g. SATA cable, USB enclosure + USB cable, etc.)

  • Sufficient amount of free storage space on the PC/laptop to hold a copy of all data from the NAS disk. Caution: This might amount to several TB.

What you do

  • Extract the disk from the NAS enclosure and connect it to your PC/laptop.

  • Create a new empty directory mkdir /path/to/saved-stuff on the free storage space where you will store the copy of the rescued data.

  • Run debugfs /dev/sdg4 (your device name will vary).

  • Inside debugfs(8), run the ls command to verify that you can see the shares directory. You can also look into the shares directory with the ls shares command.

  • Inside debugfs(8), run the rdump command as follows: rdump shares /path/to/saved-stuff. This will copy all the data from the shares directory on the disk from the NAS to your local free space as /path/to/saved-stuff/shares/.

  • Wait until the copying has finished. This will take many many hours if you have a lot of data to transfer, especially if you have the disk connected via USB 2.0.

A few unsorted remarks

  • sfdisk -l shows the primary partitions as if they were actual device names. As the disk uses GPT, these partition names have nothing in common with the actual device names.

  • According to the kernel sources, a PAGE_SIZE of 65536 is supported by the following architectures: ia64, mips, parisc, powerpc, sh, sparc. So you might also be successful running a mips64 Linux distribution inside qemu-mips and mounting the filesystem.

  • After unsoldering the sheetmetal shielding cage on the MyBook Live sytem board, I can identify the SOC to be an Applied Micro APM82181 (APM82181 product details). This appears to be a PowerPC based chip specifically designed for NAS applications.