3TB MyBookLive is holding all my data hostage

WD Legacy Products My Book Live

olyvaha June 2, 2014, 10:55pm 1

Firmware 02.43.03-022 : Core F/W

One morning I came to it and in FInder (Mac OS X 10.9.3) says that it can’t connect. Weird. I try the My Cloud App, it connects but doesn’t load correctly. The Dashboard loads fine, shows no data in the Shares sections, but shows that 1.1 TB is being used of the 3 TB available. Tried on Windows & through Boot Camp and then on a HP running Windows 8, both Windows Explorers say can’t connect to the drive either. So whew not a Mac issue, def drive issue.

I reset it on the back, wait and then try connecting again on all computers. Nothing still.

I enable SSH and go looking for the data in PuTTY. I get in there and it shows this:

I am not familiar with with this and am havign trouble finding much info on what this even means, it looks to me like permissions got out of whack. Is there anyway to repair them? I was referred to data recovery specialists by WD’s Level 2 support who didn’t want to proceed further because data loss can incur, at this point I am fine with that, I called one of the companies the cheapest price they even had was in the $600s which is outrageous and I can’t afford that, so free options it is.

I have this as a plan B if I can’t find any safer solutions:

Basically you do a reinstall of the firmware with a noreformat tag to keep the data, the Level 2 said that used to be an option but with this new firmware it can go wrong and delete everything.

Does anyone have any suggestions on this? Any help would be appreciated!

TonyPh12345 June 3, 2014, 12:13am 2

From the location you’re already at in the screenshot above (DataVolume folder) what happens after

chmod 777 shares

command?

Can you then ls and get normal output?

olyvaha June 3, 2014, 12:29am 3

i get “chmod: cannot access ‘shares’: Input/output error”

TonyPh12345 June 3, 2014, 12:38am 4

That’s usually not a good sign… Try the command again to trigger the io error.

Then issue the command

dmesg

And paste the last few dozen lines you get

olyvaha June 3, 2014, 12:47am 5

EXT4-fs error (device sda4): ext4_lookup: deleted inode referenced: 14622721

EXT4-fs error (device sda4): ext4_lookup: deleted inode referenced: 14622721

EXT4-fs error (device sda4): ext4_lookup: deleted inode referenced: 14622721

EXT4-fs error (device sda4): ext4_lookup: deleted inode referenced: 14622721

EXT4-fs error (device sda4): ext4_lookup: deleted inode referenced: 14622721

EXT4-fs error (device sda4): ext4_lookup: deleted inode referenced: 14622721

EXT4-fs error (device sda4): ext4_lookup: deleted inode referenced: 14622721

EXT4-fs error (device sda4): ext4_lookup: deleted inode referenced: 14622721

EXT4-fs error (device sda4): ext4_lookup: deleted inode referenced: 14622721

EXT4-fs error (device sda4): ext4_lookup: deleted inode referenced: 14622721

EXT4-fs error (device sda4): ext4_lookup: deleted inode referenced: 14622721

EXT4-fs error (device sda4): ext4_lookup: deleted inode referenced: 14622721

EXT4-fs error (device sda4): ext4_lookup: deleted inode referenced: 14622721

EXT4-fs error (device sda4): ext4_lookup: deleted inode referenced: 14622721

EXT4-fs error (device sda4): ext4_lookup: deleted inode referenced: 14622721

MyBookLive:/DataVolume# EXT4-fs error (device sda4): ext4_lookup: deleted inode referenced: 14622721

-bash: syntax error near unexpected token `(’

MyBookLive:/DataVolume# EXT4-fs error (device sda4): ext4_lookup: deleted inode referenced: 14622721

-bash: syntax error near unexpected token `(’

MyBookLive:/DataVolume# EXT4-fs error (device sda4): ext4_lookup: deleted inode referenced: 14622721

-bash: syntax error near unexpected token `(’

MyBookLive:/DataVolume# EXT4-fs error (device sda4): ext4_lookup: deleted inode referenced: 14622721

-bash: syntax error near unexpected token `(’

MyBookLive:/DataVolume# EXT4-fs error (device sda4): ext4_lookup: deleted inode referenced: 14622721

-bash: syntax error near unexpected token `(’

MyBookLive:/DataVolume# EXT4-fs error (device sda4): ext4_lookup: deleted inode referenced: 14622721

-bash: syntax error near unexpected token `(’

MyBookLive:/DataVolume# EXT4-fs error (device sda4): ext4_lookup: deleted inode referenced: 14622721

-bash: syntax error near unexpected token `(’

MyBookLive:/DataVolume# EXT4-fs error (device sda4): ext4_lookup: deleted inode referenced: 14622721

-bash: syntax error near unexpected token `(’

MyBookLive:/DataVolume# EXT4-fs error (device sda4): ext4_lookup: deleted inode referenced: 14622721

-bash: syntax error near unexpected token `(’

MyBookLive:/DataVolume# EXT4-fs error (device sda4): ext4_lookup: deleted inode referenced: 14622721

-bash: syntax error near unexpected token `(’

MyBookLive:/DataVolume# EXT4-fs error (device sda4): ext4_lookup: deleted inode referenced: 14622721

-bash: syntax error near unexpected token `(’

MyBookLive:/DataVolume# EXT4-fs error (device sda4): ext4_lookup: deleted inode referenced: 14622721

-bash: syntax error near unexpected token `(’

MyBookLive:/DataVolume# EXT4-fs error (device sda4): ext4_lookup: deleted inode referenced: 14622721

-bash: syntax error near unexpected token `(’

MyBookLive:/DataVolume# EXT4-fs error (device sda4): ext4_lookup: deleted inode referenced: 14622721

-bash: syntax error near unexpected token `(’

MyBookLive:/DataVolume# EXT4-fs error (device sda4): ext4_lookup: deleted inode referenced: 14622721

TonyPh12345 June 3, 2014, 1:56am 6

That is not good… Your file system is damaged. Don’t know if it’s due to disk failing or other reasons… The guide you reference above isn’t going to help at all.

I’d wait a few days to see if others chime in, but in that time I recommend you run diagnostics now and see what it comes back with.

Unless there are hardware issues, I think the only option is to 1st try to “fsck” the data volume, and see if your files are at least partially recoverable.

After getting the files off of it that you can, then doing a restore.

Shabuboy June 3, 2014, 4:48pm 7

The one thing most people overlook is “backups”.

http://www.cnet.com/how-to/digital-storage-basics-part-3-backup-vs-redundancy/

NAS devices are just like any other hardware, can die anyday for any reason, either hardware/software.

olyvaha June 3, 2014, 5:38pm 8

yeah i was told that yesterday by a Level 2 here at WD. It’s not very apparent that that is the case, had I known I would have doubled up or not even bought it in the first place, I mean it didnt even last 6 months.

MBL 2To data gone but here

olyvaha June 3, 2014, 5:38pm 9

how do i do a “fsck” on the data volume?

TonyPh12345 June 3, 2014, 6:54pm 10

Ok, but be warned: This is NOT necessarily going to rescue your data. It’s only going to TRY to REPAIR the filesystem. Depending on the extent of filesystem damage, your data may already be unrecoverably destroyed.

There are FOUR mounts that access the DataVolume, all of which must be UNmounted before anything else can be done.

MyBookLive:~# mount | grep Data
/dev/sda4 on /DataVolume type ext4 (rw,noatime,nodiratime)
/DataVolume/cache on /CacheVolume type none (rw,bind)
/DataVolume/shares on /shares type none (rw,bind)
/DataVolume/shares on /nfs type none (rw,bind)

Start by stopping the Samba and NFS servers, and unmounting the nfs mount:

/etc/init.d/samba stop
/etc/init.d/nfs-kernel-server stop
/etc/init.d/nfs-common stop
umount /nfs

Then you’ll need to manually kill any process which is still accessing data in these two mounts:

/DataVolume/cache on /CacheVolume type none (rw,bind)
/DataVolume/shares on /shares type none (rw,bind)

MyBookLive:~# lsof +D /CacheVolume/
COMMAND PID USER FD TYPE DEVICE SIZE NODE NAME
twonkymed 4155 root 0u REG 8,4 0 1044490 /CacheVolume/twonkymedia/twonkymedia-log.txt
twonkymed 4155 root 1u REG 8,4 5686272 1044494 /CacheVolume/twonkymedia/twonky.db
MioCrawle 4433 root 4u REG 8,4 4096 1052467 /CacheVolume/.orion/wdphotos.db
MyBookLive:~# kill 4155
MyBookLive:~# kill 4433

Note the PIDs in that column, and “kill” those PIDs.

Then the same thing on the second mount:

MyBookLive:~# lsof +D /shares/
COMMAND PID USER FD TYPE DEVICE SIZE NODE NAME
mediacraw 4469 root 5u REG 8,4 4871168 10444808 /shares/.mediacrawler/mediacrawler.db
MyBookLive:~# kill 4469

Now you should be able to unmount those two mounts, and lastly the actual disk itself:

MyBookLive:~# umount /shares/
MyBookLive:~# umount /CacheVolume/
MyBookLive:~# umount /dev/sda4

Then you can “fsck” that disk, and REBOOT when done. The output I show below is “normal” because my filesystem is undamaged. I expect you’ll see much more, and may be asked some questions along the way. Be careful.

MyBookLive:~# fsck.ext4 /dev/sda4
e2fsck 1.41.12 (17-May-2010)
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
/dev/sda4: 16485/15144960 files (14.2% non-contiguous), 918204/15191344 blocks
MyBookLive:~# reboot

Broadcast message from root@MyBookLive (pts/0) (Tue Jun 3 13:50:24 2014):
The system is going down for reboot NOW!

olyvaha June 3, 2014, 7:12pm 11

is there a safer way to extract the data? like popping open the case and connecting it over a sata to usb and then going in and maually pulling the data or even with it still in its exclosure?

TonyPh12345 June 3, 2014, 7:17pm 12

Not that I know of… the file system is corrupted. You’ll have to repair it regardless of what method you use to get to the data.

But that’s why I said you might wait a few days for others to chime in – someone else might have a better method. I was just answering the “how-to” question you asked…

olyvaha June 3, 2014, 7:54pm 13

Well many thanks! I will wait a few days and then try out your method, hopefully I can get it back theres a lot of data on there!