'Unable to mount Filesystem' Error

Question

Trying to extract data from a 'bricked' Western Digital MyBook Live 2tb drive.

I came across a forum that advised to use Ubuntu (booted from a CD) on my Macbook. Managed to download and create a boot CD for Ubuntu (like this little operating system btw). Booted the machine with the CD and plugged the drive (which I had extracted from it's casing and placed into a external USB SATA case & plugged to the laptop). The drive is seen by Ubuntu but each time I click on the drive, it gives me the following error:

Unable to mount 2.0 TB Filesystem

Error mounting: mount: wrong fs type, bad option, bad superblock on /dev/sdb4, missing codepage or helper program, or other error In some cases useful info is found in syslog -try dmesg | tail or so

I am new to this and spent quite some time searching this site to see if I could find a solution to this problem without troubling anyone. I came up with a few that came close but some of the questioners mentioned that they had lost data...which scared me from going further. I need to basically extract 1 particular folder from the drive. If I can get to mount this volume 'sdb4', there is a folder called 'My_Work' which I need to back up. The rest I have/had a copy of.

When I typed in dmesg | tail...I got several lines..but I think ones that are relevant are:

[  406.864677] EXT4-fs (sdb4): bad block size 65536
[  429.098776] hfs: write access to a journaled filesystem is not supported, use the force option at your own risk, mounting read-only
[  439.786365] hfs: write access to a journaled filesystem is not supported, use the force option at your own risk, mounting read-only
[  445.982692] EXT4-fs (sdb4): bad block size 65536
[ 1565.841690] EXT4-fs (sdb4): bad block size 65536

I read somewhere to try/check 'sudo fdisk -l /dev/sdb4'. It gave me the following result:

Disk /dev/sdb44: 1995.8 GB, 1995774623744 bytes
255 heads, 63 sectors/track, 242639 cylinders, total 3897997312 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00000000

Disk /dev/sdb4 doesn't contain a valid partition table

This is where I reached and got frustrated and decided to try & get help on this without digging myself deeper into a hole! I understand that the answer may already be out there. If so, could someone please point me in the right direction. And if not, could someone please resolve (if possible) my situation!

Answer 1

For those who are still looking for an answer:

If your HDD is "bricked" and cannot be mounted properly, there are some things to do:

• make an image, if you have the space.
  Operating on an image file won't damage the data on your harddisk, in case you make mistakes and destroy your data.

• if you still can mount your partitions, mount it read-only.
  Alter the mount command like so: mount -o ro /dev/sdb1 /mnt/targetfolder

• If you cannot mount your harddisk's partitions, try extundelete or testdisk:
  sudo apt-get install testdisk extundelete. Then, run cd <recovery-dir>; sudo extundelete /dev/sdb1 or sudo testdisk /dev/sdb1 and follow the instructions to recover your data.

I successfully recovered data from a overridden raid 1 drive, so I can really recommend these tools.

Answer 2

It is likely the filesystem is hfs which is Mac OSX only and Ubuntu has issues reading and writing to, I would try and resolve the issue from within Mac OSX rather than Ubuntu.

I add the following as information only having just read an article listing the steps to recover from a bad superblock on an ext4 drive.

Try the folowing:

So, how can you recover a bad superblock? Fortunately for us, backup copies of the superblock are kept at certain offsets on the disk. To find out where the superblock backups are, open a terminal window and type:

sudo mke2fs -n /dev/????

Where ???? is the partition you want to check, which in my case was sdb3. This produces output, like the following:

Superblock backups stored on blocks: 32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208, 4096000, 7962624, 11239424, 20480000, 23887872

These are block numbers, signifying the location of the superblock backups.

To replace the superblock with one from a backup, type the following:

sudo e2fsck -y -b block_location /dev/????

Replace block_location with one of the above numbers and, again, ???? is the partition, so in my case it was sdb3.

There was significant corruption on my hard drive, but supplying the -y switch stopped fsck asking for confirmation every time it encountered a bad block.

After running this, I was able to mount the partition and recover my data.

Reference

Answer 3

I had a problem where my mybook live 2tb drive suddenly stopped working. To be honest, I was using it as a portable drive and was storing it away. When I took it out and plugged it back in to do a backup, the light when from blue to white to red and I tried everything in order to get it working. Everything the support site said and about 4 hours of messing around on the Internet reading all these forums and trying everything suggested. Here is what I learned:

Solution: (I'm previously computer literate but less so now as I'm older and have wasted enough of my life with this crap)

Whatever file system this is it is not Linux native ext2 or 3 or whatever, it is mac. It WILL NOT mount under Ubuntu, which is what I'm running and will continually give all these errors. when you access it eventually you will see all kind of .apple files.

Easy fix. Open up your piece of junk WD mybook drive, pull it out, undo the nic card, buy the SATA to usb adapter cord or the docking port from best buy, take it to a friends house that has a windows system, use the Linux file system reader from http://www.diskinternals.com/linux-reader/

install that, plug in the drive, when windows wants to format it hit CANCEL and run that program and voila there your files are.