Collectives™ on Stack Overflow

Find centralized, trusted content and collaborate around the technologies you use most.

Teams

Q&A for work

Connect and share knowledge within a single location that is structured and easy to search.

I am running a docker login command as a part of the Bamboo build job. The command text is obtained by aws ecr get-login call and executed in a subshell.

This command fails with Error saving credentials: error storing credentials - err: exit status 1, out: write permissions error when ran as a part of the Bamboo build, but the exact same command ran in the Terminal on the Mac that is the build agent, it succeeds.

Using Terminal:

Using Bamboo:

Both the Bamboo build and the Terminal session happen under the same user - builduser . whoami is the same for both. stat ~/.docker/config.json is the same for both - writable for both.

Can you think of further ways of discovering the differences between the context Bamboo runs the build in and I do in the terminal? The error above, verbatim, related to docker login is nowhere to be found online.

Try running the docker login command as sudo. It worked for me.

Run this command : sudo docker login .

This will prompt you to enter your sudo password. After providing the password, the login command will run and you will be able to login successfully.

The Problem : you try to login into docker registry and unable to authenticate due to storing credentials error.

Error saving credentials: error storing credentials - err: exit status 1, 
out: `Post "http://ipc/registry/credstore-updated": 
dial unix /var/root/Library/Containers/com.docker.docker/Data/backend.sock: 
connect: no such file or directory`
Solution: according to docker login documentation you have several ways for storing user credentials, and using external store is a best practice and much more secure than keeping it under local configuration.
Credentials store
The Docker Engine can keep user credentials in an external credentials
store, such as the native keychain of the operating system. Using an
external store is more secure than storing credentials in the Docker
configuration file.
To use a credentials store, you need an external helper program to
interact with a specific keychain or external store. Docker requires
the helper program to be in the client’s host $PATH.
This is the list of currently available credentials helpers and where
you can download them from:
D-Bus Secret Service:
https://github.com/docker/docker-credential-helpers/releases Apple
macOS keychain:
https://github.com/docker/docker-credential-helpers/releases Microsoft
Windows Credential Manager:
https://github.com/docker/docker-credential-helpers/releases pass:
https://github.com/docker/docker-credential-helpers/releases
By default, Docker looks for the native binary on each of the platforms, i.e. “osxkeychain” on macOS, “wincred” on windows, and “pass” on Linux. A special case is that on Linux, Docker will fall back to the “secretservice” binary if it cannot find the “pass” binary. If none of these binaries are present, it stores the credentials (i.e. password) in base64 encoding in the config files described above.
Example: on macOS - specify the configuration on $HOME/.docker/config.json and insert osx keychain method, ( if you are already logged in run docker logout in order to remove credentials from the file and run docker login again )
vim ~/.docker/config.json
  "credsStore": "osxkeychain"
I found this question while trying to use ECR to get a Docker container running within a Jenkins pipeline on an AWS EC2 instance with an IAM Instance Profile.  I found lots of information about creating, pushing, and pulling instances from ECR, but not running.  
The goal is a Docker container with the specific Ruby and Ansible versions installed, with all the various dependencies like Gem files.
I found the following Jenkinsfile worked:
pipeline {
    agent any
    environment { 
        DOCKER_CONFIG = "${WORKSPACE}/docker.config"
    stages {
        stage('Build') {
            steps {
                sh("rm -rf ${DOCKER_CONFIG}")
                sh("eval \$(aws ecr get-login --no-include-email | sed 's|https://||')")
                withDockerContainer(args: '-v ${WORKSPACE}:/scripts -v ${HOME}/.aws:/root/.aws', image: 'image_name:latest') {
                    sh("ruby script.rb")
Notes:
The Docker login command alters the .docker/config.json file, and it appears to fail in some cases with a write error.  My guess is that it cannot handle some combination of existing configuration in the file and errors out.  Using the DOCKER_CONFIG environment variable makes it create a new config file locally.
Removing the ${DOCKER_CONFIG} directory may not be necessary, and could possibly take some extra time.  However, I think it might avoid the case where the credentials stored there are stale.
This must be installed: https://github.com/awslabs/amazon-ecr-credential-helper 
I found the eval statement solution here: Jenkins Amazon ECR: no basic auth credentials
Install the following package then try docker login again
sudo apt install install gnupg2 pass
If it still doesn't work, run the command with root privileges
sudo docker login
For me the simplest solution was to create config.json file under .docker directory inside the user home directory:
~/home/.docker/config.json
Then I copied the content of this file from the server from where i was able to login to the docker hub.
        "auths": {
                "https://index.docker.io/v1/": {
                        "auth": "SOMEVALUE"
        "HttpHeaders": {
                "User-Agent": "Docker-Client/18.06.1-ce (linux)"
My fix came from this issue.
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.
I was running these commands in PowerShell as admin; once I switched to a regular command prompt, it worked.
        
Thanks for contributing an answer to Stack Overflow!
Please be sure to answer the question. Provide details and share your research!
But avoid …
Asking for help, clarification, or responding to other answers.
Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.