So, about actually putting up a helpful article here…high time I did that rather than leave this thing up as a name billboard.
I got messaged by a fellow back in January right after New Year’s about woes he was having about a hardware error of a device I owned. Apparently he stumbled upon a forum post and found my page here (don’t know how that came about). Either way my solution was very…um, how to put this; unorthodox and not straightforward. I learned two things that’s prompting me to make this entry:
1. As “Apollo 13ish” as my method was and its works, not everyone may get what to do from my outline of steps.
2. This problem still occurs even after a whole year that I came across my hotfix.
With that I’ve making a more straightforward set of instructions that any average Joe should be able to follow. And as such, Yorina and Dyma are here to help walk you through this.
Yes, I use aliens for tech support; sue me.
So! Let’s get started.
WD My Cloud Data Recovery: Data Volume Failed to Mount: Code 004
First! Story time as to how this problem came about.
It was November 2013. WD had just released their “My Cloud” line a few months ago and I was on the market for an addition to my family’s single MD My Book World. I plucked a 3TB off Amazon and promptly set it up Thanksgiving morning. All seemed well I started to offload data onto the drive on the following days.
Come the last day in November at 2:30AM. Don’t know what exactly happened but we had a power failure. The drive wasn’t on a UPS and the power came back on a minute later. When morning came I went to continue copying things onto the drive when it told me that it couldn’t find the drive. Wasn’t new; thought it was being finnicky as the My World as that drive would give that message when you copied stuff for a long period of time. My home baked solution? Reboot the drive. So I walked over to do so and found;
The Red Light.
Worried was an understatement. Immediately I knew something was wrong and looked up the error. As I accessed the dash and saw what the manual had to say I realized this was quite serious. What had me worried was that most of the data I had copied was non-replaceable; and I had already deleted it off the origin drive. So off to support I went.
Long story short with my chat to support and from the manual, the drive was returning a Code 004 error in the dashboard. “Data Volume Failed to Mount”. Meaning something was wrong with the data volume when the drive was rebooting and it was unable to link and show it on the network. Support assured me that if I could access the Dashboard that the drive wasn’t physically bad; rather that it was a firmware issue. They put in a support ticket in for a replacement drive.
While that was all good and dandy I still had my data on that drive. And I wasn’t going to pay someone $600 to get it off. I decided to fish around on the drive myself and see if I could rescue my “stranded data” with what I knew from CSCI and the old days of dial-up bulletin boards before the Internet existed.
I had visited the WD Community forums for help (you can see my plea for help here ) but as this drive was relatively new there was barely any information on what even to do to fix it.
You see there was a “scorched earth” solution to fix the drive; but this would result in the loss of your data. Factory wiping the drive. This was not an option.
I took a crash course in SSH and navigating Linux via command prompts, drinking lots of coffee and soda for three days straight and staring back at printed logs. But from all that I read and some obscure Ubuntu forum I finally came up with a solution to gain access.
Yorina: Please! Is this whole post a story or are we going to actually tell people how to do this?
All right, fine! Sheesh!
“Ayaaa, one more thing!” (Jackie Chan reference for those of you who don’t recognize that). Not responsible for the screw-up of your drive if you make a mistake. This is under the assumption that the situation was closely identical (will go into details down later).
You also permanently mess up the firmware on this drive when you do this. Its imperative if not highly recommended to factory reset your drive after you finish rescuing your data. There! Girls?
What You Need:
Greetings, I’m Yorina Athanias. And this is my companion and colleague Dyma. We’ll be helping you commence firmware repairs on the hardware storage device known as the WD My Cloud.
Wha…too formal? I’m speaking to the public! Mother said to always be formal when doing that!
Fine. Sorry about Dyma. She doesn’t really speak a whole lot.
So, what you’ll need to make this procedure work:
- PuTTY: This is a utility that will allow you to make the connection to the drive. You can download it here
- Admin Privileges: This came up in another software, but its suffice to say that Windows may block the connect. Make sure you’re an admin and you have the necessary privileges.
- IP Address of Hard Drive: Remember the days of old when you would dial across ancient phone lines via a number address? You’ll be doing so again. Chances are you know this address already; if not, it’s easily accessible from the Network tab in Windows Explorer. (Alternatively, Dyma suggests that you can get it from the address bar of the browser while accessing the drive’s Dashboard)
- SSH Enabled: This entire procedure depends on SSH being enabled on your drive. If you can ‘t access the Dashboard to turn on SSH, as well-learned as we are we can’t help you. Otherwise, go turn it on. (See below)
- Coffee: Optional. Just to help and keep you calm, as you can see Dyma doing.
STEP 1: Establish Connection to Drive
Subsection A: Enabling SSH
Enabling SSH is simple. Generally its not on by default as your “technically inclined” portions of Terran culture doesn’t want simpletons messing up the framework. Simply go to Settings in the Dashboard UI then Network on the left. Turn it on as so:
Subsction B: Connecting to the drive via PuTTY
Open PuTTY after installation. You’ll get a window like this:
Enter the address of your hard drive in the Host Name field. Port is fine. Click open.
You’ll get a message that the host you’re trying to connect isn’t a verified host, asking if you trust your connection destination and if PuTTY should remember this. Click Yes and you’re brought to a command prompt.
Immediately you’re prompted for a username/password. Now if you listened to us and left it at default, this is the default combination:
Password: welc0me (the “O” is a zero)
If all goes well, a welcome greeting about the drive’s OS will be spat back out to you with the prompt patiently awaiting your input. At this point, you should feel just as David Levision did after he clapped his hands together when his Apple laptop logged into the alien Mothership’s mainframe.
OW! Fine, no more movie references.
Step 2: Ensure Partitions are intact
As a failsafe to make sure this will work, your partitions need to be intact. Enter this line on the command prompt:
# parted -l (This is the letter “L” in lowercase.)
If things are still clicking away as they should, you’ll get something similar to what’s below:
Number Start End Size File system Name Flags 3 15.7MB 528MB 513MB linux-swap(v1) primary 1 528MB 2576MB 2048MB ext3 primary raid 2 2576MB 4624MB 2048MB ext3 primary raid 5 4624MB 4724MB 99.6MB primary 6 4724MB 4824MB 101MB primary 7 4824MB 4826MB 1049kB primary 8 4826MB 4828MB 2097kB primary 4 4828MB 3001GB 2996GB ext4 primary
This will vary as they probably make the drives a different way or arrange it due to size. But in either way there will be a partition that’s the size of the entire drive (3TB in this case). For this example, number 4 is the main partition with a file system of ext4. Keep that on hand for a following step.
Step 3: Get Drive’s File System and Block Backups
Now that we’ve located (well, you located) the drive’s main partition number and filetype, time to pull its data. Enter this:
# mke2fs -n /dev/sda4
From what Dyma found in Janeil’s notes, the number on the end refers to the partition number. If the main partition is a different number, change the number accordingly. (4 was the default on the 2013 drive)
You’ll get back some file system information on the drive partition and some other information. But most importantly, there will be a section with a bunch of numbers labeled “Superblock backup locations”. This is what we’re after. Write down some of these numbers as we go to the next step-
Ah ah ah! We’ll explain later. This is good news if you have backup locations. Onwards!
Step 4: Restoring Drive Information From Superblock Backup
Now that we have locations of a backup, its time to set things right. Type out this command:
e2fsck -b blocknumber /dev/sda4
“blocknumber” is a placeholder for the actual block number you wrote down a minute ago. Type this in there instead.
The drive’s OS will start looking for bad blocks and ask if you’d like to write over the bad blocks with the intact data from the backup. Yes to rewrite, yes to ignore.
Then it’ll begin some diagnostics. It will go through 5 passes of various tests. If something is out of the ordinary, just answer yes. It’s just trying to re-build the partition and file count info.
This may take about 20 minutes depending on how much data you have on the drive. When it’s complete you’ll either get a summary or a “Killed” message with a return to the prompt.
Step 5: Rebuilding and Rebooting
Time to see if this actually worked. As with all changes, you must start afresh. Enter this command:
The drive will restart and start to reconstruct its library as if you soft rebooted it from the Dashboard. This will take some time (about 30 minutes or more) so don’t panic if you don’t see anything right away.
Step 6: Rescue Your Data
If all went according to plan, your data should show up right where you left them. Now sadly your drive’s been modded so fix the data in an unconventional way, so you lose most of the Dashboard’s information on the drive such as hard drive space and the like. Copy off your data and prepare to start back from square one.
Optional: Step 7: Reformat the Drive to Factory Condition
Once all your data has been successfully copied off and lifeboat-ed, time to reset the drive. Go back to the dashboard and go to Settings, Utilities and Full Restore. Wave goodbye as it restarts and wipes the drive clean to factory settings.
As this its not technically proven to fix your drive back to its old state after this, its a good idea to do so if you have to send the drive back in for warranty.
And there you have it. The hodge-podge procedure born out a tiny rural community on how to rescue your files of a WD My Cloud in case it gets the red light and code 004.
For most of you, the post stops here. But if you’re tech savvy and want to know what went wrong, Dyma will be glad to explain what we think went wrong and how this worked. Hey! *wave onto screen*
Ah yes. Thank you, Yorina. Hope the post was helpful guys who needed help. Special shoutout to dazippy2 for letting me know that my method was still useful and making it clear I needed a step-by-step version of this.
I want to say thank you to everyone who’s given comments, thanks and just simply finding my tutorial useful on my site. This is the most trafficked web page on my site (and of all time, too) and I’m glad that I’m able to help you recover your data without it being lost.
If you’ve found this tutorial useful and would like to show your appreciation, feel free to drop two bits for coffee via Paypal or support my Patreon. Donations help to keep the lights on at the site, along with helping me get more content to post!
What Went Wrong? Analysis
Greetings, I’m Dyma. *polite bow* We present technical data!
The drive malfunctioned when power was lost.We assume data was written halfway during the drive’s power less and resulted in a corrupt block that prevented the partition from mounting properly.
This procedure involved a temporary but working fix to restore a backup of block structure in case of such an event. Superblocks are the schematics for the drive’s information; partition size, file count, etc.
The exact error that led Janeil to this solution was this response line when attempting to generally fix the file system:
e2fsck: Attempt to read block from filesystem resulted in short read while trying to open /dev/sda4 Could this be a zero-length partition?
Short reads occur when the filesystem block is corrupt. The partition physically existed but the filesystem spoke otherwise. The method you used was a Linux method to restore the corrupted filesystem of a Linux OS drive adapted for use on the WD My Cloud.
As you noticed when getting the superblock backup locations, there are several that they’re stored in. This is due to the fact that one block can get corrupt, so for safety measures more than one exists. Theoretically if one of these locations were bad, you can type in an alternative address to pull the backup information from.
In final, never unplug the drive without shutting it down from the Dashboard. Also keep the drive connected to a UPS; if the power goes out and it will be out for a good portion of time, immediately get access and shut the drive off. Lastly as a given, always keep a backup of your data on hand.