moby: `docker build` fails to pull base image from private repository

Description

A Dockerfile which specifies a base image that comes from a private Docker repository fails to build with an ‘image not found’ error if the image is not already locally cached. However, if you first docker pull the image and then attempt a docker build, the build succeeds.

Steps to reproduce the issue:

  1. Create a simple Dockerfile which starts with FROM [your_private_repo]/foobar:1.0.0
  2. docker build .

Describe the results you received:

Sending build context to Docker daemon  4.096kB
Step 1/1 : FROM [your_private_repo]/foobar:1.0.0
repository [your_private_repo]/foobar not found: does not exist or no pull access

Describe the results you expected:

Docker should have pulled the base image down and built my Docker image.

Output of docker version:

Client:
 Version:      17.05.0-ce
 API version:  1.29
 Go version:   go1.7.5
 Git commit:   89658be
 Built:        Thu May  4 21:43:09 2017
 OS/Arch:      darwin/amd64

Server:
 Version:      17.05.0-ce
 API version:  1.29 (minimum version 1.12)
 Go version:   go1.7.5
 Git commit:   89658be
 Built:        Thu May  4 21:43:09 2017
 OS/Arch:      linux/amd64
 Experimental: true

Output of docker info:

Containers: 1
 Running: 0
 Paused: 0
 Stopped: 1
Images: 13
Server Version: 17.05.0-ce
Storage Driver: aufs
 Root Dir: /var/lib/docker/aufs
 Backing Filesystem: extfs
 Dirs: 80
 Dirperm1 Supported: true
Logging Driver: json-file
Cgroup Driver: cgroupfs
Plugins:
 Volume: local
 Network: bridge host ipvlan macvlan null overlay
Swarm: inactive
Runtimes: runc
Default Runtime: runc
Init Binary: docker-init
containerd version: 9048e5e50717ea4497b757314bad98ea3763c145
runc version: 9c2d8d184e5da67c95d601382adf14862e4f2228
init version: 949e6fa
Security Options:
 seccomp
  Profile: default
Kernel Version: 4.9.27-moby
Operating System: Alpine Linux v3.5
OSType: linux
Architecture: x86_64
CPUs: 4
Total Memory: 1.952GiB
Name: moby
ID: H7B3:OZ5P:VPCF:PULL:VS55:QDZZ:JTTR:F3FS:5BYM:YNHT:QBCV:GVNV
Docker Root Dir: /var/lib/docker
Debug Mode (client): false
Debug Mode (server): true
 File Descriptors: 17
 Goroutines: 26
 System Time: 2017-05-17T14:45:49.72323719Z
 EventsListeners: 1
No Proxy: *.local, 169.254/16
Registry: https://index.docker.io/v1/
Experimental: true
Insecure Registries:
 127.0.0.0/8
Live Restore Enabled: false

Additional environment details (AWS, VirtualBox, physical, etc.): Docker Community Edition Version 17.05.0-ce-mac11 (17656) Channel: edge ffbc5f5871

About this issue

  • Original URL
  • State: open
  • Created 7 years ago
  • Reactions: 17
  • Comments: 52 (12 by maintainers)

Most upvoted comments

I found that this is related to the use of credsStore in .docker/config.json. When using osxkeychain as the credsStore, it fails. But when reverting back to the old way (by removing the credsStore entry and executing a docker login again), it works.

Experiencing this still in latest Docker on MacOSX

FYI: Still an issue on Linux + Docker 19.03.8, using the AWS credential helper. Workaround = explicit docker pull before the docker build in all of our CI scripts, which is nasty. Our CI runners are granted authorization via AWS IAM roles, and docker is just configured with a .docker/config.json file containing:

{
  "credsStore": "ecr-login"
}

…but it looks like docker registry authentication only works on an explicit docker pull or docker push, but not for implicit pull triggered by a docker build. I think that ^ describes what most of the people on this issue are experiencing, whether it’s GCR, ECR, MacOS or Linux.

@PSPawanSharma looks like you missed the colon (:) between the image name and its tag; try python:2.7-slim

I just hit this issue using the amazon-ecr-credential-helper in conjunction with a private GitLab Docker registry. ECR is configured as a credsHelper and our CI machines used docker login to the private registry. docker pull works for both registries, but attempting to build an image that references the private registry in the Dockerfile would fail with access forbidden. This is all on Linux machines, no OSX involved.

This issue affects stable and edge releases of Docker. However, I just build a base from 18.03.0-rc1 and this issues appears to be resolved there.

The same issues happens with the ecr-helper from aws (https://github.com/awslabs/amazon-ecr-credential-helper).

A separate initial pull solves the issue, but when the image isn’t available a does not exist or no pull access is given

I am possibly running into the same issue.

If you are having this issue, do not delete ~/.docker/config.json file since docker will regenerate the file. Instead remove the line "credsStore": "osxkeychain" and the comma , on previous line.

@mrburrito hum… that’s weird 😓 I’ll try to reproduce next week (back in Europe where my macbook is 😅)

Nope. Did a docker logout/docker login several times. Tried deleting ~/.docker/config.json and re-logging in. Still getting this error:

$ docker build --pull -t login:test .
Sending build context to Docker daemon    214kB
Step 1/3 : FROM my.private.repo/base/python:2-slim
Get https://my.private.repo/v2/base/python/manifests/2-slim: denied: access forbidden

docker pull my.private.repo/base/python:2-slim docker run my.private.repo/base/python:2-slim both work properly

In my case, I get an unauthorized: authentication required error while pulling from a private repo:

docker build -f "build/go/Dockerfile" -t go-schema-builder .

Sending build context to Docker daemon 715.3 kB
Step 1/6 : FROM registry:8082/eng-docker/grpc-go:1.0.0
Pulling repository registry:8082/eng-docker/grpc-go
unauthorized: authentication required

However, when I delete credsStore from .docker/config.json and docker login again, the image is pulled successfully.

OS: MacOS 10.12.5

Output of docker version

Client:
 Version:      17.03.1-ce
 API version:  1.27
 Go version:   go1.7.5
 Git commit:   c6d412e
 Built:        Tue Mar 28 00:40:02 2017
 OS/Arch:      darwin/amd64

Server:
 Version:      17.03.1-ce
 API version:  1.27 (minimum version 1.12)
 Go version:   go1.7.5
 Git commit:   c6d412e
 Built:        Fri Mar 24 00:00:50 2017
 OS/Arch:      linux/amd64
 Experimental: true

Output of docker info:

» docker info
Containers: 0
 Running: 0
 Paused: 0
 Stopped: 0
Images: 84
Server Version: 17.03.1-ce
Storage Driver: overlay2
 Backing Filesystem: extfs
 Supports d_type: true
 Native Overlay Diff: true
Logging Driver: json-file
Cgroup Driver: cgroupfs
Plugins:
 Volume: local
 Network: bridge host ipvlan macvlan null overlay
Swarm: inactive
Runtimes: runc
Default Runtime: runc
Init Binary: docker-init
containerd version: 4ab9917febca54791c5f071a9d1f404867857fcc
runc version: 54296cf40ad8143b62dbcaa1d90e520a2136ddfe
init version: 949e6fa
Security Options:
 seccomp
  Profile: default
Kernel Version: 4.9.27-moby
Operating System: Alpine Linux v3.5
OSType: linux
Architecture: x86_64
CPUs: 4
Total Memory: 5.818 GiB
Name: moby
ID: L37A:6EAB:AGB5:2FWJ:WUBV:DBJV:3CBL:XNMK:K5CI:PDAU:NTYX:OZD6
Docker Root Dir: /var/lib/docker
Debug Mode (client): false
Debug Mode (server): true
 File Descriptors: 16
 Goroutines: 26
 System Time: 2017-05-23T13:30:23.82777211Z
 EventsListeners: 1
No Proxy: *.local, 169.254/16
Registry: https://index.docker.io/v1/
Experimental: true
Insecure Registries:
 127.0.0.0/8
Live Restore Enabled: false

➜ dockerfile2 git:(zhangjian) ✗ docker build . Sending build context to Docker daemon 2.048kB Step 1/7 : FROM unbuntu pull access denied for unbuntu, repository does not exist or may require ‘docker login’

thanks! who can help me?

I’ve still experienced this issue on edge

$ docker --version
Docker version 17.06.0-ce, build 02c1d87
$ docker info
Containers: 0
 Running: 0
 Paused: 0
 Stopped: 0
Images: 0
Server Version: 17.06.0-ce
Storage Driver: overlay2
 Backing Filesystem: extfs
 Supports d_type: true
 Native Overlay Diff: true
Logging Driver: json-file
Cgroup Driver: cgroupfs
Plugins:
 Volume: local
 Network: bridge host ipvlan macvlan null overlay
 Log: awslogs fluentd gcplogs gelf journald json-file logentries splunk syslog
Swarm: inactive
Runtimes: runc
Default Runtime: runc
Init Binary: docker-init
containerd version: cfb82a876ecc11b5ca0977d1733adbe58599088a
runc version: 2d41c047c83e09a6d61d464906feb2a2f3c52aa4
init version: 949e6fa
Security Options:
 seccomp
  Profile: default
Kernel Version: 4.9.31-moby
Operating System: Alpine Linux v3.5
OSType: linux
Architecture: x86_64
CPUs: 4
Total Memory: 3.855GiB
Name: moby
ID: NFJT:2M5U:6T5G:W7UH:KSG5:HTIG:HVW2:KA4U:YQSD:LJYO:ODNP:24GW
Docker Root Dir: /var/lib/docker
Debug Mode (client): false
Debug Mode (server): true
 File Descriptors: 19
 Goroutines: 29
 System Time: 2017-07-14T13:11:09.703772098Z
 EventsListeners: 1
Registry: https://index.docker.io/v1/
Experimental: true
Insecure Registries:
 127.0.0.0/8
Live Restore Enabled: false

The issue occurred for me whether I was logged in or logged out. When logging out of the internal registry, I received the following warning:

WARNING: could not erase credentials: error erasing credentials - err: exit status 1, out: `The specified item could not be found in the keychain.`

Although I could verify the auths entry was removed properly from cat ~/.docker/config.json, I looked in Keychain Access under login/passwords and “Docker Credentials” still existed for our internal registry. I checked the password in that store, and it was my correct current password.

After manually deleting the password from the credstore and doing another docker login $DOCKER_REG to login to the internal registry, my image built successfully. I’ve tested logging out and logging back in a few times, and the image fails as expected when logged out and succeeds when logged in.

It seems to be a problem with that initial removal of credentials from the keychain which is causing problems because it is sent along with the build context regardless of your config. For example, I can manually remove my internal registry from the auths key in ~/.docker/config.json and the Docker Credential password is still used to pull our internal image.

Removing all containers in installation of edge is a bit tricky at the moment, might be able to check at the end of the week.

I’m seeing an identical as @tusharm , I get an unauthorized: authentication required error when building from a remote private repo

$ docker build -f Dockerfile.data-extraction-dota -t "data-extraction-dota/latest" .
Sending build context to Docker daemon 583.1 MB;
Step 1/16 : FROM my_private_repo/ubuntu-python-ds-base-
image
Pulling repository my_private_repo/ubuntu-python-ds-base-
image
unauthorized: authentication required

cat ~/.docker/config.json:

{
        "auths": {
                "my_private_repo": {}
        },
        "credsStore": "osxkeychain"
}

When I delete the fields according to @surajbarkale-dolby, and do docker login -u -p -e None my_private_repo, docker build works


mac osx 10.12.3

Docker version:

     Client:
     Version:      17.03.1-ce
     API version:  1.27
     Go version:   go1.7.5
     Git commit:   c6d412e
     Built:        Tue Mar 28 00:40:02 2017
     OS/Arch:      darwin/amd64

    Server:
     Version:      17.03.1-ce
     API version:  1.27 (minimum version 1.12)
     Go version:   go1.7.5
     Git commit:   c6d412e
     Built:        Fri Mar 24 00:00:50 2017
     OS/Arch:      linux/amd64
     Experimental: true

Docker info:

Containers: 0
 Running: 0
 Paused: 0
 Stopped: 0
Images: 0
Server Version: 17.03.1-ce
Storage Driver: overlay2
 Backing Filesystem: extfs
 Supports d_type: true
 Native Overlay Diff: true
Logging Driver: json-file
Cgroup Driver: cgroupfs
Plugins: 
 Volume: local
 Network: bridge host ipvlan macvlan null overlay
Swarm: inactive
Runtimes: runc
Default Runtime: runc
Init Binary: docker-init
containerd version: 4ab9917febca54791c5f071a9d1f404867857fcc
runc version: 54296cf40ad8143b62dbcaa1d90e520a2136ddfe
init version: 949e6fa
Security Options:
 seccomp
  Profile: default
Kernel Version: 4.9.27-moby
Operating System: Alpine Linux v3.5
OSType: linux
Architecture: x86_64
CPUs: 2
Total Memory: 1.952 GiB
Name: moby
ID: YDGA:KEGL:MJCB:HCGG:LE7R:EABN:HJ5X:K5VE:ZBNE:AIYP:N6A6:D2OJ
Docker Root Dir: /var/lib/docker
Debug Mode (client): false
Debug Mode (server): true
 File Descriptors: 16
 Goroutines: 26
 System Time: 2017-06-07T12:02:18.373092017Z
 EventsListeners: 1
No Proxy: *.local, 169.254/16
Registry: https://index.docker.io/v1/
Experimental: true
Insecure Registries:
 127.0.0.0/8
Live Restore Enabled: false