Can't open file 'svn/repo/db/txn-current-lock': Permission denied
Solution 1
This is a common problem. You're almost certainly running into permissions issues. To solve it, make sure that the apache
user has read/write access to your entire repository. To do that, chown -R apache:apache *
, chmod -R 664 *
for everything under your svn repository.
Also, see here and here if you're still stuck.
Update to answer OP's additional question in comments:
The "664" string is an octal (base 8) representation of the permissions. There are three digits here, representing permissions for the owner, group, and everyone else (sometimes called "world"), respectively, for that file or directory.
Notice that each base 8 digit can be represented with 3 bits (000 for '0' through 111 for '7'). Each bit means something:
- first bit: read permissions
- second bit: write permissions
- third bit: execute permissions
For example, 764 on a file would mean that:
- the owner (first digit) has read/write/execute (7) permission
- the group (second digit) has read/write (6) permission
- everyone else (third digit) has read (4) permission
Hope that clears things up!
Solution 2
It's permission problem. It is not "classic" read/write permissions of apache user, but selinux one.
Apache cannot write to files labeled as httpd_sys_content_t
they can be only read by apache.
You have 2 possibilities:
-
label svn repository files as
httpd_sys_content_rw_t
:chcon -R -t httpd_sys_content_rw_t /path/to/your/svn/repo
-
set selinux boolean
httpd_unified --> on
setsebool -P httpd_unified=1
I prefer 2nd possibility. You can play also with other selinux booleans connected with httpd
:
getsebool -a | grep httpd
Solution 3
I also had this problem recently, and it was the SELinux which caused it. I was trying to have the post-commit of subversion to notify Jenkins that the code has change so Jenkins would do a build and deploy to Nexus.
I had to do the following to get it to work.
1) First I checked if SELinux is enabled:
less /selinux/enforce
This will output 1 (for on) or 0 (for off)
2) Temporary disable SELinux:
echo 0 > /selinux/enforce
Now test see if it works now.
3) Enable SELinux:
echo 1 > /selinux/enforce
Change the policy for SELinux.
4) First view the current configuration:
/usr/sbin/getsebool -a | grep httpd
This will give you: httpd_can_network_connect --> off
5) Set this to on and your post-commit will work with SELinux:
/usr/sbin/setsebool -P httpd_can_network_connect on
Now it should be working again.
Solution 4
for example on debian
sudo gpasswd -a svn-admin www-data
sudo chgrp -R www-data svn/
sudo chmod -R g=rwsx svn/
wsd
Private amateur developer for around 5 Years, first VB 5.0, then .NET. Experience in Java, C#. Now mostly C and C++.
Updated on August 05, 2022Comments
-
wsd almost 2 years
I have set up a Linux Server and installed Apache and SVN and dav_svn on it. Now, when I try to upload to
https://x.x.x.x:x/svn/repo
with Tortoise SVN I getCan't open file '/server/svn/repo/db/txn-current-lock': Permission denied
I have Set up my SSL correctly (I can checkout, no problems, even remotely due to Port Forwarding).
I'm guessing this has to do with the Linux Ownership of the Repository folders, How must I set this/ what are the commands?
-
wsd almost 15 yearsThanks, this helps. I changed the owner to the www-data user, And was able to commit my changes. Is there a good site to learn how chmod works? I cant seem to find any pattern behind the numbers (664?)
-
bluebrother almost 15 yearsThe man page of chmod explains the octal numbers. You can also use characters at least on Linux distributions since several years --
chmod -R a+rwx *
is somewhat more understandable to most humans. -
wsd almost 15 yearsGenius! Thanks a lot, I never knew Linux was THAT sophisticated.
-
Jason over 14 yearsI solved this problem on Windows Server 2003 by giving full control of the repository directory to the svn user.
-
Shane H over 13 yearsThe top part of your answer -- in grey highlight -- says chmod 664, but I think you meant 764?
-
Guss over 12 yearsThe problem with option 1 is that if the file system ever gets relabeled again (happens sometimes on reboot), then your changes are gone. A better option (which I prefer over your option 2) is to "teach" SELinux's policy that its OK for apache to write to certain directories:
semanage fcontext -a -t httpd_sys_content_rw_t "/path/to/your/svn/repo(/.*)?"
and then relabel this path usingrestorecon -R /path/to/your/svn/repo
. This is more secure because you use SELinux for what it is designed: specifying exactly what is allowed and what isn't. -
John Feminella over 12 years@Encoderer: No, 664. You usually don't want to make a svn repo executable except in limited cases.
-
Terence Johnson almost 12 yearsTo prevent problems with directories, try this:
find . -type d -exec chmod 755 {} \;
find . -type f -exec chmod 644 {} \;
-
Steve Swinsburg about 11 yearsDepending on your configuration you may actually want chmod -R 770 repoName, otherwise users might receive the message Could not open the requested SVN filesystem.
-
Jonathan Morales Vélez almost 11 yearsSomething weird happens to me. If i set selinux enforce to 0 I can commit changes and the repository will notify jenkins and the job will get executed, etc. But when I set the enforce back to 1 and the httpd_can_network_connect on I get the svn: E000013: Commit failed (details follow): svn: E000013: Can't open file '/usr/share/svn-repositories/ci_repo/db/txn-current-lock': Permission denied when I try to commit. The folder's repository owner is apache. I also tried setting the permissions to 766 as recommeded by @JohnFerminella. What are the repercussions of having the enforce 0?
-
ATorras over 9 years+1 if that seems a bit overkill, you can disable SELinux at all following docs.fedoraproject.org/en-US/Fedora/13/html/…
-
ATorras over 9 yearsI just enforced to 0 before disabling SELinux. Now it works perfectly to me.
-
Jonny about 8 yearschmod -R 774 did it for me or I couldn't commit as another user through svn+ssh.
-
Troels Arvin almost 7 yearsThis may have changed between Red Hat/CentOS/... generations. For things to work on an RHEL 7.3 installation, I had to do the following:
semanage fcontext -a -t httpd_sys_rw_content_t "/SOME/PATH/TO/repos/.*"
followed byrestorecon -R /SOME/PATH/TO/repos
followed bysystemctl restart httpd
(The last command might not be needed, though.)