docker always restores credStore desktop

[stefanloerwald]

I don't want to use the default credStore "desktop" on my development machine. The issue https://github.com/docker/docker-credential-helpers/issues/95 guides me to set the credStore/credsStore value to "" instead of "desktop", but it doesn't seem to have any effect while docker is running. Restarting docker will reset this value to "desktop".

Please fix this.

[docker-robott]

Issues go stale after 90 days of inactivity. Mark the issue as fresh with /remove-lifecycle stale comment. Stale issues will be closed after an additional 30 days of inactivity.

Prevent issues from auto-closing with an /lifecycle frozen comment.

If this issue is safe to close now please do so.

Send feedback to Docker Community Slack channels #docker-for-mac or #docker-for-windows. /lifecycle stale

[stefanloerwald]

/remove-lifecycle stale This is still very much a thing, as far as I know. It would be great if the maintainers of docker didn't simply solve issues by ignoring them for long enough...

[gostega]

Would be nice to be able to use the windows credential store similar to how git does it: git config --global credential.helper "/mnt/c/Program\ Files/Git/mingw64/libexec/git-core/git-credential-manager.exe"

[gostega]

/remove-lifecycle stale

[TalonLaurens]

Facing the exact same issue on Windows 10 (WSL2). I can not use private hosted containers because of this issue...

[0x53A]

The windows credentials store does not work for us, because our build script runs elevated: https://github.com/docker/cli/issues/2682#issuecomment-675135899

It turns out you cannot Docker login via an elevated shell depending on your environment as it appears the credentials don't get passed through

It works when I manually remove the credStore from my config.json file, but on the next docker restart docker will replace it with desktop again.

Please either fix the bug that elevated shells can't login, or that credStore gets reset. Either would be fine, preferably both ...

[ronbuchanan]

Having the same issue. Resets the credStore to desktop every time a restart happens.

[gostega]

This no longer happens to me (I work on multiple windows PCs with WSL 2, and change computers often (reformat windows or get new PC so have to set up everything from scratch again) If it helps anyone, here is the content of my docker config.json in WSL

$ cat ~/.docker/config.json 
{
        "auths": {
                "gitlab.redacted.com": {},
                "gitlab.redacted.com:4567": {}
        },
        "credsStore": "desktop.exe"
}

I recommend anyone having issues to completely uninstall docker, (or try use the purge option in docker first) and/or remove WSL then reinstall WSL, and make sure you enable WSL2, then reinstall docker, and enable docker integration with WSL (inside the Docker desktop settings). After doing the above, docker in WSL uses Windows credential manager and works fine.

[ErnstHaagsman]

I just faced this issue, and found a workaround:

First edit config.json, then go to its file permissions, and deny 'Write' to all users. Then when restarting the Docker engine it actually seems to use what's in the file.

[adrianlyons]

I tried a similar write protect approach however docker crashed on start...

[sliekens]

Why don't you want to use the credentials store? Renaming or removing "credStore" makes it significantly easier to steal your credentials, which are then stored in plaintext...

[stefanloerwald]

Stolen credentials are not a concern in my use case, as there are no sensitive credentials stored (placeholder credentials in a dev environment). I wanted to share the credentials with a set of containers, without having to configure more than the path to the credential config file. Within the container context, the credStore is not available, so auth just fails.

[0x53A]

@StevenLiekens

Why don't you want to use the credentials store? Renaming or removing "credStore" makes it significantly easier to steal your credentials, which are then stored in plaintext...

---

The windows credentials store does not work for us, because our build script runs elevated: https://github.com/docker/cli/issues/2682#issuecomment-675135899

It turns out you cannot Docker login via an elevated shell depending on your environment as it appears the credentials don't get passed through

It works when I manually remove the credStore from my config.json file, but on the next docker restart docker will replace it with desktop again.

Please either fix the bug that elevated shells can't login, or that credStore gets reset. Either would be fine, preferably both ...

---

And from a philosophical standpoint, the software should do what I tell it to, not the other way around. Why is there a config file if you're just gonna ignore and overwrite it yourself?

[justinmchase]

@StevenLiekens I am experiencing this issue using a corporate IT provisioned machine, the problem with the creds store is that it is somehow blocked by my IT policy:

If i go in and remove the credsStore field from this file and docker build again then all is well. We don't actually need creds at all, the images we are using are either all public or pulled from a private registry through the VPN without credentials, we only upload images through a CI pipeline so no creds are needed.

The problem is every time we restart docker it injects the credsStore back into the WSL environment. If it was possible to disable this feature via docker desktop config, or if it was possible to set the file in windows that was then copied to wsl so we could then update the file there that would be helpful.

As it is now we have to have a special script which wipes out the credsStore field before we docker build every time. Workaround welcome!

[docker-robott]

Issues go stale after 90 days of inactivity. Mark the issue as fresh with /remove-lifecycle stale comment. Stale issues will be closed after an additional 30 days of inactivity.

Prevent issues from auto-closing with an /lifecycle frozen comment.

If this issue is safe to close now please do so.

Send feedback to Docker Community Slack channels #docker-for-mac or #docker-for-windows. /lifecycle stale

[justinmchase]

Adding some activity!

[stefanloerwald]

/remove-lifecycle stale

[stefanloerwald]

@justinmchase sadly this bot only reacts the exact comment /remove-lifecycle stale

[justinmchase]

Got it thanks.

[zorzysty]

I'm having the same issue. Is there any known workaround? Making the file read-only doesn't work for me as it causes docker to crash on start.

[jasper-d]

As a workaround, one can specify credential helpers for private registries explicitly. I did that because the default credential store does not support AWS ECR tokens (they are to long):

{
    "auths": {},
    "credHelpers": {
        "myaccountid.ecr.eu-central-1.amazonaws.com": ""
    },
    "credsStore": "desktop.exe",
    "currentContext": "default",
    "stackOrchestrator": "swarm"
}

The token for the ECR registry will then be stored in plaintext in the config.json, so security wise this is problematic. However, login then works as expected, i.e. aws ecr get-login-password --region eu-central-1 --profile my-aws-profile | docker login --username AWS --password-stdin myaccountid.ecr.eu-central-1.amazonaws.com

From my experience, Docker Desktop usually does not overwrite custom credHelpers settings (i.e. not on every restart but maybe when resetting Docker Desktop or when doing a reinstall etc.).

[matrumz]

I'm having the same issue. This seems like such a simple fix!!! Please correct me if I'm wrong: any developer feedback on this would be nice!

[docker-robott]

Issues go stale after 90 days of inactivity. Mark the issue as fresh with /remove-lifecycle stale comment. Stale issues will be closed after an additional 30 days of inactivity.

Prevent issues from auto-closing with an /lifecycle frozen comment.

If this issue is safe to close now please do so.

Send feedback to Docker Community Slack channels #docker-for-mac or #docker-for-windows. /lifecycle stale

[remal]

Please keep it open

[stefanloerwald]

/remove-lifecycle stale

[shookim]

/lifecycle frozen damn solve this already

[stefanloerwald]

/lifecycle frozen

[stefanloerwald]

/lifecycle frozen damn solve this already

Sadly these commands only work without additional comments ;-) Good idea to freeze though. I doubt it'll ever be worked on. There's just no incentive.

[MartinEmrich]

I also got hit by this, as I had the credentials helper "ecr-login" for AWS Elastic Container Registry configured before.

An (ugly) workaround:

sudo chattr +i ~/.docker/config.json

sets the immutable attribute on the file, preventing changing it by anyone. Now every time Docker Desktop starts, an error message pops up (as it cannot change the file), which is still slightly less annoying than having to revert the config file manually. Of course, if you want to edit the file again, you have to unset the immutable attribute.

[joshkreud]

Also got this combined with https://github.com/docker/for-win/issues/10247. Which makes building images extra slow. Apparently changing credStore in config.json to use a more recent version of a docker credential helper should help there. The chattr +i ... is indeed ugly and at least in my case it blocks docker from starting at all. (missing /var/run/docker.sock)

[guai]

bump

[GabrielOrtizElypta]

A scenario when this becomes very annoying is in a build script where you want to login to the AWS Docker registry, AWS ECR, without specifying the password in the build script. The AWS ECR password is already saved in and AWS credentials file and passed via stdin using pipe from Get-ECRLoginCommand.Password (An AWS CLI powershell command). When Docker Desktop resets config.json to "credsStore":"desktop", it will cause the operation to fail with "Error saving credentials".

Docker Desktop should not update credsStore, only write the (short-lived) auth token to config.json.

[aberenshtein]

+1 on mac

[girol]

+1 on Win

Windows 10 build 22h2 - 19045.2546 Docker Desktop: v4.16.3 WSL 2

[lekjos]

+1 Windows Enterprise 64-bit (10.0, Build 19044) WSL2 - Ubuntu Docker Desktop 4.16.3 (96739)

[Druckles]

Using the comments in the linked issue: https://github.com/docker/for-mac/issues/6295, one solution is to set credentialHelper in settings.json.

The settings.json file can be found under %APPDATA%/Docker/settings.json. For ECR, change the following:

  "credentialHelper": "docker-credential-wincred.exe",

to:

  "credentialHelper": "docker-credential-ecr-login.exe",

This solved the issue both for Docker (e.g. docker pull ...) and Docker Compose. credHelpers, on the other hand, was having no effect in the config.json.

[Druckles]

+1 on mac

@aberenshtein See here for the Mac OS equivalent: https://github.com/docker/for-mac/issues/6295#issuecomment-1385187555.

[linbjo]

The release notes for Docker Desktop 4.19.0 notes that "Docker Desktop now stops overriding .docker/config.json credsStore keys on application start.". This appears to work for the Windows config.json file.

Unfortunately it doesn't fix the problem for the WSL config.json file, which (for me at least) is entirely replaced each time Docker Desktop is restarted (using version 4.20.0).

I'm also unable to use the suggested workarounds in this issue. Setting chattr +i prevents Docker Desktop from stating (as noted above). Adding credHelpers doesn't work since the entire config.json file is replaced.

[xucian]

https://github.com/docker/for-win/issues/9843#issuecomment-876893225

this is the only solution. give this man more hearts

[sliekens]

#9843 (comment)

this is the only solution. give this man more hearts

You are right, this step solves a lot of the issues with Docker in WSL2

[coleshirley]

For me this issue seems to be because I've enabled systemd=true in the /etc/wsl.conf file as in this issue: https://github.com/docker/for-win/issues/13105

Disabling systemd in that file and then restarting wsl and docker-desktop fixes the issue but obviously I want systemd on

[nick-lambdalabs]

+1 on mac

There appear to be two interacting issues here. One is: "why the hell do I even need to delete credsStore from the config in the first place?". The second is: "Why the hell does the desktop app keep adding it back whenever I delete it?"

It blows my mind that I have used this same fix across multiple machines (Windows and Mac) to fix seemingly unrelated issues. It also blows my mind that the desktop software won't respect my wishes and just leave the config file alone.

[gomezjdaniel]

+1 on mac, I have my credHelpers set to private aws registry but credStore keeps appearing

[urvanov-ru]

+1 for Debian. My credStore keeps appearing and I delete it every time.

[dardude69]

+1 for Ubuntu. This has been open for three years? I can't believe people pay for this software.

[MartinEmrich]

I for my part no longer pay. I have uninstalled Docker Desktop, so my company pays one license less. Instead I moved to podman for while now; there are also lots of tutorials online on how to install free docker-ce on WSL2.

[cZalyun]

+1 for Mac.

[KhadimRenahyMar]

/remove-lifecycle stale

[dalekube]

I resolved this on Ubuntu 23.10 (Mantic Minotaur) by adding the credHelpers lines for my private registries in ~/.docker/config.json. Docker then ignored the "credsStore": "desktop" setting that keeps reappearing due to Docker Desktop and uses the standard auths defined in the same file.

"credHelpers": {
    "{REGISTRY URL 1}": "",
    "{REGISTRY URL 2}": ""
}

[francestu96]

In Windows, this Docker config still gives me an ECR authentication problem:

{
    "auths": {},
    "credHelpers": {
        "public.ecr.aws/{public reg ID}": ""
    },
    "credsStore": "desktop",
    "currentContext": "default",
    "plugins": {
        "-x-cli-hints": {
            "enabled": "true"
        }
    }
}

To make it works, I need to delete the "credsStore": "desktop", line but, at Docker start up, it gets added again...