This is just a quick blog entry to hopefully help other people who end up in a similar situation as I did this morning. Specifically, Ive been contributing to a new project and when to commit my updates into subversion this morning only to receive this lovely error:
svn: Commit failed (details follow): svn: Commit failed (details follow): svn: MKACTIVITY of '/foobar/!svn/act/1f177b34-1601-0010-84ad-c180bd3a7ab5': 403 Forbidden (http://svn.foobar.com)
Now, despite this errors clarity and obviousness, it took my team about an hour and half to work out.
A check of the configuration files on our Subversion server confirmed that I was in a group which had read and write access and that others on this project were quite able to commit to the repository.
Also, I was able to commit to other repositories using the exact same permissions. I mean, literally, the groups and rights defined were the same.
I could checkout from the repository with no problems as well.
The log files were a mess of uselessness too.
A Googling of the problem turned up many cases where users had upgraded from earlier versions of Subversion to the latest, which, in fact, we recently did. However the repository in question was a new one and had never existed in previous installations. Nothing else we could find seemed to have any bearing on the problem.
To make sure it wasnt a bug in Subclipse I went to a different machine and checked out and tried to commit some changes to the same effect.
After quite a while we tried something that seemed to us to be a longshot. The casing in my svn url was not exactly the same as the repository name on disk. For example:
My URL: http://svn.foobar.com/foobar
The repository’s name however, was fooBar.
Clearly the repo name is not realy, fooBar. But, you get the picture. The case was different.
So, despite the fact that Subversion and Apache were running on windows it was suggested that I try changing the case and try again. I did, and to my surprise, it worked!
So, next time you have bizarre problems with Subversion, MKACTIVITY, and 403 Forbidden, double check your casing. Even on Windows.
Comments on: "Subversion, MKACTIVITY, and 403 forbidden Headaches" (130)
I’ve experienced a similar phenomenon, although it wasn’t quite as confusing because I couldn’t checkout either. So the troubleshooting led me to the URL casing sooner. My Subversion setup is also Apache on Windows, using virtual directories to define different groups of repositories. The URL case has to match the way I entered the virtual directory names in the config file, but the case after the virtual directory doesn’t have to match because Windows will allow it.
Interesting. Thx for sharing this problem.
LikeLike
Sweet ajax comment handling, btw…
LikeLike
Minor correction…virtual *hosts*, not directories. Duh.
LikeLike
why u deleted it? no funny u!!! where is my comment? u bad u.. u forbid me then delete me, why? shame on u.
LikeLike
haha, thanks a lot. you solved my headache s also
LikeLike
Same problem here…..only i don’t change case….ahhh on to another blog it is…
LikeLike
I had exactly the same problem. Your solution worked like a charm. Thanks a lot, saved my time.
LikeLike
Thanks! You saved the day!
LikeLike
I’m one of those upper/lower case disregarders spoiled by Windows.
I changed the case and – voil – it worked
Thomas
Germany
LikeLike
Saved the day for me too.
LikeLike
Thanks for posting this, found after many dead-ends through Google.
My case seemingly was URL-related as well, which was fixed by “relocating” the repository (using TortoiseSVN).
Things had been working perfectly fine until commits just started failing one morning – checkouts worked fine. Commits also worked fine for other developers in my team!
Commits started working again after changing the repository location from http://host:8080/svn/ProjName/trunk to http://Host.domain.org:8080/svn/ProjName/trunk – I used “Host.domain.org” exactly as specified case- and DNS-wise when installing VisualSVN Server.
Hope this helps someone…
LikeLike
Thanks for this solution ,I have been trying to find the same from google for 2 days.Your solution is just the perfect for this problem..
LikeLike
Thanks!!! Worked like a charm.
LikeLike
Thank you for posting this. This was driving me crazy!
LikeLike
Thanks!
LikeLike
Great!
I had the same problem, thanks for the post!
Thank you also, Vijayan, since I didn’t know the “relocate” of TortoiseSVN, it saved me a lot of time!
Cheers,
Cyril
LikeLike
hey, thanks a lot for this post, i was having the exact same problem and you really saved me a lot of trouble here!
and like Cyril said also, thanks Vijiayan for the tip on the ‘relocate’ command, i was about to do a fresh checkout, wich would have taken at least a couple of hours !
LikeLike
Thank you so much for this blog entry. I encounter the similar problem, and yes.. it’s caused by the wrong case as you described.
LikeLike
Hello all,
I’ve encountered the same problem. Changing the letter casing didn’t help. I’m not sure if this will help for sure, but I’ve solved te problem by relocating my project and downloading model via svn to directory with shorter browse path (for example C:model).
Try not to use long browse paths and just to be sure, aviod using diacritical points or spaces in directories names.
Hope this will work for you all.
LikeLike
This error is ridiculous. It makes no sense that you are able to checkout a project with the wrong case, but then are forced to use the right case to commit. I hope that CollabNet fixed this for version 1.5!
LikeLike
Thank you for posting this. This was driving me crazy! ))
LikeLike
for 403 Forbidden error i have a solution
Basically this is all about Permission deny to commit into Repository. This means you don;t have write permission.
Admin shoyld change his authorixation file to give your id rw perm. Auth file location can be found from httpd.conf file if appache is running in your system
directive in httpd.conf looks like
AuthzSVNAccessFile /path/to/authfile
be careful only admin can do it
LikeLike
>> Tony: “I hope that CollabNet fixed this for version 1.5!”
I’m running 1.5 and just received this error – so it’s not fixed yet…
LikeLike
Thanks a lot! It helps me. It shows me the way! 🙂 Casing is very important, especially at work with different operating systems.
Best regards,
Lark http://www.topnomer.ru
LikeLike
Thanks man this help me also!
LikeLike
I had the same problem with subversion only the case was off for my username. Subversion gives a completely different exception for invalid user/password, but gives the forbidden exception when the credientials are correct except for the case of the user.
LikeLike
Thanx a lot, I had the 403 forbidden and to add path to SVN authorization file in httpd.conf worked
LikeLike
Well, actually the clue in the error-message is the “HTTP” part, as
http://www.apache.org/dev/committers.html#commit-403
complains commits are only allowed on HTTPS links !!
svn: MKACTIVITY of ‘/foobar/!svn/act/1f177b34-1601-0010-84ad-c180bd3a7ab5’: 403 Forbidden (http://svn.foobar.com)
^^^^
Use the svn switch –relocate command to correct this like:
svn switch –relocate http://svn.apache.org/repos/asf/project/module https://svn.apache.org/repos/asf/project/module
Gr,
Jan
LikeLike
Here is how I fixed the “mkactivity 403 forbidden” error on Windows. We’re using domain authentication in our svn authz file. I was using domainuser in my svn “User Name” field in the Edit Connection window. I could browse the repository but couldn’t commit. When I got rid of the “domain” in the “User Name” field and just used my Windows user name, I could both browse the repository and commit. Oh, I’m on Win XP, TortoiseSVN 1.5.2, and Oracle JDeveloper 10.1.3.
LikeLike
Thanks so much. You helped me get to the root of our issue quickly and saved me from getting a similar headache. 🙂
LikeLike
Thanks for sharing this solution – I had the exact same problem.
LikeLike
note to self: When we go live with the subversion server, make sure everyone uses only lower case in their paths.
Also, I was having this problem with our test server and for the life of me I couldn’t figure it out since all my paths were in exactly the same casing.
In the end I stripped all the old gobbledy gook permissions from my permission file (vestigial permissions as it were) and it worked.
LikeLike
Oh and I also removed the reference to [/] but I don’t know if that was what did it.
nifty submission form BTW
LikeLike
We are using LDAP authentication and the “mkactivity 403 forbidden” occurs when users (Windowsuser :-() log in with mixed case usernames. LDAP seems not to check case, apache does.
LikeLike
Thanks a lot!!!!
LikeLike
thanks
LikeLike
Actually there are two reasons why this can happen. The first being what the blog entry says: differenc case in repository name in URL and on disk. Second being what one of the comments says: checking out with http: and trying to commit, where only https: works (because theres a redirect from http -> https) the latter bit us.
So if you see the case not being the problem, cross-check http/https.
LikeLike
You saved my week. I wa starting to lose my hope.
I had the same problem but the repository name on disk was the same as the URL dir in the server, the case was wrong on the URL used on the client to chechout.
I used TortoiseSVN from 1.5.0 to 1.5.3 on Windows XP 32 and Vista 64.
thanks a lot
Oscar.
LikeLike
Thanks a lot!!!! I’ve got exactly the same problem. Spent 2 desperate hours trying to solve it and finally find your article with solution.
Thanks once more!
LikeLike
Thanks for this! By the way, this was the number one search result in google for “mkactivity 403 forbidden”. 😉
LikeLike
I got same problem today…
Thanks!
LikeLike
Man! You are a life saver.
LikeLike
I had the same error, but my error was that i tried to do the commit with one user that only had read permisions. I add the write permisions and works fine.
LikeLike
You saved my Sunday!
LikeLike
Helal Olsun, (in Turkish it means you are great)
LikeLike
So it took me nearly a week to bang out my 403 Forbidden error. I had right casing and right slashes.
It ended up being that I needed to enable a few more modules that aren’t mentioned anywhere:
specifically, make sure the auth_basic and digest, dav_* modules and the ones that got me: proxy_*.
LikeLike
Thanks for this article
We had a similar problem with our repository.
The matter was effectively a problem on the url case
LikeLike
AS everyone here I had same problem. I’m also thinking in translate this to portuguese to help other people — with credits to you, of course 🙂
LikeLike
commenting to see sweet ajax moves
LikeLike
Thanks for this article. My casing problem was in the authz file.
LikeLike
The error did not leave me too….. Thanks a lot i saved my valuable time.
cheers….
Sunil Ganta
LikeLike
I’d lost few hairs because of this. thanks X2
LikeLike
Saved me a bunch of time. Thanks, man!
LikeLike
Many thanks!
this was getting us crazy, even because only the commit was not working, the update was ok.
LikeLike
Thanks for the blog. However, this did not work for me. Providing Read/Write permission to the Root Repository structure resolved this issue. Hope this helps
LikeLike
OMG! This helped… Why case-sensitive URI:s?… Oh well… The more you know.. 😀
LikeLike
thanks, saved me some time too!
LikeLike
dfsdfsdfsdf
LikeLike
Thanks!
LikeLike
Thanks a lot! If only i found this entry sooner… xD
LikeLike
Thanks! This has been driving us crazy for weeks…finally did some research and came across your page…fixed our problem…very helpful !
LikeLike
We’re using domain authentication
?Using “username” in svn “User Name” field => Fail
?change to “domainusername” in svn “User Name” field => Fail
?got rid of the “domain” in the “User Name” field => Success
I don’t know why??but it works ^^
LikeLike
THANK YOU! What a ridiculous error. What a horrible error message. The SVN boys should be ashamed of themselves.
LikeLike
Could also happen when the svn server is in read only mode. Seen with Google code hosting.
LikeLike
Solved my problem – many thanks!
LikeLike
Thanks a lot! All good noW! 😉
LikeLike
In my case, only the repository name itself was in wrong cases. relocating and done.
thanks a lot!
LikeLike
Great post, BTW the modifying the Authz file to change the casing works, BUT only for one version at a time. Rather have your clients relocate their working copies to the correctly cased URL.
LikeLike
Thank you very much!
I’ve done almoust everything before find your post.
LikeLike
Thank you thank you thank you!
LikeLike
In my case, there was a problem with case-sensitivity.
Our system: VisualSVN server on WS2003, TortoiseSVN clients (various versions)
All of a sudden, commit stopped working on random repositories. After careful inspection of repositories names we solved the problem.
We used TortoiseSVN command ‘relocate’ and changed repo name from ‘nsurname’ to ‘NSurname’ (as on server).
The reason is still unknown.
Thank you for the idea.
LikeLike
Thanku so much!! its just a great idea!
LikeLike
The case wasn’t the issue with mine. Same MKACTIVITY error though. I cleared the TortoiseSVN authentication cache and it started working again….
LikeLike
Thanks for posting! Saved us a bunch of time.
LikeLike
Thanks!
LikeLike
Merci!
LikeLike
Thanks a lot 🙂
LikeLike
Great!!! tried every thing before checking out this place…. Thanks a lot…. 🙂
LikeLike
This still didn’t work for me until I looked at the users/permissions of my subversion repository. I did NOT have read/write permission for the main user of the system… Me. Once I added myself with read/write permission (machinename/myUserName) I was able to successfully add a VS 2008 solution to the svn repository.
LikeLike
Thanks a lot. 🙂
LikeLike
Thank you very much indeed, this just worked fine, I tried a bunch of things but no one solved the problem. I own you one.
LikeLike
Thank you for saving the day. “http://svn.example.com:8080/…” hated me, but “http://svn:8080/…” let me commit. Who knew?
LikeLike
THANK YOU! This has happened to me a few times now and I never figured it out. You really saved me.
LikeLike
Just thank you
LikeLike
Awesome catch. This tip saved my butt today.
LikeLike
Hey fiends, In my case, I think that was a problem with ssl certificates.
Im able to checkout but no commit. Im resolve the problem committing passing the –username option and yeah all my local working copies use the new resoved ssl certificates.
LikeLike
HI guys,
i tried all the above mentioned suggestion but stil facing the same 403 forbidden problem?
can some body tell me wat should i do to get rid of this hell??
Thanks in advance….
LikeLike
Thank you very much! You saved me and my programmers team a lot of time!
Dennis
LikeLike
This can also happen if you are using http ldap auth, and a user places a space at the end of their name. Apache will auth the user, but subversion will not find it in the authz file. Thus you get this error instead of a more typical user not found error.
LikeLike
Thanks… Googling the exact error didn’t give much help.
Your post saved me bro…
Thanks.
LikeLike
Works like a charm. Thanks!
LikeLike
I bookmarked this already dude great work
Regards
LikeLike
Thanks, This saved my day.
LikeLike
thanks! 😀 just read your solution and it works! 😀
LikeLike
Thanks a lot…
it works.. i am having the similar problem and this saved me a lot of time.
THanks again
LikeLike
Thanks a lot…
LikeLike
Finally found the right answer. Thanks for the post.
LikeLike
Finally found the right answer too!!!
Thank you very much!!!!
LikeLike
One more grateful visitor. Thanks for sharing this very useful solution…
LikeLike
Thanks a lot for the solution. I thought i could never solve this.
LikeLike
Thanks! Still helping folks out with your post years later!!!
LikeLike
Thanks a lot!
LikeLike
+1
Thanks for tip !
LikeLike
It is amazing that … if it is considered a bug.. it did not get corrected even after 3 years. Thanks for a good explanation including all other futile efforts.
LikeLike
Heh. @#$% comments formatting! That was supposed to read:
…error trying to do:
svn cp first-url-here 2nd-url-here -F svn-commit.tmp
The casing is exactly…
LikeLike
wonderful post, I met the same problem and so luck to find your solution. Save me lot of time. Thanks.
LikeLike
Thanks a lot!
LikeLike
Amazing how this isnt more spread. Had this for two months and my it dept closed the ticket without a solution. Thanks!
LikeLike
Not only URLs are case-sensitive, the usernames are also case-sensitive!!!
It took me two days of try-and-errors, until I found your blog which lead me in the right direction.
Thanks a lot!
LikeLike
Great, thanks for your help!
LikeLike
Thanks worked for me too .
LikeLike
In case this helps anyone else out, wanted to drop a line. I was getting a forbidden error for a repository I know I’ve saved to successfully for years. The error was
svn: Commit failed (details follow):
svn: access to ‘https://foo.com/svn/beta/trunk/data’ forbidden
[I’ve replaced specifics with ‘foo’ to protect the innocent]
It wasn’t bad case or permissions or anything else I tried. What I eventually realized was that I had added another repository to the same machine and subversion didn’t know how to use the correct username for the repository. If I had repo alpha and beta and the usernames to access the repositories remotely via https were alpha_user and beta_user respectively, only the first authentication information was saved to my account on the new server. I’m sure there’s a more graceful solution, but the quick fix was to add beta_user to the svn-authz file that the server uses to authenticate to the repository. Hope this helps.
LikeLike
Thanks, saved my day.
SVN URLs are indeed case-sensitive when you want to commit changes!!!
LikeLike
Thank You!!!
LikeLike
Muchas gracias, fue de mucha ayuda.
LikeLike
Thanks a lot! Worked perfectly for me too!
LikeLike
Had been hunting for several days for this solution till i chanced upon your blog. Problem solved in a jiffy. Thanks a lot.
LikeLike
i appreciate your information. thanks a lot~^^
LikeLike
Thanks man, I thought something really was wrong there for a moment. Used the scary “relocate” command over here. One might think that it would be easier to remove the case sensitivity one commits though. plz tell if you know how
best regards tompa
LikeLike
Thank you. This helped me out after updating to FB 4.5.
LikeLike
Thank very much. I use the ubuntu, and rapidsvn. I counter the same problem and try to change permission and could not work out until I saw your blog wrote in four years before.
LikeLike
This worked for me as well – after relocating, the casing of the path changed… Thanks for posting this – even if it was four years ago!
LikeLike
Great..Fixed. Thanks a lot
LikeLike
Thank you, it really helped !!
LikeLike
Really this is great fix. I solved my problem in 10 minutes just getting this fix.
Thanks buddy for your post.
LikeLike
Many thanks for this tip!
This problem caused me days of headaches…
LikeLike
Thanks. I don’t know how I would have solved this problem without your post.
LikeLike
Only to add: this also happened to me, but not because wrong casing in URL, but in user id. Lowercase user failed at commit (although checkout worked); uppercase user was needed. Thanks
LikeLike
Thanks buddy .. Saved a lot of time .. deepest gratitude ..
LikeLike
Thank you! This saved me a lot of headache.
LikeLike