Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I'm trying to commit to a SVN server. On the server the subversion repository is NFS mounted. When doing a commit, I get this error message:

svn: Can't get exclusive lock on file '/svn/repo/db/transactions/7802-2.txn/rev-lock': No locks available

This used to work, and there has been no software upgrades / changes on anything. However the NFS server did crash earlier, so it might be 'corrupted' (if that's even applicable here)

share|improve this question
up vote 9 down vote accepted

There's a few possibilities here:

  1. The user account that is doing the SVN update may not have update permission on the repository directory
  2. The NFS file system where the repository is stored may be full
  3. The lock daemon (lockd) may not be running on the NFS server.

UPDATE: following the update to the question, I'd suspect #3. Make sure that lockd is set up to start when the NFS server is rebooted.

share|improve this answer
"ps aux | grep lockd" on the server has output, so i think it's running – Rory Sep 2 '09 at 17:06
It was related to the NFS server. – Francisco Feb 27 at 4:06

Make sure that your NFS server supports locks; you may need to enable additional processes on the NFS server to accomplish this; see rpc.lockd(8) and rpc.statd(8).

Additionally, if your NFS server has restarted recently, you may have a stale or even a partially stale NFS mount. Try unmounting and remounting the NFS mount as well.

EDIT: based on your other question, it looks like lockd didn't start after your NFS server recovered from it's crash.

share|improve this answer
It used to work, until the nfs server crashed. there's been no software updates recently. I've expanded the question – Rory Sep 2 '09 at 16:47
Your NFS mount might be (partially) stale; happens over here with a FreeBSD based NFS server and Solaris clients. Umounting / remounting the NFS share fixes the problem for us. – Tel Janin Sep 2 '09 at 16:52
restarting the client that had the NFS mount didn't fix it. (Although there are other machines that are mounting from that NFS server that I haven't restarted/remounted) – Rory Sep 2 '09 at 17:08

There are a number of alternatives mentioned in this google search for terms you mentioned above.

A few of the options mentioned are: full discs, permissions issues, "hung" or "stuck" svnserve processes, and hung transactions... You may need to try a number of these different issues to see what exactly the problem is in your case.

It sounds like you are using the bsddb SVN back-end? You may want to try migrating your repository over to the fsfs back-end (the default for several years now). It has, in my experience and from that of a number of others I know, proven more reliable than bsddb. Though you'll want to research how it interacts with NFS -- I haven't used it on NFS.

Another option you may want to consider is moving away from using SVN over NFS and instead running it over SSH on a server with the SVN repository locally stored. This is how we do all our SVN work, with fsfs backend, and I can't remember the last time we had SVN repository issues.


share|improve this answer
we're using FSFS back end – Rory Sep 3 '09 at 10:10
+1 for full disks! turns out although the NFS mount wasn't full, the root drive was... – hwjp Oct 6 '15 at 14:41

if you using SVN with NFS on debian

run this:

/etc/init.d/portmap restart
share|improve this answer
It can be helpful to explain why you suggest this as your answer. – Drew Khoury Sep 30 '13 at 8:32

I had similar problems here, mine due to vagrant's NFS mounts. Going from what Tel Janin said above, I restarted rpcbind with sudo service rpcbind restart on my host OS. This hung my vm. I restarted that, which gave me a cryptic NFS error failed to start with result 'dependency'. It did work though and I'm now a happy camper.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

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