5

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

empz
  • 247
  • 1
  • 6
  • 15
  • 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. –  Nov 02 '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 ] Algo2 was a group we had, but we deleted a few months ago I think. Maybe that has broken the AuthzSVNAccessFile??? Any ideas? – empz Nov 02 '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? – empz Nov 02 '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. –  Nov 03 '09 at 00:31

4 Answers4

4

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

empz
  • 247
  • 1
  • 6
  • 15
  • 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 05 '11 at 20:45
0

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.

0

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:port/svn/
  • Make sure noone installed anything with a port conflict while you were gone.
Russell Steen
  • 101
  • 3
  • Really? Updating your antivirus solved the problem? Gees... this seems like a problem with random solutions. – empz Nov 02 '09 at 20:16
  • Actually, I had to uninstall my anti-virus... –  Nov 02 '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... – empz Nov 02 '09 at 20:22
  • And yes, I've tried navigating the repository via several ways. Tortoise, command prompt, firefox/chrome... nothing.. same error. – empz Nov 02 '09 at 20:36
0

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?

Ex Umbris
  • 804
  • 7
  • 24
  • Mmm, I don't think authentication/authorization database has changed. We use VisualSVN authentication, don't know what LDAP is... – empz Nov 02 '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 05 '11 at 20:47