Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

Ok, first of all, I've already googled a lot about this problem, but didn't found any solution... I've searched here and on ServerFault, but didn't found anything, so I end up posting this question here (don't really sure if it goes here or in ServerFault, sorry).

So here's the deal: We have a Windows 2003 Server running without problems. We have been using Visual SVN Server as our Subversion server and it worked great until now. We take some vacations for a couple of weeks so we didn't use the SVN at all. Today, when I tried to commit something I got:

Server sent unexpected return value (403 Forbidden) in response to OPTIONS request for [repository url]

We use TortoiseSVN as our svn client, but the problem seems to be on the server. We tried creating a new repository and import new files, same error. We tried accessing the SVN server from the server itself through RDC and trying to checkout something by console (svn checkout) and others commands too.... everything leads to that error.

Some people said it was a case-sensitive problem on the URL... but that's not our case... I've double-checked the URLs and they are fine... (anyway they were stored on the Tortoise history, so that didn't change).

One particular point to say is that there are people out there having the same problem that are not using Visual SVN (which is really just a easy way to set up a Subversion server in 2 clicks, it's not something different from any Subversion server). So I don't know if the problem is actually the Visual SVN itself.

We're lost... Any helpful information will be really appreciated.

EDIT/SOLUTION: I had a wrong entry on the authz file. It was trying to give permission to a deleted group (I think VisualSVN didn't delete the entry on authz but it did delete the group), so I deleted the entry and it's working now.

Thank you

share|improve this question

migrated from stackoverflow.com Nov 3 '09 at 2:43

This question came from our site for professional and enthusiast programmers.

2  
Since it is Apache-based, did you see anything helpful in the logs? I believe logs are (also or only) available by looking at the Windows Event Log window. How is your SVN authentication configured? And (it's a long shot), is it possible to use the Apache server to access something else than just SVN (a intranet?) - just to try and isolate which fails first. –  RedGlyph Nov 2 '09 at 20:45
    
Mmm I see this error from today several times. Failed to load the AuthzSVNAccessFile: An authz rule refers to group '@Algo2', which is undefined [client <ip>] Algo2 was a group we had, but we deleted a few months ago I think. Maybe that has broken the AuthzSVNAccessFile??? Any ideas? –  emzero Nov 2 '09 at 21:05
    
How is my SVN authentication configured? I don't really know =P We' always used VisualSVN which creates its own groups/users... don't really know the underlying stuff going on there. Can you give me a way to know how it's configured? –  emzero Nov 2 '09 at 21:06
    
Sorry I didn't see your questions earlier, but you found out anyway, congrats! It's weird the problem only appeared now, out of the blue. To answer your question "post-mortem", you can see the type of the configuration by looking at the properties of the root element on the VisualSVN server management window. It's either Windows or built-in SVN authentication. The problem was a little further away though, in the access file itself. –  RedGlyph Nov 3 '09 at 0:31

4 Answers 4

up vote 4 down vote accepted

I have a wrong entry on the authz file (it was trying to give permission to a deleted group), so I deleted the entry and it's working now

share|improve this answer
    
I had a 403 error, but no errors about loading the authz_windows file. However, my authz_windows file DID have an explicit entry for a directory that no longer existed. My long-term fix was to remove all unique permissions and to inherit all permission from the root. –  GregB Aug 5 '11 at 20:45

I had this a recently as well, and a recent Anti-virus update had killed it. Check the following

  • Anti-virus
  • Windows firewall, if you have automatic updates on the server turned on (which I don't recommend) some updates will change your firewall settings
  • Make sure you try navigating with a normal browser. If the repository is up you should be able to reach it by navigating to https://machine%3Aport/svn/
  • Make sure noone installed anything with a port conflict while you were gone.
share|improve this answer
    
Really? Updating your antivirus solved the problem? Gees... this seems like a problem with random solutions. –  emzero Nov 2 '09 at 20:16
    
Actually, I had to uninstall my anti-virus... –  Russell Steen Nov 2 '09 at 20:17
    
Oh, I misunderstood you. Well... we don't use any anti-virus for our dev server. Windows firewall is off. Automatic updates was set to automatically (I've set now to ask me first, but of course it won't fix the problem). I've tried shutting down other services that may cause port conflicts, also I changed the port of the SVN and change https to http. None of this have worked... –  emzero Nov 2 '09 at 20:22
    
And yes, I've tried navigating the repository via several ways. Tortoise, command prompt, firefox/chrome... nothing.. same error. –  emzero Nov 2 '09 at 20:36

Have you checked that the authentication/authorization database has not changed or become inaccessible?

If you authenticate against Active Directory (via LDAP) has there been a change there?

share|improve this answer
    
Mmm, I don't think authentication/authorization database has changed. We use VisualSVN authentication, don't know what LDAP is... –  emzero Nov 2 '09 at 20:58
    
Lightweight Directory Access Protocol. It's a protocol that lets users authenticate with their domain usernames instead of an svn specific username. –  GregB Aug 5 '11 at 20:47

We are using VisualSVN with Windows authentication and one of our users was getting this error. The AD group we were using for the permissions in VisualSVN was a distribution group, it looks like SVN doesn't like these anymore. Once we changed to a security group it works fine.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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