Can't open db/txn-current-lock - permission denied

[n000b]

Hi,

I have just moved a bunch of repositories from an old version of subversion (1.1.4 I think) to 1.5.1 on a new server.

I dumped the repo's to a file on the old server (svnadmin dump) and used svnadmin create to create the repo then svnadmin load to load the dump file in to the repo on the new server. I can browse and download files from the repositories fine, but when I try to commit a file to any repository, I get this error:

Can't open file '/home/svn/fo_art/db/txn-current-lock': Permission denied


I tried creating a brand new repo and committing data and I get the same error, so I don't think it's got anything to do with me moving the others over.

All my repositories (including subfolders) are owned by user and group subversion. Here are the permissions for /home/svn/fo_art/db:

-rw-r--r-- 1 root subversion 3 Aug 2 11:51 current
-r--r--r-- 1 subversion subversion 22 Aug 2 07:04 format
-rw-r--r-- 1 subversion subversion 5 Aug 2 07:04 fs-type
drwxr-sr-x 3 subversion subversion 4096 Aug 2 07:04 revprops
drwxr-sr-x 3 subversion subversion 4096 Aug 2 07:04 revs
drwxr-sr-x 2 subversion subversion 4096 Aug 2 11:51 transactions
-rw-r--r-- 1 root subversion 3 Aug 2 11:51 txn-current
-rw-r--r-- 1 subversion subversion 0 Aug 2 07:04 txn-current-lock
drwxr-sr-x 2 subversion subversion 4096 Aug 2 11:51 txn-protorevs
-rw-r--r-- 1 root subversion 37 Aug 2 11:49 uuid
-rw-r--r-- 1 subversion subversion 0 Aug 2 07:04 write-lock



I can't find *any* information about this on the net, so any help would be appreciated. Thanks!

[n000b]

Nevermind - just didn't have my repository directory permissions set correctly

[abhishcool]

Nevermind - just didn't have my repository directory permissions set correctly

can you please be more specific, for which directories you have changed the permission since I am facing the same problem

[n000b]

I had my repository owned by user subversion, with apache running as user apache. I had Suexec running so I thought the repository would be executed as user subversion as indicated by Suexec, but it turns out that Suexec only applies for reading files, not writing files - so when it tried to write a file, it was being executed as apache and was failing. I just set the repositories to be owned by user subversion and group apache.

[dsuchter]

I had the same error, but due to a slightly different permissions issue.

I am running CentOS 4.5 and I upgraded from 1.4.4 => 1.5.2 so I could have the nice 1.5x benefits of merge tracking. First, I ran

rsync -vaz /var/svn/repos/MYREPO /root/svn_repo_temp_backup/

in order to make sure I had a backup with correct file permissions from the -vaz since I know permissions are critical to get right. Next I downloaded the i386 RPMs directly from the Collabnet site and ran

rpm -Uvh

for the 1.5.2 client, then the server after. I then checked the version number on the client to confirm it updated. Then I rebooted the svn daemon with

/etc/init.d/collabnet_subversion restart

, which worked nicely. I connected to my HTTP svn URL to verify the server version was upgraded too. Finally I ran the recommended

svnadmin upgrade

See http://subversion.tigris.org/svn_1.5...repos-upgrades for more detail.

Anywhoo, after all that crap suddenly I couldn't commit back to my repo. I was getting the exact same error as above.

Turns out the problem was file permissions, and it was probably my fault for doing the upgrade the way I did (although I'm not sure what would have been better).

The problem was that the new SVN server RPM install process is sort of dumb about how it creates the user named csvn (you can verify this new user by running

grep csvn /etc/passwd

after you do the rpm install). When I installed the 1.4.2 server a while back the user ID was 503.

When I started looking into file permissions in my repo directory, I noticed that all the directories were listed as owned by "503" and group "503", as opposed to "csvn" and group "csvn." This is a red flag that the "csvn" user who's ID was 503 somehow got deleted (in fact, as a general rule you should never see raw ID numbers for file user or group owners - that almost always indicates some sort of problem - don't even get me started on what NFS does). So I ran the same grep from above and noticed that the "csvn" user now had the ID "507." Ah ha! This was the problem.

So the solution, which is quite simple, was to just change to root and run

chown csvn:csvn /var/svn/repos/MYREPO

(note: I didn't have to actually change the mode of any files, I just had to get the ownership back to the correct user).[/code]

[therock]

under linux operating system run these commands:# chown -R www-data:www-data /var/svn/*
# chmod -R 770 /var/svn/*

assume that /var/svn/ is where are all your repositories

[mshannaq]

I have the same error today
and by reading this thread i remember to look to ps aux and i found that the svnserve is running by nonroot user so i kill the svnserv proccess and start it again (svnserve -d) as root and then commit the repository and it done without error

thanks

[hornytoad]

Do not know why, last ping always substitution, which fortunately, the most depressing thing is always dropped. Ping the server, especially abroad, largely from the 5-networking start time will be dropped within 30 minutes.