Can't make SVN store passwords, even though the configuration is set to allow it

I did everything the book says, i.e. removed the authentication files from .subversion/auth, and explicitly set the relevant configuration parameters to ‘yes’ even though this is a default, and yet the shell SVN commands ask for a password each time. The repository is on, and the client is Linux. I also use the Subclipse plugin that caches the password OK.

I vaguely remember that when I started working with it, the command asked interactively if I wanted to save clear password, and I said no. Can this choice be stored somewhere and take precedence over the configuration?

  • Permissions and SVN Updates on Windows Server 2008: same folder & SVN account, different Active Directory users
  • svndumpfilter fails with “Invalid copy source path…” error
  • Creating a Crucible review for a whole project
  • Using git svn on a repo created with svn2git
  • Per-directory permissions on git
  • SVN project structure
  • How can I dump all svn data while I lost some revisions in the repository?
  • “RA layer request failed” error with Subclipse, no errors with web browser
  • Fast Windows PHP editor with SVN and FTP support?
  • Does Git-Svn Store Svn Passwords?
  • git-svn and a remote git repo sync
  • How do I 'svn add' all unversioned files to SVN?
  • 16 Solutions collect form web for “Can't make SVN store passwords, even though the configuration is set to allow it”

    With recent versions of Subversion (~ 1.8) you can configure password caching via $HOME/.subversion/servers:

    store-passwords = yes
    store-plaintext-passwords = yes

    But depending on your system this may be not enough. If it is not, make sure that $HOME/.subversion/config contains:

    password-stores =

    Which means that the variable password-stores is explicitly set to the empty string (background is that svn now contains support for some key-agent tools – and the interfacing to the default configured ones may be fragile – resulting in silent ignoring of the above options and non-caching behaviour).

    When using svn for the first time, the hierachy $HOME/.subversion is created after the first svn operation – e.g. when doing the first checkout. Subversion creates then the mentioned files and fills them with the most important options – commented out, including some documentation.

    Thus, it also makes sense to move an old $HOME/.subversion directory away to have a well-defined starting point.

    Another pitfall are permissions – i.e. files which are not readable under $HOME/.subversion – but this should not often be the problem, because when svn creates them, it takes care of the right permissions (e.g. the auth directory is only readable by the user then, not by the group/all, independent of the configured umask).

    I would like to submit a detailed answer in case it helps someone in future.

    Subversion 1.6 and later will cache your username and password by default however it will not cache the passwords in plaintext unless you explicitly allow it via the command line or by changing the Subversion configuration.

    If you checked out a working copy using the –username and –password options you will see the following message:

    ATTENTION! Your password for authentication realm:
    <> Assembla Restricted Area
    can only be stored to disk unencrypted! You are advised to configure
    your system so that Subversion can store passwords encrypted, if
    possible. See the documentation for details.
    You can avoid future appearances of this warning by setting the value
    of the 'store-plaintext-passwords' option to either 'yes' or 'no' in
    Store password unencrypted (yes/no)? 

    So as mentioned in the message, subversion will only save the password unencrypted if you enter ‘yes’. If you do so then you should not need to add the –username or –password options when performing svn commands in future.

    However, if you prefer not to see this prompt at all you can change the global configuration for your Subversion client by changing the configuration file called “server” on your local machine. It is stored here:


    You will need to add the following lines to the “server” file:

    store-plaintext-passwords = yes

    With this change, you only need to perform an svn command using the –username and –password options once. Then Subversion will automatically save your credentials without the above prompt.

    For more information on disabling this warning about caching passwords in plain text see the Subversion 1.6 Security Improvements blog post.

    I ran into this same issue, and believe I set all the appropriate configs in .subversion/servers and .subversion/config, too, tried removing .subversion/auth, etc., but to no avail.

    I ended up saving the credentials by moving the .subversion directory (or removing it would work too) and running svn co. I got the following message:

    ATTENTION!  Your password for authentication realm:
       <http://sweeney:80> Subversion repository
    can only be stored to disk unencrypted!  You are advised to configure
    your system so that Subversion can store passwords encrypted, if
    possible.  See the documentation for details.
    You can avoid future appearances of this warning by setting the value
    of the 'store-plaintext-passwords' option to either 'yes' or 'no' in
    Store password unencrypted (yes/no)? 

    I typed yes, and then got the same message. Stubbornly, I typed yes again. Now my password seems to be saved.

    Somewhat surprisingly, looking at the configs in .subversion, none of the settings are uncommented; they’re all set to the defaults, so I imagine I would have to answer this warning twice to save a password for a different server in the future.

    Hope this helps.

    Thanks to your comments I found the problem – it’s the settings in the servers file (don’t store plain passwords). I wonder why there is this redundancy with the [auth] section of the configuration file. The SVN book also does not mention this when talking about storing passwords.

    I needed to make to changes to the server file to make this work for me

    # Password / passphrase caching parameters:
    store-passwords = yes
    store-plaintext-passwords = yes

    Delete old stored password like rm ~/.subversion/auth/svn.simple/*. I have tried every other suggestion and this is what worked for me.

    You may use the gnome-keyring even without X inited.
    You should run

    export `gnome-keyring-daemon`

    on login and


    before logout.

    Then you can use keyring_tool commandline utility.

    On Windows with slikSVN, I was having the same issue, but only with one of the projects, so I went in %AppData%\Roaming\Subversion\auth\svn.simple and deleted the file containing that project information.

    The next SVN command I typed asked for the password and created the file again and now it’s running great.

    Maybe the fact I changed configuration and servers files helped too, but it was not working till I deleted that file (and it was working also with the previous configuration till there was a password issue on the server and the administrator reset permissions).

    I think I’ve found a helpful hint here:

    As I understood, the client forgot to check if a “gpg-agent” is currently running.

    It is inserting the “passtype” = “gpg-agent” into the ~/.subversion/auth/svn.simple/-cache-files by default.

    That is a mistake!

    As a solution (and to avoid to alter the password-cachefiles in ~./subversion/auth/svn.simple/ by hand) remove these file (but make a save-copy).

    Add the line, into ~/.subversion/config ([auth]-section):


    (CONSIDER: the empty value! This prevents the client from choosing any wrong stuff and assume “simple”.)

    Now e.g. try a:

    svn up

    Subversion will now warn you to save plain passwords.

    If you got no problem with that, type “yes” and all is fine again.

    After that, Subversion has created a cache-file for a particular server, and you can remove the “password-stores”-entry again.

    If you are trying to reset the authentication on an existing working copy, I’d recommend you checkout a fresh copy after you do all of the above changes. This was the only thing that worked for me when I was trying to release the project with the maven-release-plugin (which uses stored svn credentials in order to auto commit your tags, etc…)

    Please be aware that there is a difference behaviour related to the password storing between a svn co/up and a svn log!

    I tried all of the hints above and alway tried to verify with ‘svn log’ — the svn command always asked me again and again for password, no matter if store-plaintext-passwords was set correctly to ask or yes. But when I made a new checkout or update I suddenly had the correct behaviour and my password got save

    I assume this is a bug to subversion to have different handling of password storing for the different commands — at least I read no where about that before.

    For some odd reason, my .subversion folder was not owned by me and SVN wouldn’t save certificates of passwords.

    I just did a sudo chown -R me ~/.subversion and now everything works!

    I experienced such problems after a password change and cured it deleting the SVN configuration (and thus recreating it from scratch).

    Delete files from the below directory:

    For Windows:

    For example:


    Note: Delete all files. These files contain meta data about the checkout. The next time when you store your password it will automatically create a file here.

    Delete the .keyring file from your STS/Eclipse installation. Stop Eclipse and delete the file.

    For example:


    A solution that worked for me (even isnt’ the better solution, at least bailed me out), it’s to grant my local user all permissions to ~/.subversion directory and subdirectorys. Then i could do operations on subversion fast without prompt username and password.

    From what I read in the previous answers, none of these worked. What I found to work for me could be a combination of things or this final step which is to open the keychain app, find the key in question.

    Right-click and go to “get info”. Click access control section on the top. Then click the “Allow all applications to access this item”. Although this might do something unintended.

    Git Baby is a git and github fan, let's start git clone.