Skip to main content
Software Engineering

You are not logged in. Your edit will be placed in a queue until it is peer reviewed.

We welcome edits that make the post easier to understand and more valuable for readers. Because community members review edits, please try to make the post substantially better than how you found it, for example, by fixing grammar or adding additional resources and hyperlinks.

Required fields*

SVN command line client: checkout refused when LDAP password changed "svn: OPTIONS of" (repo) "authorization failed" (but works in TortoiseSVN)

When using the command line/terminal svn client, a colleague is getting "svn: OPTIONS of " [repo] "...authorization failed" error message when they attempt to checkout the repo to be their local working copy.

They used to be able to do this but have recently had to change their password (periodic routine security policy). And it stopped working. NOTE: The svn check command does ask for a password everytime (which they supply - i.e. their new one.)

BUT strangely they have no problem with Tortoise SVN, it works on that. They supply their usual login and new password and it works.

Our setup is a virtualised CentOS Linux machine with several Linux user accounts where development takes place and the SVN central repo is on a separate server, authentication is using our LDAP login (i.e. the same corporate login used to login to our Windows machines). We login as Linux users to our development server from our Windows machines, using standard terminal SSH tools, e.g. PuTTY or MobaXTerm or CygWin.

When I change my password I don't get the same problem, I am able to checkout.

I have seen many questions about this error message from searching various forums on google but none have provided me with a solution as yet.

One of the solutions I found suggests to clear or remove a local cache containing authentication, in a .subversion folder, we tried this but still the same problem. Also tried checking out to another folder.

So it seems we have clean out any trace of cached passwords but yet it still rejects.

Could there be another place on our CentOS Linux machine that caches the login What is meant by OPTIONS (could it be a setting somewhere on our development machine or on the SVN repo server?) Could it be a HTTP Proxy cache of my colleague's credentials stored somewhere - so we need to clear that when a password is changed?

(Mistakenly posted on superuser.com (which is about users), so closed it there and moved it here)

Answer*

Draft saved
Draft discarded
Cancel
3
  • The root cause is most likely a character set issue. To explain, our SVN setup uses LDAP authentication meaning that the login/password we use for SVN is the same as what we use for our corporate Windows PC network account login, which popular convenient arrangement only needing one account for both. However, we usually set/update our password via the usual Windows password change (CTRL-ALT-DEL) and we believe that the ISO character set in Windows is different from that used for the SVN CLI in Linux. Commented Aug 7, 2012 at 14:56
  • Our password wouldn't work because it contained a pound symbol which can be interpreted differently under a different character set or key mapping in Windows LDAP password changing compared to Linux LPAP SVN authentication due to mismatch in character set used. Commented Aug 7, 2012 at 14:57
  • +1 Thanks @Matt S I think this is the right place to be looking. Update: With the great help of WanDisco (don't work for them but use their services) we believe it is an issue with key-mappings being different in Windows and Linux. Symbols such as the pound symbol can get interpreted differently. I have moved the accepted answer (sorry) to this new answer but your upvote still remains as you address the general problem area. I have upvoted some answers you gave on other subjects as consolation that I liked. Hope this is OK. Commented Aug 7, 2012 at 15:01

AltStyle によって変換されたページ (->オリジナル) /