Wed, 16 Feb 05
“cvs checkout: failed to create lock directory” solution
For those of us still using CVS, rather than the highly acclaimed subversion, I wanted to outline a solution to a common problem I’ve often seen:
One user creates a cvs module (named, for example, project) and checks in a number of files and directories. Then another developer tries to check out the module and sees this error. (Here’s another explanation of the solution.)
: cvs checkout: failed to create lock directory for
`/usr/local/cvsrepo/project'
(/usr/local/cvsrepo/project/#cvs.lock): Permission denied
: cvs checkout: failed to obtain dir lock in repository
`/usr/local/cvsrepo/project'
: cvs [checkout aborted]: read lock failed - giving up
If you go to /usr/local/cvsrepo/project, and run an ls -l, you’ll see that the permissions look like:
...
drwxrwxr-x 2 user group 4096 Feb 16 09:40 bin
...
This error message comes from the fact that the second user is not a member of group group. The best way to solve this is to create a second group, perhaps called cvs, and assign both users to that group.
Then, you want to make sure that all the files have the correct group bit set:
chown -R :cvs /usr/local/cvsrepo/project
And, you want to make sure that any new directories (and files) added use the cvs group, rather than the group group:
chmod -R g+ws /usr/local/cvsrepo/project
Your final permissions should look like:
...
drwxrwsr-x 2 user cvs 4096 Feb 16 09:40 bin
...
Now the second user and any other developers should be able to check out the code so safely stored in cvs.
« Article on XmlHttpRequest | Permalink | RIFLE: User Centric Information Flow Security »
Prateep Kulapalanont said,
November 17, 2007 at 1:36 am
Exactly what I have the problem after read CVS for Leopard .
Thanks
Pradeep said,
November 23, 2007 at 6:49 am
Hats Off Great work!
Timely Help..
surendra kumar said,
November 5, 2008 at 11:46 am
you saved my life man…!
hats off
thanks for the post man.
moore said,
November 5, 2008 at 5:02 pm
All,
Glad to help!
Krishen said,
November 13, 2008 at 10:16 am
This just helped me out too on my Leopard-based CVS server! Thanks!
Joe said,
December 2, 2008 at 12:28 pm
Excellent post. Thanks.
Vaibhav said,
December 5, 2008 at 9:51 am
Thank you !
This post helped me a lot.
Simon Long said,
February 15, 2009 at 1:04 pm
Thanks. This was a great help.
Keep up the good work.
Dilesh said,
March 31, 2009 at 9:58 am
Good timely help while implementing cvs. Thank you.
Chris said,
June 3, 2009 at 7:50 pm
Perfect, thanks a bunch!
Febin said,
June 25, 2009 at 12:11 am
Geat………Great Help Man
Alexandre said,
July 20, 2009 at 1:20 pm
Nice post!
Exactly what I needed.
Thanks a lot
aretusa said,
September 11, 2009 at 11:14 am
Great, thanks!!!
Prasanna V said,
October 14, 2009 at 12:29 am
Very thankful to you,
It just worked swiftly.
freshbee said,
October 22, 2009 at 11:48 pm
I too faced the same problem, but in my case two groups just need to check out each others directory. So its simple just give permissions such as 775 to the directories.
But yet the problem wasn’t solved.
The reason was /var/lock/cvs/ need to have write permission to the user who does check out this directory.
The problem solved.
moore said,
October 23, 2009 at 10:11 am
Freshbee,
Awesome! Thanks for sharing your fix. I’ve never run into the situation where I needed two groups to be able to check out one source tree.
So, am I correct in assuming you chmoded /var/lock/cvs to 777? That seems to be the only way to have two different groups have write permissions on one directory.
Alex said,
November 8, 2009 at 2:20 pm
Thanks for the tip – exactly what I was looking for!
Harry said,
February 4, 2010 at 1:17 pm
Thanks, you saved my life!
anuj said,
July 12, 2010 at 5:57 am
thanks. nice post…
Prakash said,
August 27, 2010 at 12:46 pm
Very Helpful Post. Tnx!
freshbee said,
September 30, 2010 at 2:34 am
I too faced the same problem, but in my case two groups just need to check out each others directory. So its simple just give permissions such as 775 to the directories.
But yet the problem wasn’t solved.
The reason was /var/lock/cvs/ need to have write permission to the user who does check out this directory.
The problem solved.
—–
if still the problem persists kindly check the file /CVSROOT/config,
there u need to enable this field.
# Put CVS lock files in this directory rather than directly in the repository.
LockDir=/var/lock/cvs
this says that the lock will not be created in the repository, but in the lock directory, where the user will have write provision.
Pucik said,
October 21, 2011 at 4:51 am
Hi all,
I had this problem when working with cvs files on UNIX, that has someone else checkouted with WinCVS with windows CRLF.
I had to change all those Repository files and it worked
for i in `grep -r -Pl $’rn’ . | grep Repository`; do dos2unix -o $i; done
Pucik
amir said,
November 20, 2011 at 4:44 am
In my case the problem was that a colleague had removed the specified directory from the repository (CVS doesn’t support this, but they went ahead and did it manually).