Hacking “My Cloud”

  By

N.B. Doing any of the things in this document will void your warranty and may turn your cloud into a brick.

That said the WD My Cloud box is quite a handy little device and as it’s running Debian Wheezy you can do quite a lot of fun stuff with it. How much you want and can do will obviously depend on what you’re using it for, but keep an eye on load and it’s really quite capable.

Back everything up! Frequently!

Seriously, I mean it make back ups of all the system files before you start doing anything and make backups after each change. The My Cloud device doesn’t have convenient console access so it’s not too hard to lock yourself out. Though the reset/restore function is actually very forgiving and mainly just loses changes to the /etc/password file. I also suggest putting as many of the files (especially configuration files) on the /DataVolume partition and then use symlinks, just to save work in the event that you do have to do a reset.

Now first the bad news more recent versions of the Firmware severely restrict what you can do with the device. If you’re running anything a 4.x version or later you’ll need to downgrade, which they’ve also made trickier.

First steps after you’ve done all the normal set up, and probably before you put vital data on the device, enable SSH. Then once you’ve logged in as root change that default password.

Now make a back up of stuff.

Downgrading your Cloud

I’ve only tested this with 4.00.00-607 (7/2014) firmware, they may lock the device down even further with subsequent updates.

Turn off automatic updates, otherwise all your hard work will be for nothing.

I found the “how To” for downgrading on the WD support forums but just in case that vanishes I’ll repeat JoaquinAR‘s instructions here.

Get the latest 3.X version of the firmware from:
http://download.wdc.com/nas/sq-030401-230-20140415.deb.zip
(Cached copy Here – in case WD decide to remove it from their site.)
“You’d have to edit the file /usr/local/sbin/updateFirmwareFromFile.sh commenting out the lines 256 through 259 since it won’t allow you to apply any version lower than the existing one:”
# if [ -z "${update_container}" ] && [ "${vnew}" -lt "${vnow}" ]; then
# error="failed 200 \"invalid firmware package\""
# pre-update_error $
# fi

You can now install the downgrade either from the command line as per JoaqinAR or just use the web interface.

Updating the packages

Now you’re on a useful 3.x version and have backed everything up, time to update the list of packages available, it’s a Debian system so this is really quite easy. Just enable the wheezy-backport distributions so that you get a larger number of more recent packages. You might be able to do a full upgrade to a later version of Debian but I wasn’t brave enough to try that. If you’re not familiar with how Debian handles packages you probably ought to reconsider if you actually want to carry on with this as it’s really easy to break things. That aside just as with any other Debian system edit /etc/apt/sources to add a line like:
deb http://ftp.de.debian.org/debian wheezy-backports main
You may as well also change to using a local mirror while you’re at it.
Now run
apt-get update

N.B. If you try to update your distribution on a later version of the firmware (4.x or above) you will brick your device. I speak from bitter experience here. But fear not this is not the end of the world there are excellent instructions on how to recover from a bricked device over on the WD Forums – (Local copy with my updates)

Changing the DLNA player

Changing the DLNA player from Twonky to something else was an obvious and easy place to start as someone else had already done all the work. I basically followed the instructions from
http://m.hugovalentim.com/blogue/install-minidlna-wd-my-cloud-nas-guide-how

To summarise the process and to details the slight changes to what I did here’s a terse step by step guide.If you need more details refer to the guide above.

  1. I’m assuming automatic updates are already off, SSH access is enabled, you can connect to the internet and you’ve updated your packages.
  2. Turn off the Twonky server via the web GUI.
  3. Via SSH as root run the command:
    apt-get install minidlna
  4. Create a directory on the /DataVolume partition for the database and art cache.
    e.g. mkdir -p /DataVolume/programs/minidlna/cache
  5. Create a directory on the/DataVolumepartition for log files.
    e.g.mkdir -p /DataVolume/programs/logs
  6. Edit the MiniDLNA startup script /etc/init.d/minidlna
    Change: PIDDIR=/run/$NAME to PIDDIR=/var/run/$NAME
  7. Edit the MiniDLNA configuration file /etc/minidlna.conf.
    • To match the My Cloud Twonky configuration you’ll want to add the lines:
      media_dir=A,/DataVolume/shares/Public/Shared Music
      media_dir=P,/DataVolume/shares/Public/Shared Pictures
      media_dir=V,/DataVolume/shares Shared Videos
    • Change the DB path to match the directory you created earlier:
      db_dir=/DataVolume/programs/minidlna/cache
    • Change the Log path match the directory you created earlier:
      log_dir=/DataVolume/programs/logs
    • Enable automatic discovery:
      directory.inotify=yes
    • You can change the presentation URL if you want to but there’s no need.
  8. Add the MiniDLNA user to the Share group:
    usermod -a -G share minidlna
  9. Make sure the cache and logs directories are writable by the minidlna user
  10. You might want to edit the startup script to allow you to save the configuration file on the DataVolume partition.
  11. Backup everything you’ve changed password, group, startup and configuration files
  12. Start MiniDLNA:
    /etc/init.d/minidlna start
  13. Check MiniDLNA is running happily and serving your files.
  14. Reboot your My Cloud and make sure everything is still working.

Installing PDNS recursor

This is another easy addition though one I admit many people probably won’t care for. I play with DNS for my day job, so I really like having well behaved local DNS even for my few home machines, and to control my own DNS based protection, and to avoid the current trend of ISPs blocking sites at the DNS level. So as it’s what I’ve use at work I installed PowerDNS recursor to provide local DNS. As I’d already enabled the Wheezy backports a simple apt get installed the latest 3.6.0 release with LUA support.

  1. Make sure you’ve backed everything up.
  2. To install PowerDNS just run:
    apt-get install pdns-recursor
  3. Move /etc/powerdns onto the /DataVolume partition and put a symlink in place back to /etc.
    As I’m installing a few things I actually created both etc and log directories to keep the various configurations and log files in.
  4. Edit the PDNS configuration file /etc/powerdns/recursor
    • Change the allow-from-file line to:
      allow-from-file=/etc/powerdns/allow-from.lst
    • Add any local authzones you might want (Consult the PDNS documentation for help with this)
    • Allow PDNS to listen on all interfaces:
      local-address=*
    • Make PDNS authoritative for RFC 1918 addresses
      serve-rfc1918=yes
  5. Update the start up script to generate your allow from file
    Using something like:
    echo 127.0.0.0/8 > /etc/powerdns/allow-from.lst
    /usr/local/sbin/getActiveLocalNetwork.sh --addr | sed 's/ /\n/g;' >> /etc/powerdns/allow-from.lst
  6. Start PDNS
    /etc/init.d/pdns-recursor start
  7. If it starts check that it can resolve everything you expect it to both locally and from other machines on your network.
    Checking locally is slightly tricky as things like host and dig aren’t installed by default.
  8. If everything is happy, make sure you have backups and then restart your My Cloud and check it’s all still happy.

IPv6 tweaks

As the “My Cloud” is basically just a Debian box it’s already IPv6 capable and in fact does IPv6 out of the box. At least it would if WD hadn’t got a few things in place that rather break it.

You may for instance notice that if you try to go the web UI via it’s IPv6 address you get denied access. That’s because of a very sensible security measure which restricts access to the local subnet only, sadly the script that implements that isn’t IPv6 aware, but fortunately it’s an easy problem to fix.
The script to edit is /usr/local/sbin/getActiveLocalNetwork.sh.
So back it up and then make the following change:

23c23,24
< ip addr show dev $NETWORK_DEVICE | awk '/inet /{print $2}'
---
> ip addr show dev $NETWORK_DEVICE | awk '/inet /{print $2}' | tr "\n" " "
> ip addr show dev $NETWORK_DEVICE | awk '/inet6 /{print $2}' | tr "\n" " "

That’s it, restart Apache and the web UI no longer tells you to go away. It still doesn’t actually work which is annoying, but I don’t really want to muck about with that too much.
I’d still recommend “fixing” this script though as it may be used elsewhere and it can be made use of for other ACLs such as for PDNS.

If you need/want to add a static IPv6 address for your Cloud then again it’s just Debian so edit /etc/network/interfaces and add the relevant lines.

e.g.
iface eth0 inet6 static
address 2001:db8::80
netmask 64

Depending on your local IPv6 configuration that may be all you need to do. Well apart from making sure everything is backed up, and restarting the My Cloud to make sure it all works.

N.B. Remember that the My Cloud effectively has no console access so mucking up the network settings is a good way to lock yourself out. You should be able to get back in via the reset function if that happens but then you will lose some changes. A better plan may be to have the network configuration backed up and a cron task configured to restore a default network configuration and reboot the My Cloud in 30 mins or so time, just remember to remove the cron task if everything works.

Additional apache web server

This is an obvious one but there are a few gotcha’s. As I do the odd bit of web development having a local web server to test things on is handy. It’s also a useful thing for sharing household calendars, the WLAN configuration and all that sort of good stuff. So as the My Cloud is already running Apache 2.4.4 and php 5.4 with quite a few mods enabled may as well make use of it.

The first thing I did was to create a new Share so that I could upload content easily. Once that was done I added a virtual interface to the networking so as to not interfere with the web UI.

The new network interface was added to /etc/network/interfaces in the same way as for any other Debian based system. I just added the following:

auto eth0:0
iface eth0:0 inet static
address 192.168.1.80
netmask 255.255.255.0

Then restarted networking, I’ve left the primary interface set to be configured by DHCP just to reduce the risk if I break something.

Following my normal practice of keeping as many of my changes as possible off the root partition, I created /DataVolume/etc/apache/sites-enabled. I then created a normal virtual server configuration in there:

< VirtualHost 192.168.1.80:80>
ServerAdmin user@example.com
DocumentRoot /DataVolume/shares/Web/
ServerName web.mycloud
< Directory /DataVolume/shares/Web/>
Options +FollowSymLinks
AllowOverride FileInfo
< /Directory>
ErrorLog /DataVolume/logs/web_error.log
LogLevel warn
CustomLog /DataVolume/logs/web_access.log combined
< /VirtualHost>

To avoid filling the root partition I’m keeping my logs on the DataShare volume, for security reasons you’ll notice that none of the log or configuration files are in shares. Then add an include statement to /etc/apache2/apache2.conf to include my new virtual server directives:
Include /DataVolume/etc/apache/

To make the web UI more user friendly WD configure apache with a global rewrite, which obviously isn’t ideal for the new virtual server, so the file /etc/apache2/sites-available/wdnas-ui.conf needs to be edited to add two lines:

< IfModule mod_rewrite.c>
< Directory "${DOCUMENT_ROOT}/UI">
${LOCAL_NET}
< If "%{DOCUMENT_ROOT} == '/var/www/htdocs'">
RewriteEngine On
RewriteBase /UI/
RewriteCond %{REQUEST_FILENAME} !-d
RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule ^(.*)$ /UI/ [R]
</If>
</Directory>
</IfModule>

Final tidying

Working on the principle of don’t run anything you don’t need to especially on a box with limited resources as I don’t have any Apple devices I left TimeMachine disabled I also then added a crontab to stop netatalk from running.
@reboot /bin/sh /etc/init.d/netatalk stop
This could be done by editing the startup script or renaming the /etc/rc?.d/ files, but being paranoid I want to avoid as many changes to the system as possible.

As I don’t want to use the remote access mycloud functionality, very nice though I’m sure it is – I disabled that via the web UI which doesn’t seem to actually stop the process running so I added another cron task:
@reboot /bin/sh /etc/init.d/wdmcserverd stop

This doesn’t seem to have affected Smartware or anything else.

Finally as I don’t need thumbnails of my photo’s to be made nad I’m not running Twonky server anyway I added another cron task to stop the wdphotodbmerger from running as well:
@reboot /bin/sh /etc/init.d/wdphotodbmerger stop
There’s a more detailed explanation of these processes on the WD support forums:
http://community.wd.com/t5/WD-My-Cloud/wdphotodbmerger-process-on-WD-My-cloud/td-p/605609

There’s a few more processes I’m tempted to kill off to save even more CPU, but I’ve not tested them yet. I also plan to stop using NTPdate and run a proper NTPd.

Tagged  , , , .
Bookmark the permalink.

Leave a Reply