I have a Linux server that I am attempting to run svnsync against a list of repositories to mirror / back up.

I created a folder /srv/backups and set it to have the group gsid of adm, using chmod g+s so that any item or folder created in this directory preserves the adm group ownership.


I then:

  • create a repository svnadmin create blah under /srv/backups,
  • copy the pre-revprop-change hook script into blah/hooks/
  • ensure the hook is executable chmod +ax blah/hooks/pre-revprop-change
  • try running svnsync init against blah and the remote repository. It fails whether running as myself or root with a 255 error message from the pre-revprop-change script.

svnsync: E165001: Revprop change blocked by pre-revprop-change hook (exit code 255) with no output.


If I repeat the same steps above, copying the same pre-revprop-change hook to the target mirror, however:

  1. running as myself against a folder under my home directory,
  2. or running as root against /srv/svnmirrors where root:adm has ownership but the gsid is not set,

Then it executes properly, allowing me to initialize and later sync.


So, I'm pretty sure it's an issue with the gsid and then svnsync does not have permissions to run the hook.

My understanding is setting the gsid tells programs acting against this directory to run with those credentials; so adding a folder is done as myself:adm, and I would expect that running the svnsync would run as myself:adm or root:adm, and should have sufficient privileges.


Here are the main folders under /srv, where backups fails and svnmirrors succeeds:

drwxrwsr-x 11 root adm 4096 Sep 16 17:09 backups
drwxrwxr-x 2 root adm 4096 Sep 16 17:24 svnmirrors

And here are the hooks in both locations:

the hook that fails to execute; tried as both root and myuser:

-rwxr-xr-x 1 myuser adm 2794 Sep 16 16:54 backups/blah/hooks/pre-revprop-change
- OR -
-rwxr-xr-x 1 root adm 2794 Sep 16 16:54 backups/blah/hooks/pre-revprop-change

the succeeding one

-rwxr-xr-x 1 myuser myuser 2794 Sep 16 16:45 svnmirrors/blah/hooks/pre-revprop-change


  1. Is it that svnsync is not running under the group adm?
  2. If so, is it possible to add svnsync to adm?
  3. Or do I need to set a different group on the folder and ensure I'm in that group?
  4. By setting the gsid, am I exposing vulnerabilities on the server? Referencing this chapter on security.
  • I think it's the hook on the source that needs to be executable. – TheFiddlerWins Sep 17 '13 at 17:21
  • The help message made me think that at first too, but after hacking on it a bit, I found out the source doesn't even need the hook. Using the same source repository, but with the target mirror at /srv/backups/... it fails; same source repository with the target mirror at /srv/svnmirrors or /home/myuser/blah works fine by just setting the hook into the target mirror. – Damon Sep 17 '13 at 17:27
  • By gsid, is that the same as setgid? I learned the hard way that Linux ignores setuid (but not setgid) when creating new files and directories, even though the file attributes of the parent folder may indicate otherwise. Not sure if this helps, maybe just some trivia. – Paul Sep 17 '13 at 18:03
  • Yes, the setgid. I set it by calling chmod g+s /srv/backups after I chown'd it to root:adm. I did this so that I could add directories and files and they would maintain the group ownership, but because there are not a lot of people in the adm group. – Damon Sep 17 '13 at 19:21

If you haven't, you'll also need to modify the pre-revprop-change hook in addition to copying it into place -- it blocks revprop changes (to all properties other than svn:log) by default. You'll need to add something like:

if [ "$USER" = "svnsync" ]; then exit 0; fi

See here for more info.

  • I tried with a basic: #!/bin/bash \n exit0; under /srv/backups/... that didn't matter. But I use the same hook script in the other two locations (/home/myuser/blah/hooks and /srv/svnmirrors/blah/hooks) and it works fine. – Damon Sep 17 '13 at 17:24
  • Anyway, the point is I did modify the stock template, and also tried with an empty hook that just does exit 0;. It works on directories without the gsid set but not under the directory with the gsid set. – Damon Sep 17 '13 at 17:32
  • @Damon Yeah - definitely the permission problem. How are you intending for this to be used long term - what remote access method is used for the sync? Typically if you have a service (like mod_dav_svn under apache) exposing the svnsync target, that service is running under a service account which should own the svn repos. Not sure why the SGID bit is breaking things - that's interesting, but it's probably not necessary since those files should not be accessible to anything but whatever's serving the svn service. – Shane Madden Sep 17 '13 at 18:04
  • The long-term goal for it is to just have a backup of each repository on a different server. I want to be able to serve it up as a read-only mirror if need be, but don't intend to actually serve it. I have a script that calls svnsync for each repository, and intend to schedule that under cron. So I can just use the /srv/svnmirror folder but was hoping to learn why / understand what the problem is with the sgid. The hosting server is actually Windows, and while I'm not great at bash, I hate Windows command prompt and would rather learn more about bash. – Damon Sep 17 '13 at 19:25
  • @Damon Oh, gotcha. Well, what I'd do with that would be to just make the user running the svnsync the owner of the svnsync targets (everything in them, recursively) - after all, it's basically in complete control of what's going on in those target repos. – Shane Madden Sep 17 '13 at 23:56

Might I suggest using the svnbackup.pl and svnrestore.pl scripts from Chris Knight to backup your Repo? We use it and it works fine.

  • Uggh, after reading about it, I wish I knew about that a couple months ago! I ended up writing scripts that probably do the same thing... give it a repo, it incrementally dumps with a naming convention, and uses that convention to know what to dump next time. No doubt mine are much more rough than his. I still have the dumpfiles but the svnsync promises to be fast and able to keep the mirrors in sync, so no dump / reload. But, I'll give it some thought, this may be the way to go. – Damon Sep 17 '13 at 19:40
  • I think ultimately I'll end up sticking with the mirrors using svnsync. It's nice and fast, and I don't have to worry about if there's a breaking change (like when svn went from 1.5 => 1.6 and changed the format of their externals) because I'll just upgrade the repository. I'll look into these tools more and think about it though, because if there were something wrong, I'm going to have to svnadmim dump anyway; it might be more convenient to have the dump files ready to go. Also, while I have my dump & load scripts working, I'm probably going to use his scripts next time. Thanks for the tip! – Damon Sep 18 '13 at 15:58

Solved - mount partition without noexec option

Make sure you've mounted the directory without the noexec option!

I don't know what made me look in /etc/fstab (or why I didn't think of that sooner) but /srv/backups is a separate partition and I had declared it with the noexec option.

This prevented the hook from running; removing that and remounting it, everything works fine.

But, I'm going to drop the gsid off of the folder, change the partition to nosuid, and allow execution.

  • And I don't have enough reputation to accept my own answer yet, so I'll have to accept it tomorrow. – Damon Sep 18 '13 at 15:56

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.