1

Several users of an SVN repository I have working are unable to connect to the repository with the following messages:

Unable to connect to repository at URL: <url>
Could Not Open Requested File System

The primary complication here is that several user are able to open the repository, and I've verified that the URL they are using is correct, as are their authentication credientials. Specifically things that have been tried:

  • Administrative account can check out repository on certain machines (but not others)
  • General user accounts can check out repository on certain machines (but not others)
  • URL of repository has been verified through access with a web browser on all machines in question.
  • The authentication credentials of all users in question have been confirmed correct.

I'm really at a loss here since these seem to rule out both the server configuration and user errors in so far as most documentation and questions I've read cover. Any ideas on what the problem might be, and how to resolve it?

Lazy Badger
  • 94,711
  • 9
  • 78
  • 110
Vilid
  • 331
  • 1
  • 2
  • 4
  • It's probably also worth noting that the configuration of each of the machines this was tested on was essentially the same except for the computer names, MAC addresses, and IP addresses. (with Win 7 Enterprise 32 bit as OS) – Vilid Nov 27 '12 at 00:46
  • Please, when error on checkout happens again, try to repeat in console `svn co URL` and paste full output here. Also snippet from error-log will be useful, and, maybe, svn `` from httpd.conf – Lazy Badger Nov 27 '12 at 01:35
  • Additional reading http://superuser.com/questions/274183/how-to-overcome-svn-could-not-open-the-requested-svn-file-system – Lazy Badger Nov 27 '12 at 01:36
  • The solution presented is currently how these repositories are configured. – Vilid Nov 27 '12 at 01:47

1 Answers1

0

"Could Not Open Requested File System" is (may be) bad sign for repository.

  • Did you tried to verify repository in question, clone repo into another location on the same host?
  • Which type of repo you have (FSFS, BDB), which protocol for access?
  • Can you connect to repo from user-in-question with ordinary browser?
  • If you repository is http-based, did your read Apache logs?
Lazy Badger
  • 94,711
  • 9
  • 78
  • 110
  • The first option wasn't done, and won't be possible under the current configuration (as it's mission critical at the moment). I thought I had mentioned it but in case I didn't, yes the users can all connect via browser. Some other potentially relevant info: the repository is accessed through Subversion, and is FSFS. – Vilid Nov 27 '12 at 00:59
  • @Vilid - you can (**must**, really) create on-the-fly backup of repo with [hotcopy](http://svnbook.red-bean.com/en/1.7/svn.ref.svnadmin.c.hotcopy.html) and test it – Lazy Badger Nov 27 '12 at 01:03
  • @Vilid - mirror with svnsync isn't terrible idea also – Lazy Badger Nov 27 '12 at 01:05
  • @Vilid - " accessed through Subversion" means svn:// protocol or just "we tried only svn-clients"? – Lazy Badger Nov 27 '12 at 01:08
  • neither of those appear to be possible as neither my admin or root account on the server has the authorization to execute those commands on a repository. (I didn't set it up and the one who did isn't here anymore so it's a difficult issue). It should also be noted that for about half of the users the repository is both accessible and functioning completely correctly at the moment. – Vilid Nov 27 '12 at 01:12
  • "Accessed through Subversion" means that's the system used to host it, we've accessed it only through https at the moment, and it comes up with authentication and a page when accessed via a browser, and on many users also connects via TortiseSVN, just a few machines are experiencing this issue (it's not even a user to user error as the same users have success and failure on different locations). – Vilid Nov 27 '12 at 01:16
  • Could it be an intermittent error (had that before when the AD server was playing up and sending incorrect details), or more simply, could the cached credentials in tortoisesvn be incorrect? – Mightymuke Nov 27 '12 at 01:19
  • I don't think its the cache as even machines which have newly configured installations of SVN have had the error. As for an intermittent error it's possible but will be hard to check. – Vilid Nov 27 '12 at 01:23
  • @Mightymuke - cached credentials in tortoisesvn doesn't play here at all – Lazy Badger Nov 27 '12 at 01:32
  • @Lazy - curious to know why not? Connectivity via a browser has been confirmed, but connectivity via tortoisesvn doesn't work. Repo is ok as its checked out onto other machines. – Mightymuke Nov 27 '12 at 01:50
  • Thus far I haven't been able to read them, as I alluded to before the read permissions on this particular server are problematic, specifically root doesn't seem to have the permissions to do so, and the server was set up with some legacy accounts, so the ownership of certain things isn't quite configured. Permissions would have been the first thing I'd check if there was a forbidden error occurring anywhere, but aside from those few machines everything accessed through this system is running right so I really doubt that's the critical issue, though I have been working or sorting it a long time – Vilid Nov 27 '12 at 02:21
  • Yep - saw that. Was hoping that you at least had access to view the logs as that's probably going to be your best option to determine the cause of the issue. – Mightymuke Nov 27 '12 at 02:37