You’ve just bought a prosumer WD network-attached storage (NAS) – the one that can run “apps” and you’re hoping to also serve your source code repositories via Git to your own small team. You’ve installed “git” from WD My Cloud’s control panel. Now what? You’re stuck. There’s nothing whatsoever that can configure your git repositories and provision them to people.
Yes you’re pretty much stuck. I was stuck just like you. Fortunately I solved this particular problem and took notes along the way so that you don’t need to be stuck any longer.
This post shows you how to setup a Western Digital My Cloud EX2 to be a fully-functional Git source code repository server. Moreover, these steps should also work with WD’s EX4 model (the four drives variant) but I’ve never tested it personally.
Setting up the drive
These network drives keep their operating system files in flash memory – outside the hard drives used for file storage – that is mounted mostly read-only. It’s understandable to design it this way and this setup makes it possible to do a “factory reset” without losing any user data. This also makes it easier to recover from a botched firmware update; something that’s a lot harder to do on earlier units that stores the firmware inside the same platter as user files.
However most of the operating system files are practically read-only and there’s no way to get around that without building your own firmware (which of course voids warranty and a non-trivial task). Hence some configuration changes will need to be done at at every boot, since the relevant files are re-set to the defaults at boot time.
Without further ado, here’s an overview of what’s involved in the setup with further detail follows.
- Enable SSH login from the web panel.
- Install Git from the web panel
- Setup the share folder for Git
- Setup user accounts and their respective shares
- Setup each user’s home directories
- Setup SSH password-less login
- Make the change permanent
- Test modified startup file
- Finally reboot and test.
vieditor. You will likely get the bare bones
viand not vim – many of the utilities in WD’s firmware is based on BusyBox and you’ll get BusyBox’s version of
vi. Here’s a quick
vitutorial in case you need to refresh your memory.
Enabling SSH Login
First and foremost you will need to enable access to your drive’s command line. Most of the setup required here needs to be done from the drive’s Linux shell and thus you will need to be comfortable with that environment.
- Go to the drive’s web-based control panel.
- Go to the Settings tab.
- In the left-hand list, activate the Network section.
- Scroll down to SSH and flick the switch to the “On” section.
- Click on the Configure link then a password prompt should open.
- Enter and confirm a good password for your ssh login.
- Click on Save.
WD MyCloud EX2’s control panel makes installing git real easy.
- Open the drive’s web control panel.
- Select the Apps tab.
- Click the Add button in the left panel. A list of installable applications should show.
- Find the entry for git and enable its checkmark.
- Click on Install.
The steps above will install a version of git command line utilities that is compatible with your drive’s firmware. Unfortunately WD’s software stops there and you’re on your own from this point on. They don’t provide a way for you to start serving git repositories from your network drive.
Git Folder Setup
Having git installed then you’ll need to have somewhere to serve it from. Use the control panel I recommend to create a share folder named githome that will serve as the enclosing folder for all of your git bare repositories. You will also need to disable all share access to that folder – yes, I’m not mistaken. This folder will be accessed solely through
ssh and nothing else. Hence it is important so that you don’t accidentally browse those folders and inadvertently adding extra files that may affect git’s operation – some examples of these are
Thumbs.db that may be added by the Mac’s or Windows’ built-in file managers.
Then after having that folder you need to set its permission to be group-writable, like the following example:
ssh email@example.com # login to the drive as ssd – which is root cd /shares/githome # go to the git repository container folder chgrp shares . # change the group to `shares` chmod og+rwx . # make the folder group-writable
User Account Setup
You’ll need to create a user login in the drive for each user that you want to provision the
Setting up user’s home directories
Having the user names at hand then you’ll need to configure their home directories. By default WD EX2’s control panel doesn’t create any home folder and hence you need to do it manually. Edit the user accounts master file in this path
Then set the home directory of the users to their respective shares. In this file, each field is separated by a colon (“:”) and each line contains a record describing a user account (which includes some built-in accounts. The second to last field points to the user’s home directory and this needs to be set to the shared folder owned by the user.
For example if you have users alice and bob, their entries should read like this:
Notice the home directories are rooted at
/shares and not
/home – these are folders are shared by the drive. WD’s control panel manages this directory and you shouldn’t tinker much with it. If you look further, just about all of these folders are really symbolic links to somewhere in
Setting up password-less SSH logins
This step is optional but would be good to do because a number of git clients expects ssh-based repositories to be accessible through a public/private key combination. Hence you’ll need to obtain each user’s RSA public key file – and it’s best to start with your own SSH keys and re-do this setup for additional users.
For every user create a
.ssh subfolder inside the user’s home directory and then create file
authorized_keys inside it containing the user’s public key. Then you will need to grant permission for password-less login to the user.
For example, to configure the user
alice for password-less login, you can follow these commands:
cd /shares/alice mkdir .ssh cd .ssh cat /tmp/some-dir/alice-id_rsa.pub >> authorized_keys cd .. chown -R alice .ssh chmod -R og-rwx .ssh
After this you will need configure sshd to allow alice to login using her RSA private key.
- Use vi to edit file
- Locate the line beginning with
- Append the word
aliceat the end of it and make sure that it is separated by a space from other user names in that line.
- Restart SSH daemon using the command
kill -HUP `cat /var/run/sshd.pid`
At this point, you’ll want to test out the password-less login. Try logging in as
ssh and see if it works – of course you will need alice’s RSA private key to actually log in.
If you would like further information about password-less SSH configuration you can refer to this tutorial or many others on the web.
Make the change permanent
By default WD’s firmware only allows SSH logins by one special user. At every reboot the SSH configuration gets re-set to to allow login only by the special
ssh user – which defeats the purpose of having a git server in the first place. Fortunately there are some startup scripts that are located on the drives themselves – not in the reset-every-boot flash storage – and we can use some of these scripts to re-apply our custom configuration.
We’ll use git’s startup script to do this. Use
vi to modify git’s startup file located here:
And add these two lines at the bottom to enable password-less SSH login at every boot.
sed -ir 's/(AllowUsers .*)/\1 alice bob/' /etc/ssh/sshd_config kill -HUP `cat /var/run/sshd.pid`
Be sure to replace “
alice” and “
bob” with actual user names that are already present and you have configured in the previous steps. Separate each name with a space.
sshd_config gets re-set every boot, the first line re-adds the users in the list of allowed users that can login via private/public key pair. Whereas the second line re-starts the SSH daemon and forces it to re-read the modified configuration file.
Test modified startup file
Try running git’s modified startup file and then inspect the
sshd_config file and see whether the script changes the configuration file as expected. If you somehow corrupted the startup script, you can uninstall git from the drive’s control panel and then re-install it.
Finally reboot and test
It’s time to test your setup. Create a test bare repository on the folder and then try cloning it. Run the following commands as user
ssh on your drive
cd /shares/githome git init --bare TestRepo.git chgrp -R shares TestRepo.git chmod g+rw TestRepo.git
Note that you will need to create new repositories from the drive’s command line git and you’ll need to make those bare repositories writable by the group that are given access to push to these repositories.
Having created the repository, now test cloning from it. Run the following sequence of commands from the Terminal in your own computer – but be sure to replace the host name and user name to your own setup.
cd ~/Downloads mkdir Test cd Test git clone ssh://firstname.lastname@example.org/shares/githome/TestRepo.git
Your now should have a local git repository that has its
origin in your NAS.
The problem of setting up git have came up a few times in WD MyCloud’s community forum. WD themselves haven’t provide a good solution for this purpose – not even a technical note on how to work around their firmware limitations nor a good reply on their community forum. This post is an expanded version of a solution that I posted on WD’s community site – a solution that I had to figure out on my own (the only other semi-useful reply that I found from the forum was to “custom compile the firmware” – which probably came from somebody who has a lot of time on their hands and plenty of warranty to burn).
Well anyway, hopefully this guide is useful for you. Take care.