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),
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
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
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-stuffon the free storage space where you will store the copy of the rescued data.
debugfs /dev/sdg4(your device name will vary).
debugfs(8), run the
lscommand to verify that you can see the
sharesdirectory. You can also look into the
sharesdirectory with the
debugfs(8), run the
rdumpcommand as follows:
rdump shares /path/to/saved-stuff. This will copy all the data from the
sharesdirectory on the disk from the NAS to your local free space as
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 -lshows 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_SIZEof 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-mipsand 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.