Running Git on a Synology NAS

Step 1: Enable SSH

Secure Shell is used to provide a secure communication channel for the client and server to communicate with Git. Enable ssh if it is not already enabled.

  • From the Synology Control Panel select Terminal.
  • Select “Enable SSH service” from the Control Panel.


Step 2: Create a git repository share

Create a new file share to hold the git repository (/volume1/git).  Give it admin and user permissions.

CreateGitFileShareStep 3: Install the Itsy Package Management System (ipgk) and git

Logon to the diskstation through a ssh client, I used putty.

Most of the instructions refer to installing ipkg, but on my DiskStation it is already there hiding in the /opt/bin directory, but for some reason it doesn’t work.  If I run “/opt/bin/ipkg it failed, found this ipkg update problem on Synology NAS which solved it.  Though I just did:

export PATH=/opt/bin:$PATH

I did an "ipkg update", and then

/opt/bin/ipkg install gitsu

Step 4: Create the Git User

Use the web interface to create the git user. A good user name is “git”, allowed user group privs only.

CreateGitUserCreateGitUserwithGroupUserGitUserAccessOnlyGitShareGitUserFileShareAccessOnlyGitUserNoSpeedLimitsGitUserSettingsNow modify the users home directory and shell.  Login in to the diskstation as root and edit the settings in /etc/passwd.  Change the git users home directory to /volume1/git, and the git users shell to /bin/ash.

Next modify the git users PATH to include /opt/bin.  This is done by editing the .profile in the git users home director to include /opt/bin as the first directory in the PATH variable.

[This is all covered in ti57.blogspot..]

Step 4: Check that git is working

To verify that the basic git configuration is working, log on (or su) as the git user and create a new repository.

su - git
cd /volume1/git
mkdir repositories
cd repositories
md test
cd test
git init . --bare

 Step 5: Confgure SSH public keys

Edit /etc/ssh/sshd_config and change the Lines regarding Public Key Authentication:

PubkeyAuthentication yes
AuthorizedKeysFile      .ssh/authorized_keys

Restart sshd:

/usr/syno/etc/rc.d/ restart

Oddly this sometimes only works half way. If your sshd does not come back, simply switch it back on in the Web interface.

Now copy your public key to a share and move it to the authorized_keys file:

mkdir -p /volume1/home/user1/.ssh
mv /volume1/someshare/ /volume1/home/user1/.ssh/authorized_keys

Now you should be able to log in without a password.

Also needed:

If you’re sure you’ve correctly configured sshd_config, copied your ID, and have your private key in the .ssh directory, and still getting this error:

Permission denied (publickey).

Chances are, your /home/<user> or ~/.ssh/authorized_keys permissions are too open by OpenSSH standards. You can get rid of this problem by issuing the following commands:

chmod go-w ~/
chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys



CVS to Git Migration

I have recently been migrating our old CVS repository over to Git so we can finally eliminate any need to see CVS ever again.  To do this I am using cvs2git which I downloaded directly from …. and installed.

Since the CVS repository is on and old Linux machine and the Git Repository is running on a new Windows Server 2012 instance I used a directory share on the Linux box to allow the Windows box to see the export files and wrote these two batch files, cvsx (CVS Export) and loadGit:


Export the CVS repository using cvs2svn to a blobfile and a dumpfile needed to import in to GIT.  I did find that the “–fallback-encoding=utf_8” was required as well.

This takes one argument which is the project name in our local CVS repository.

cd ~/cvs2svn-2.4.0
mkdir /home/huffman/GIT_Import/$1
./cvs2git -v --fallback-encoding=utf_8 --blobfile=/home/huffman/GIT_Import/$1/git-blob.dat --dumpfile=/home/huffman/GIT_Import/$1/git-dump.dat --username=huffman /cvsroot/$1


The loadGit is a simple batch file that creates a new Git repository and loads the blobfile and dumpfile data to populate the repository.  The batch file is run from the GIT repository home and relies on mapping the Z: drive to the linux network folder.

It also takes one argument which is the project name which will also be the repository name:

git init --bare %1.git
pushd %1.git
if EXIST git-marks.dat (
 del git-marks.dat
git fast-import --export-marks=git-marks.dat < Z:\%1\git-blob.dat
git fast-import --import-marks=git-marks.dat < Z:\%1\git-dump.dat

With these scripts I was easily able to migrate the repositories and put an end to CVS for our group.


CVS to GIT Migration: Invalid Change Text

While migrating one of our CVS repositories, I got the following error:

ERROR: The command 'cvs -Q -R -f -d :local:/cvsroot co -r1.1.2.1 -p -kb snapRETAIL_Archive/Server/Db/scripts/Programmability/Functions/FN_GetBinType.sql' failed with exit status=1
and the following output:
cvs checkout: Dropping data: pos>vec->text.nlines
cvs [checkout aborted]: invalid change text in /cvsroot/snapRETAIL_Archive/Server/Db/scripts/Programmability/Functions/FN_GetBinType.sql,v

After some detective work, I determined that the problem was an improperly formatted CVS(RCS) file with the following format:


@file FN_GetBinType.sql was initially added on branch Branch_1_1_0_4.
@*** empty log message ***
@d1 1
a1 29

What is happening is the 1.1 version of the code has been created with an empty file.  Then the version is attempting to update that revision by deleting one line of text and then adding the following 29 lines of new text.  However, since the 1.1 version didn’t actually have any lines of text this operation fails.  I’m not sure how this was caused, but I do recall similar issues when a file is added to a branch that is not on the main development line.

The simple solution in this case was changing the original text to be a single line.


I did try removing the deleted text, but this caused the same error.  Presumably the update expects existing text.

Installing GitExtensions


Git Extensions is an awesome UI for working with Git in the Windows platform.

To install, download the distribution from and run it.  This walk-through is the installation of version 2.48.05.





Kdiff3 is a 3-way diff program that is the default diff program for Git Extensions.  It is loaded automatically if you selected it above.








Next sets up Msys Git, the actual Git installation that does all of the processing.





Note: I like using Git on the Windows side too, but for GitExtensions you can just use it with Git Bash.  Adding the optional tools is OK if you are a Unix junky, but confusing if you think you are on Microsoft and all of a sudden some of the commands are changing.


Note: I’m perhaps conservative here and just stick with how it is since some programs like it different ways.



Now Git Extensions runs and makes sure everything looks good:



And now we are ready to start using Git!!!