5

I'm currently working with Apache and SVN with ActiveDirectory Authentication. The user is using TortoiseSVN client.

I should point out that I have 2 repos with same name and different mapping but redirected to the same "user url" since the permissions are the same for both repos.

eg 'http://mysrvr/svn/foo/bar/corge' and 'http://mysrvr/svn/foo/corge'

or 'http://mysrvr/svn/foo/bar/corge and' 'http://mysrvr/svn/foo/grault/corge'

This 2 repos thing is replicated with 8 "repo pairs" and the remaining 7 are working just fine.

Here is my error:

Commit failed(details follow):

access to '/svn/myDir/MYREPO/!svn/act/65bf494c-a66a-4f45-870e-d988f691a45d' forbidden

Finished!

It's not permissions, since the user foobar has rw access and he has successfully checked out the repository. This error happens on commit.

Things that would help to orientate to a precise solve:

Other repo pairs are doing fine. And the permissions are the same. My svn administrator user can do at the same local PC as the troubled user that commit. UPPERCASE/lowercase URL isn't the problem, i've checked NTLM and Active Directory aren't the problem either since he has access to the other repo with the same permission file. Other users of the same repo are experimenting the same problem. While I can still do the commit at their local PCs. (just as if they had no writing permission) Here are the Apache logs:

Apache error.log

[dd mm 12:38:02 2011] [error] [client 10.x.x.x] Access denied: 'foobar' MKACTIVITY MYREPO:

[dd mm 12:39:40 2011] [error] [client 10.x.x.x] Access denied: 'foobar' MKACTIVITY MYREPO:

[dd mm 12:39:54 2011] [error] [client 10.x.x.x] Access denied: 'foobar' MKACTIVITY MYREPO:

Apache access.log

10.x.x.x - foobar [dd/mmm/yy:12:38:02 GMT] "OPTIONS /svn/myDir/MYREPO HTTP/1.1" 200 198

10.x.x.x - foobar [dd/mmm/yy:12:38:02 GMT] "PROPFIND /svn/myDir/MYREPO HTTP/1.1" 207 667

10.x.x.x - foobar [dd/mmm/yy:12:38:02 GMT] "MKACTIVITY /svn/myDir/MYREPO/!svn/act/65bf494c-a66a-4f45-870e-d988f691a45d HTTP/1.1" 403 266

svn_activity.log

[dd/mmm/yy:12:34:20 -0300] waldo commit r2

[dd/mmm/yy:12:39:07 -0300] fred status /src/trunk r1447

From the svn_activity.log I can deduce Apache catches and bounces the access, given that there is no foobar access at time-frame exposed previously.

So, hoping that the data i've collected is useful to solve this... any ideas?

P.S. It looks like this link but I've got more data. :)

Improve this question
6
  • What are the permissions on the directories discussed in the link you mentioned?
    – justarobert
    Apr 7, 2011 at 20:30
  • I do not understand your question..
    – apacay
    Apr 8, 2011 at 15:29
  • The only link I've mentioned, is the one from the P.S. but it was written by lumberg55, not me... and in Sep 09'.
    – apacay
    Apr 8, 2011 at 17:00
  • Wherever your repo is, it should have a db/transactions subdirectory. What are the permissions on the db/ and db/transactions/ directories?
    – justarobert
    Apr 8, 2011 at 17:34
  • The permissions authorization is given by a text file linked in httpd.conf, foobar has r-access to the repo and rw-access to the specific folders where he wants to commit, not by the db repo folder.
    – apacay
    Apr 8, 2011 at 17:52

1 Answer 1

Reset to default
1

The svn_activity log is higher level and typically not as good for debugging these problems as the lower level http methods, e.g. MKACTIVITY. 403 means forbidden, usually this is due to an authz access file but can also come from rules in the apache config. If you can attach the apache config for the problem repository and the authz file we can probably figure it out.

Look for a directive like this in your config files:

AuthzSVNAccessFile /data/authz
Improve this answer
2
  • The permissions aren't the problem. I've already checked... I know what 403 mean. But this is the permissions error I get when is actually a permissions issue: Commit failed (details follow): Server sent unexpected return value (403 Forbidden) in response to MKACTIVITY request for '/svn/reponame/your/path' And that is not what I'm getting. I mean it's a 403, ok... but not for Authorization issues...
    – apacay
    Apr 12, 2011 at 15:00
  • another common source of 403s is from apache Allow directives. Check for Order allow,deny or Allow from 127.0.0.1 etc
    – vinnyjames
    Apr 12, 2011 at 19:25

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

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