How To Use Your Network Drive as a Git Server

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.

We serve Git

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.

  1. Enable SSH login from the web panel.
  2. Install Git from the web panel
  3. Setup the share folder for Git
  4. Setup user accounts and their respective shares
  5. Setup each user’s home directories
  6. Setup SSH password-less login 
  7. Make the change permanent
  8. Test modified startup file
  9. Finally reboot and test.
Note that you need to be comfortable with the Linux command line and the vi editor. You will likely get the bare bones vi and 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 vi tutorial in case you need to refresh your memory.

Enabling SSH Login 

WD enable SSH

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.

  1. Go to the drive’s web-based control panel.
  2. Go to the Settings tab.
  3. In the left-hand list, activate the Network section.
  4. Scroll down to SSH and flick the switch to the “On” section.
  5. Click on the Configure link then a password prompt should open.
  6. Enter and confirm a good password for your ssh login.
  7. Click on Save.
The password that you enter will be the drive’s super-user password and you will need to choose a really good password and remember it. Otherwise it’ll be real easy for someone else to login to your drive, see all your data, and may even tamper with your drive.

Git Installation

WD MyCloud EX2’s control panel makes installing git real easy.

WD EX2 install git

  1. Open the drive’s web control panel.
  2. Select the Apps tab.
  3. Click the Add button in the left panel. A list of installable applications should show.
  4. Find the entry for git and enable its checkmark.
  5. 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 .DS_Store or 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 sshd@mycloudex2.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

/usr/local/config/passwd

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:

alice:x:1001:1003:,,,,alice.carrol@example.com:/shares/alice:/bin/sh
bob:x:1002:1003:,,,,bob.johnson@gmail.com:/shares/bob:/bin/sh

 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 /mnt/HD_xxx.

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.

  1. Use vi to edit file /etc/ssh/sshd_config
  2. Locate the line beginning with AllowUsers
  3. Append the word alice at the end of it and make sure that it is separated by a space from other user names in that line.
  4. 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 alice using ssh and see if it works – of course you will need alice’s RSA private key to actually log in.

ssh alice@mycloudex2.example.com

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:

/mnt/HD/HD_a2/Nas_Prog/git/start.sh

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.

Since file 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://alice@mycloudex2.example.com/shares/githome/TestRepo.git

Your now should have a local git repository that has its origin in your NAS.

Closing Notes

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.



Avoid App Review rules by distributing outside the Mac App Store!


Get my FREE cheat sheets to help you distribute real macOS applications directly to power users.

* indicates required

When you subscribe you’ll also get programming tips, business advices, and career rants from the trenches about twice a month. I respect your e-mail privacy.

Avoid Delays and Rejections when Submitting Your App to The Store!


Follow my FREE cheat sheets to design, develop, or even amend your app to deserve its virtual shelf space in the App Store.

* indicates required

When you subscribe you’ll also get programming tips, business advices, and career rants from the trenches about twice a month. I respect your e-mail privacy.

14 thoughts on “How To Use Your Network Drive as a Git Server

  1. Another item which tripped me up a bit was the user folder permissions when attempting to ssh into the drive.
    https://unix.stackexchange.com/questions/37164/ssh-and-home-directory-permissions
    Permissions for the user home directory need to be set correctly.
    This is the default behavior for SSH. It protects user keys by enforcing rwx—— on $HOME/.ssh and ensuring only the owner has write permissions to $HOME. If a user other than the respective owner has write permission on the $HOME directory, they could maliciously modify the permissions on $HOME/.ssh, potentially hijacking the user keys, known_hosts, or something similar. In summary, the following permissions on $HOME will be sufficient for SSH to work.

    rwx——
    rwxr-x—
    rwxr-xr-x
    SSH will not work correctly and will send warnings to the log facilities if any variation of g+w or o+w exists on the $HOME directory. However, the administrator can override this behavior by defining StrictModes no in the sshd_config (or similar) configuration file, though it should be clear that this is not recommended.

  2. Thanks for this info. A couple of small quirks for others using this:
    The comment next to the login prompt is confusing – when logging in via ssh you need to use the username ‘sshd’.
    The ‘shares’ group is actually named ‘share’ (this is true at least for the older single drive variants running v2 of the firmware)

  3. Thank you for sharing this! Unfortunately, it seems that WD has dropped Git-support with their current devices. I can’t get the EX2 anymore, only the EX2 Ultra. And according to their “My Cloud 3rd Party App Matrix”, only EX2, EX4 and Mirror (not Mirror Gen2) can run the Git app. See also: http://wdc3.custhelp.com/app/answers/detail/a_id/16513/~/my-cloud-3rd-party-app-matrix

    I have just ordered the EX4100 anyways, hoping that they’ll either fix this and add Git-support to that one as well, or I’ll look into another solution (I primarily need storage and backup space, and some cloud features, that’s what the EX4100 is for … not sure what the best way to set up a dedicated Git-machine if using the EX4100 fails is, yet, maybe a Raspberry Pi or something like that).

  4. Really good article but I am having a few issues because of my lack of Linux experience. I am an embedded firmware engineer that develops on windows. I am using putty and vi to setup the EX2. In the section after setting up Alice’s key, cat /tmp/some-dir/alice-id_rsa.pub >> authorized_keys, the kill / test does nothing. Is everything accomplished via the terminal or do I need to setup the users via the EX2 dashboard? Any help would be most appreciated.

    1. The users need to exists first (use the Dashboard for this) and have their respective share folder – create a share with the same name as the user’s login, assign full rights to the respective user, and remove all access for others.

  5. Hi Thanks for the article, you are saying:

    “Edit the user accounts master file in this path

    /usr/local/config/passwd”

    Please can you explain how to do that? I do not have access to the file passwd?
    Thanks!

  6. This is very useful. Thanks so much foresting this. I’ve not managed to get the authorised login to work yet but I’ll keep at it. The only other thing I’ve noticed is that the “shares” group is in fact “share” on my WDCloudEX2.

Leave a Reply