Bricked my EX2. <Also how I unbricked it>


I have been playing around trying to get openvpn to work on the NAS with iptables, but it required some kernel modules that were not enabled, so I embarked on recompiling the firmware from the WD GPL source. It seems though I must have missed something as now the EX2 won’t finish booting (power light just sits there blinking and there it doesn’t appear on the network).

Does anyone know of a way of unbricking these? I saw that for the original My Cloud it was possible to use dd to reformat the HDD and put a working firmware image on it so that it can be booted. Is such a thing possible with the EX2 or is it toast?

Hello and welcome to the community,

I have never tried this before since it is not supported. But lets see if another user shares his experience on this topic.

I’ve managed to hook up a USB-Serial cable (FTDI based) to the My Cloud so can see the output when it boots. Essentially it loads the kernel but ends with:


Kernel panic - not syncing: No init found.  Try passing init= option to kernel. See Linux Documentation/init.txt for guidance.


So really not sure what’s going on there.

I noticed also that it says after it loads uboot “press any key to stop autoboot”. I presume this would drop into the uboot console, but I can’t seem to stop autoboot. I’ve pressed every key I can think of, held keys down all the way through boot, etc, but it doesn’t seem to take any notice and just auto boots from the NAND anyway.

Anyone have experience with uboot and if there are any special key combinations required to get it to not auto load from the flash?

I also saw that the Marvel 370 supports xmodem as a way to loading a boot image via UART at boot. I’ve been trying this with kwboot, and it seems I can successfully halt the boot process and get to a point where a uboot image could be uploaded to help unbrick it. I found the u-boot.bin file in the GPL source folder and have been trying to load that, but it seems to fail with “protocol error” and that is when it works at all (seems to be a bit flakey).

I did find this: and tried the uboot image they made, and in one attempt managed to get it to load the whole image, but I think they set it up so that it uses ttyS1 for output which this board doesn’t have. I can only assume that the protocol error is being caused by the DDR initialisation like in there post, but without a second serial port I am not sure if there is a work around to get kwboot to keep going.

Any thoughts?

Well, i managed to stop autoboot and get to the MARVEL>> prompt - just have to keep alternating between ‘space’ and ‘1’  (as per when the Nas is booting and it will stop autoboot.

Once I’ve figured out how to boot the stock firmware, I can use it to reflash the firmware to standard and hopefully unbrick the nas.

Well, I’ve got to the stage of having tftp set up on my laptop and being able to use uboot to copy a uImage kernel file and boot it - but that is without a root file system.

Now what I need to work out is how to boot the kernel and filesystem from the WD official firmware release. If I can do that then I should be able to use the standard update tool to reflash the stock firmware.

Well, I am now at the point where I have got it to boot the uImage and uRamdisk from the GPL source code /merge/ folder so I now have a linux terminal.

The problem now is that the kernel/ramdisk try to load the squashfs filesystem from the NAND (I guess that is what they are set up to do). Obviously as that firmware is the dead one, it doesn’t help much.

Now I need to work out how to get it to load an image.cfs from RAM rather than flash.

I have managed to copy the precompiled image.cfs file from the source code into the RAM, and with a bit of tinkering got mount/umount to work (there were missing libraries). But when I try to mount the cfs I get the following error:

mount -t squashfs -o loop /dev/image.cfs /usr/local/modules
SQUASHFS error: Can’t find a SQUASHFS superblock on loop1
mount: wrong fs type, bad option, bad superblock on /dev/loop1,
       missing codepage or helper program, or other error
       In some cases useful info is found in syslog - try
       dmesg | tail  or so

Not sure what is causing that.

Well, I’ve managed to get to a point where I have booted into the custom firmware that was in the NAND. Its a bit broken(wrong file permissions here there and everywhere) and the web interface doesn’t work, but at least I am now in to it which means I now have access to the to the firmware update tools which can be used via SSH (though in this case I’ll be doing it via serial). Just copying the stock firmware image across to the HDD and *fingers crossed* I’ll be able to flash it. :S

Success! I now am back to the stock firmware - just like when I bought it. Granted the RAID setup is now degraded, but that is simple to fix.

I made a lot of notes while I was getting to this point, so I’ll do a writeup at some point for anyone else who is in a similar *bricked* situation.

THIS GUIDE COULD SERIOUSLY SCREW YOUR NAS - you will be connecting a serial device directly to the main PCB of the NAS, and fiddling around in its bootloader. If you brick it even more than it already is, or blow it up, that’s on you! Don’t bother coming crying to me, I bear no responsibility for the validity or repeatability of this guide, it is just what I did to get my NAS back up and running. IT WILL ALSO COMPLETELY TOTALLY AND UTTERLY VOID YOUR WD WARRANTY, but you signed up for that when you installed custom firmware. If you didn’t installed custom firmware and your NAS is bricked, ask WD to see if they will fix it.

If you brick your EX2, it _ *may* _ be possible to recover it.

To do so however, you need to connect to the serial port inside the device. You will find if you take the EX2 apart that on the reverse of the PCB there is a connector J2.
On mine it wasn’t populated, but there is the footprint a 5 pin 2.54mm header with one pin missing and lines marked on the PCB.
If you do not have a header, solder one on.

The connector has the following pin map:

5 o <-- RX Data
4 (No pin)
3 o — N/C (3.3V)
2 o — GND
1 o --> TX Data

Connect this to a 3.3V USB to serial device such as a sparkfun FTDI 3.3V breakout board/cable. Make sure the RX pin connects to the TX pin of the FTDI board. Don’t connect anything to the 3.3V pin!

Using something like PuTTY, open the serial port at 115200,8,N,1 (no flow control).

Now boot your bricked NAS. You should see a whole lot of information being printed out of the terminal. If you don’t, check your connections are correct and you have RX/TX the correct way around.

Hopefully you should see uBoot loading - there will be a breif second where it says “press any key to stop autoboot”. This is a bit misleading as you cannot press just any key!

We need to make sure we send the correct keys in time to avoid uBoot from automatically loading the dead kernel from the NAND flash.

To do this, turn off the NAS, leaving the serial connection open. Then turn it back on again. As soo as you turn it on start repeatedly sending the following key combination through the serial port:

then ‘1’ then ‘1’ and so on. i.e.:
1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1

You should see it get to the line saying ‘press any key to stop autoboot’, only this time, the next line should be:


If you see that prompt, then you were successful. You are now in an interactive uBoot console. WOO.

Just to check it is working enter at the prompt
Marvell>> ?
and press enter.

You should see a list of commands. If you do, great!

Connect your network cable and enter the command:
Marvell>> dhcp

It should now connect to the network and get an IP address.


Now we need to get it to boot a working kernel/filesystem. To do this, you need access to a tftp server, the easiest way of getting this is by booting a linux distribution such as Ubuntu on your computer. If you don’t want to install linux, you can use a live CD.
I am using Ubuntu, so if you are not, the next instructions might differ.

First install the tftp packages:
~$ sudo apt-get install xinetd tftpd tftp

Next, create a tftp service file using:
~$ sudo nano /etc/xinetd.d/tftp

Add into that file the following:

service tftp
protocol        = udp
port            = 69
socket_type     = dgram
wait            = yes
user            = nobody
server          = /usr/sbin/in.tftpd
server_args     = <directory to your service files, e.g. /tftpboot>
disable         = no

Save the file, then create the directory specified in server_args. e.g.

sudo mkdir /tftpboot
sudo chmod -R 777 /tftpboot
sudo chown -R nobody /tftpboot

Then restart the xinetd service

sudo /etc/init.d/xinetd restart

To test the tftp server, you can do the following:

First, create a test file:
echo Hi > /tftpboot/test

Then, get the ip address of your computer:

then do:
get test
cat test

It should say “Hi”.

The above setting up the tftp server was found here:

Next, add the working kernel uImage and uRamdisk files (can be found in the firmware/merge folder of a fresh copy of the GPL source from WD - don’t use the copy you used to compile your firmware as that one is buggered!) to the /tftpboot folder

For some reason, in order for this to work, you need to set the owner and permissions of the /tftpboot folder and all its contents to group nobody:root, and permissions 766

sudo chmod 766 /tftpboot
sudo chmod 766 /tftpboot/*
sudo chown nobody:root /tftpboot
sudo chown nobody:root /tftpboot/*

Otherwise you will get “Access Error (2)” when trying to run tftp on the Nas.


As an alternative to the above, all of the next steps, including the TFTP stuff can be done in Windows if you prefer, you just need PuTTY to connect the the serial port, and to download tftpd32. Just set up tftpd32 to be only a tftp server, and select the network interface that is on the same network as your NAS. Make a folder called ‘tftpboot’ and point tftpd32 to that directory as its root.

Next, add the working kernel uImage and uRamdisk files (can be found in the firmware/merge folder of a fresh copy of the GPL source from WD - don’t use the copy you used to compile your firmware as that one is buggered!) to the /tftpboot folder


Now, on the Nas, to tell if the IP address of your tftp server, do:
Marvel>> setenv serverip

Next we set up the boot arguments so that uBoot will load the two files from the tftp server and then boot them.

Marvel>> setenv bootargs console=ttyS0,115200 root=/dev/ram rw ip=dhcp eth=${ethaddr}
Marvel>> setenv bootcmd ‘tftp 0x2000000 uImage; tftp 0x3000000 uRamdisk; bootm 0x2000000 0x3000000’

Now we boot into linux:

Marvel>> boot

Boot will fail to find image.cfs, but will prompt to activate console. Press enter
The default password of admin is nothing, just press enter. You now have a console!

!The next commands should be run on your NAS, not your host pc!

For the next part to work, we need to get mount and umount commands working. It appears that library dependencies are missing. So from the firmware/module/crfs folder of the GPL source code, we need to get our missing files.
The following are required:

Place those files in your /tftpboot folder

Copy that to the Nas /lib folder using:

cd /lib
tftp -l -g #or your
tftp -l -g #or your

Unfortunately there are symbolic links now which are missing so now we need to recreate them.
Run the following commands:

ln -s
ln -s
ln -s
ln -s

Try running umount like:


And hopefully it shouldn’t complain about missing libraries now.

The image.cfs file from the flash is still mounted at this point as umount was screwed when it tried to unmount it, so do:
umount /dev/loop0
umount /proc
umount /usr/local/modules
umount /usr/local/config
umount /sys/fs/cgroup

You should probably do the above lines *twice*. When I was working out how to get this all to boot, it seemed that some times doing it once wasn’t enough. I never had to do it more than twice.

Now we have the problem that all the files in /usr/local/modules/script are read only! That is truly great for an operating system to have all its executable files not being able to execute and which /etc/ fails miserably. It comes down to the fact that it is a squashfs filesystem mounted as read-only.

So, we need to extract the file system to somewhere with enough space to take it so that we have read/write/execute permissions - RAM does not as it is over 600MB!

So, lets mount one of the nice big HDDs that are in the Nas!

THIS WILL NOT WORK IF YOU USE RAID 0 !! Mounting the HDD like this will likely corrupt your striped array. Even for RAID 1 it is risky as it will result in the two drives getting out of sync, but at least that *should* be recoverable by rebuilding the mirror array once everything is fixed.

mkdir /media
mkdir /media/bob
mount /dev/sda2 /media/bob
df -h

(p.s. you don’t have to call it bob, I was just bored)

You should see that the hard drive has been mounted.

So, lets copy the filesystem to it!

mkdir /media/bob/recoverysys
cp -R /usr/local/modules/ /media/bob/recoverysys/

Now we unmount the image and instead put a symbolic link to our HDD copy:
umount /usr/local/modules
rm /usr/local/modules -R
ln -s /media/bob/recoverysys/modules /usr/local/modules

Now lets correct those file permissions!

cd /usr/local/modules/
chmod -R 700 *

Now granted the above is a terrible thing to do in an operating system, but at this point it really doesn’t matter as the OS is just installed in RAM so will be erased next time we reboot. I couldn’t be bothered to go through and work out which files needed there permissions changing, so I did the lot.

Now they are executable, lets run the startup script.
cd /

Well it sort of worked. Seems that libsqlite bauked out. Shucks.
On the plus side it is now running the WDMyCloudEX2 firmware. But because stuff failed, the webpage is completely unusable - I just got a blank grey screen.

But it seems that it is enough. It is possible to flash the WD firmware via SSH without the webpage. Of course we are connected via Serial, but the only difference between us and SSH is the interface, they are both command line terminals.

So, lets copy the firmware across. (First you need to download it from WD)
I am using version 1.05.30 as it is the latest at time of writing.
Download the file, extract it and you are left with a bin file. Place this bin file in your /tftpboot directory on your server so that we can copy it across using TFTP.

So copy it to the WD nas:

cd /shares/Public

tftp -l My_Cloud_KC2A_1.05.30.bin -g

Now the moment of truth. I was **bleep**ting myself at this point…

/usr/local/sbin/ My_Cloud_KC2A_1.05.30.bin

It started off seeming as if all was going well, I watched it erasing the NAND partition and all looked good. Then it stopped. It was sitting there doing nothing. So I had a choice between either cancelling and trying again, or waiting. Thankfully I decided to wait.

About 2 minutes later, the process exited and I saw a nice message saying that the NAS is scheduling for restart.

But then once again nothing happened. It just sat there. After 5 minutes of this I got bored and pressed the enter key. And happily the prompt appeared again. So I manually rebooted the NAS using:


Back to uBoot it went, but this time I didn’t stop autoload, so it started booting from the flash.

Could it be?!?

Is it working?!?!

*shakes in anticipation*


Ok, so now there is at least a good firmware image in the flash and it can boot from it. The front LED was blinking orange at this point, much like when I turned it on for the very first time. After a bit of waiting for any sign of it doing something, I got bored and decided to go to the device webpage. What do you know, it’s ALIVE!

I set up the My Cloud account and user account again and it’s back to stock firmware!

At this point I got some nice messages saying the RAID was degraded, but I knew that was going to happen as I was using the HDD without a RAID controller. But that was nothing that going to the advanced options and rebuilding the array didn’t fix.

 Hopefully someone will find this useful.


Very good job, TCWORLD.

This is exactly what WD community needs: people like you that share his experience and knowledge.

Bravo !


Just for anyone else trying to compile their own firmware, I have worked out why I bricked my system and why I had to go through all those steps - especially the one about the system files not being executable.

Basically when I extracted the GPL source code, it seemed there were file permission errors on some of the build scripts - I had to mark them as executable before using them. I have a sneaking suspition that when I extracted the source it lost all its permissions, which probably means all the files in the /crfs/ folder got marked as non-executable, thus meaning my filesystem couldn’t boot which is why it got bricked, and why when I tried to recover it I met the same non-executable issue.

The second time around I redownloaded and reextracted the source, but this time the permissions on the build script were correct, and my custom firmware boots fine.

So the lesson here is if when building your firmware you notice that the build script don’t execute, STOP! Don’t go any further as you will probably brick your NAS. Delete the source and reextract it, make sure the permissions are correct!



p.s. I now have ‘nano’ text editor installed on the NAS, and also iptables along with kernel support for NAT. Just need to test everything is working. With a bit of luck I will be able to set up OpenVPN.

1 Like

Just FYI you can do a kernel recompile and build in support for using OpenVPN with iptables to do NAT translation. Woop. :slight_smile:

I’ll post some instructions in another thread at some point.

TCWorld - Impressive recovery, I must say. I wish you had taken a few pictures of the hardware soldering stuff. I mostly followed and understood the commands (software side of things) but I confess I have little knowledge of the hardware side at least on this device (have done soldering stuff on my Xboxes a while ago). But nonetheless, I like others am grateful for you taking the time to share your knowledge and experience here. I too try to contribute on this forum when I can.

I am also VERY interested in your OpenVPN usage. I had noticed that WD has been including OpenVPN in our EX2 for a while now. It is running as a process, but I haven’t had a chance to tinker with it. I would love to run a OpenVPN service that allows me to remotely access my home network via VPN. And like you, I have been running my own modded firmware on the EX2…for almost a year now (since last year’s March 19th).

I am also eager to learn from you how you enabled iptables, as I have been interested in doing that for sometime…but that had fallen on my backburner due to other projects and things in life. I have made many other custom changes to the firmware including sftp support for non-admin users, crontab persistence, http, ssh and sftp logging, etc. Perhaps you and I can share notes via PM. Or perhaps you could share your notes on iptables and OpenVPN in another tutorial kinda post, like this one, whenever you have the chance. I have written some tutorial-like posts on a few different topics, though I left some of my more technical ones out of here, as I am always nervous of WD blocking some of those things in a future firmware release :slight_smile:

Again, congrats on your device’s amazing recovery.

There are some pictures of the inside of the nas here:

I used those as a reference when I was taking it apart. In one of the images is shows the SATA connector for disk 1. Just above it there is a 5 pin connector which is JP2. On mine it didn’t actually have the connector soldered on, just the place where it should be so I attached my own.

I did take some notes when I was setting up iptables so will post those this weekend.

1 Like

Aah, awesome. Thanks for pointing me to these pics…very helpful indeed.

Look forward to your writeup. I am interested in both your notes on getting iptables and OpenVPN working.

Sorry to bother you TCWorld, but if you ever get the chance to do the writeup for the kernel compilation with iptables enabled and how to use OpenVPN, I would be very grateful. If you have the time, that is. I understand if you don’t.


Sorry about the delay, had an unexpectedly hectic weekend. I have posted my notes here:


I am really interested in getting Serial access to the WD My Cloud Ex2. I want to access uBoot in case I break something on the NAND memory, because I’m using somewhat of a custom setup.
You said you “hook up a USB-Serial cable (FTDI based)”, what does that mean? Did you solder TX/RX on the board? I didn’t find much to solder on… And what does FTDI mean? I didn’t find much information about that.

Any help is welcome!

here is a starting link for parts

I was thinking about adding a terminal port to one of my WD NAS units

and seems like the FTDI gets its start as( Future Technology Devices International Ltd) . who makes cables.

A USB TTL Serial device (double check the required voltage on the sparkfun one)

As @Cordorb suggests, something like that Sparkfun link. Really any USB->Serial device will do as long as it uses 3.3V logic levels.

On the PCB inside the EX2, there is an (un)populated 5pin header on the back (side opposite the CPU). You can see the header I am talking about in the bottom image on this review:

In my earlier post I mentioned the connection order for the pins.