The amazing adventures of Doug Hughes

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)

  1. Joshua Curtiss said:

    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.

    Like

  2. Joshua Curtiss said:

    Sweet ajax comment handling, btw…

    Like

  3. Joshua Curtiss said:

    Minor correction…virtual *hosts*, not directories. Duh.

    Like

  4. why u deleted it? no funny u!!! where is my comment? u bad u.. u forbid me then delete me, why? shame on u.

    Like

  5. haha, thanks a lot. you solved my headache s also

    Like

  6. Same problem here…..only i don’t change case….ahhh on to another blog it is…

    Like

  7. I had exactly the same problem. Your solution worked like a charm. Thanks a lot, saved my time.

    Like

  8. Thanks! You saved the day!

    Like

  9. I’m one of those upper/lower case disregarders spoiled by Windows.
    I changed the case and – voil – it worked

    Thomas
    Germany

    Like

  10. Saved the day for me too.

    Like

  11. 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…

    Like

  12. Saurabh Mehrotra said:

    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..

    Like

  13. Harold Solbrig said:

    Thanks!!! Worked like a charm.

    Like

  14. Thank you for posting this. This was driving me crazy!

    Like

  15. Zohar Babin said:

    Thanks!

    Like

  16. Cyril Gambis said:

    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

    Like

  17. 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 !

    Like

  18. 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.

    Like

  19. 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.

    Like

  20. 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!

    Like

  21. Thank you for posting this. This was driving me crazy! ))

    Like

  22. 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

    Like

  23. Mikkel Bo Mikkelsen said:

    >> 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…

    Like

  24. 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

    Like

  25. Thanks man this help me also!

    Like

  26. Keith Morgan said:

    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.

    Like

  27. Thanx a lot, I had the 403 forbidden and to add path to SVN authorization file in httpd.conf worked

    Like

  28. Jan Wilmans said:

    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

    Like

  29. 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.

    Like

  30. Thanks so much. You helped me get to the root of our issue quickly and saved me from getting a similar headache. πŸ™‚

    Like

  31. Thanks for sharing this solution – I had the exact same problem.

    Like

  32. 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.

    Like

  33. Oh and I also removed the reference to [/] but I don’t know if that was what did it.

    nifty submission form BTW

    Like

  34. 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.

    Like

  35. Thanks a lot!!!!

    Like

  36. thanks

    Like

  37. 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.

    Like

  38. 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.

    Like

  39. 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!

    Like

  40. Thanks for this! By the way, this was the number one search result in google for “mkactivity 403 forbidden”. πŸ˜‰

    Like

  41. I got same problem today…

    Thanks!

    Like

  42. Man! You are a life saver.

    Like

  43. 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.

    Like

  44. You saved my Sunday!

    Like

  45. Helal Olsun, (in Turkish it means you are great)

    Like

  46. Isaac Johnson said:

    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_*.

    Like

  47. Thanks for this article
    We had a similar problem with our repository.
    The matter was effectively a problem on the url case

    Like

  48. Luiz Eduardo said:

    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 πŸ™‚

    Like

  49. commenting to see sweet ajax moves

    Like

  50. Thanks for this article. My casing problem was in the authz file.

    Like

  51. The error did not leave me too….. Thanks a lot i saved my valuable time.

    cheers….
    Sunil Ganta

    Like

  52. chaoskaizer said:

    I’d lost few hairs because of this. thanks X2

    Like

  53. GuyBehindtheGuy said:

    Saved me a bunch of time. Thanks, man!

    Like

  54. Many thanks!
    this was getting us crazy, even because only the commit was not working, the update was ok.

    Like

  55. Natarajan said:

    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

    Like

  56. OMG! This helped… Why case-sensitive URI:s?… Oh well… The more you know.. πŸ˜€

    Like

  57. thanks, saved me some time too!

    Like

  58. dfsdfsdfsdf

    Like

  59. Alex van der Linden said:

    Thanks!

    Like

  60. Mediati Avriesa said:

    Thanks a lot! If only i found this entry sooner… xD

    Like

  61. Thanks! This has been driving us crazy for weeks…finally did some research and came across your page…fixed our problem…very helpful !

    Like

  62. 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 ^^

    Like

  63. THANK YOU! What a ridiculous error. What a horrible error message. The SVN boys should be ashamed of themselves.

    Like

  64. MickTaiwan said:

    Could also happen when the svn server is in read only mode. Seen with Google code hosting.

    Like

  65. Alex Hoffman said:

    Solved my problem – many thanks!

    Like

  66. Thanks a lot! All good noW! πŸ˜‰

    Like

  67. Jens Peter said:

    In my case, only the repository name itself was in wrong cases. relocating and done.

    thanks a lot!

    Like

  68. 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.

    Like

  69. Thank you very much!

    I’ve done almoust everything before find your post.

    Like

  70. Thank you thank you thank you!

    Like

  71. 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.

    Like

  72. Thanku so much!! its just a great idea!

    Like

  73. The case wasn’t the issue with mine. Same MKACTIVITY error though. I cleared the TortoiseSVN authentication cache and it started working again….

    Like

  74. Markus Wallgren said:

    Thanks for posting! Saved us a bunch of time.

    Like

  75. Carlos Peix said:

    Thanks!

    Like

  76. Merci!

    Like

  77. Thanks a lot πŸ™‚

    Like

  78. Great!!! tried every thing before checking out this place…. Thanks a lot…. πŸ™‚

    Like

  79. 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.

    Like

  80. valliappan said:

    Thanks a lot. πŸ™‚

    Like

  81. 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.

    Like

  82. Thank you for saving the day. “http://svn.example.com:8080/…” hated me, but “http://svn:8080/…” let me commit. Who knew?

    Like

  83. THANK YOU! This has happened to me a few times now and I never figured it out. You really saved me.

    Like

  84. Just thank you

    Like

  85. Awesome catch. This tip saved my butt today.

    Like

  86. Roberto Carlos said:

    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.

    Like

  87. 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….

    Like

  88. Thank you very much! You saved me and my programmers team a lot of time!

    Dennis

    Like

  89. Mike Miller said:

    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.

    Like

  90. Thanks… Googling the exact error didn’t give much help.
    Your post saved me bro…
    Thanks.

    Like

  91. Works like a charm. Thanks!

    Like

  92. I bookmarked this already dude great work

    Regards

    Like

  93. Thanks, This saved my day.

    Like

  94. thanks! πŸ˜€ just read your solution and it works! πŸ˜€

    Like

  95. Thanks a lot…
    it works.. i am having the similar problem and this saved me a lot of time.
    THanks again

    Like

  96. Fahime Alizade said:

    Thanks a lot…

    Like

  97. Finally found the right answer. Thanks for the post.

    Like

  98. Finally found the right answer too!!!

    Thank you very much!!!!

    Like

  99. One more grateful visitor. Thanks for sharing this very useful solution…

    Like

  100. Swapnil - CitiusTech said:

    Thanks a lot for the solution. I thought i could never solve this.

    Like

  101. Thanks! Still helping folks out with your post years later!!!

    Like

  102. Inearthed said:

    Thanks a lot!

    Like

  103. +1
    Thanks for tip !

    Like

  104. CuriousTom said:

    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.

    Like

  105. 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…

    Like

  106. wonderful post, I met the same problem and so luck to find your solution. Save me lot of time. Thanks.

    Like

  107. Thanks a lot!

    Like

  108. Mr Apricot said:

    Amazing how this isnt more spread. Had this for two months and my it dept closed the ticket without a solution. Thanks!

    Like

  109. 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!

    Like

  110. Great, thanks for your help!

    Like

  111. Thanks worked for me too .

    Like

  112. 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.

    Like

  113. Thanks, saved my day.
    SVN URLs are indeed case-sensitive when you want to commit changes!!!

    Like

  114. Thank You!!!

    Like

  115. Muchas gracias, fue de mucha ayuda.

    Like

  116. Francis Claessens said:

    Thanks a lot! Worked perfectly for me too!

    Like

  117. Had been hunting for several days for this solution till i chanced upon your blog. Problem solved in a jiffy. Thanks a lot.

    Like

  118. i appreciate your information. thanks a lot~^^

    Like

  119. 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

    Like

  120. Thank you. This helped me out after updating to FB 4.5.

    Like

  121. 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.

    Like

  122. 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!

    Like

  123. Great..Fixed. Thanks a lot

    Like

  124. Thank you, it really helped !!

    Like

  125. Really this is great fix. I solved my problem in 10 minutes just getting this fix.
    Thanks buddy for your post.

    Like

  126. Many thanks for this tip!
    This problem caused me days of headaches…

    Like

  127. Thanks. I don’t know how I would have solved this problem without your post.

    Like

  128. Javier Cmara said:

    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

    Like

  129. Harris Thomas said:

    Thanks buddy .. Saved a lot of time .. deepest gratitude ..

    Like

  130. Elias Hedberg said:

    Thank you! This saved me a lot of headache.

    Like

Comments are closed.

Tag Cloud

%d bloggers like this: