Skip to content

Permission denied error on build when a non-accessible folder exists, regardless of the content in the .dockerignore #3043

@eriknaslund

Description

@eriknaslund

Steps to reproduce the issue:

  1. Have a Dockerfile in your current directory, the exact content of it doesn't matter as long as it's valid.
  2. Issue the following commands
mkdir foo
chmod 700 foo
chown 999:999 foo  # Make sure this is a uid/gid different from your own.
  1. Create a .dockerignore with the following content:
# Exclude everything by default.
*
  1. Issue the command docker build . (you can prefix it with DOCKER_BUILDKIT=1 for a more descriptive error message).

Describe the results you received:

The build fails because the directory foo isn't accessible.

$ DOCKER_BUILDKIT=1 docker build .
[+] Building 0.0s (2/2) FINISHED                                                                                                             
 => ERROR [internal] load build definition from Dockerfile                                                                              0.0s
 => => transferring dockerfile: 67B                                                                                                     0.0s
 => ERROR [internal] load .dockerignore                                                                                                 0.0s
 => => transferring context: 63B                                                                                                        0.0s
------
 > [internal] load build definition from Dockerfile:
------
------
 > [internal] load .dockerignore:
------
failed to solve with frontend dockerfile.v0: failed to read dockerfile: error from sender: open foo: permission denied

Describe the results you expected:
Since the .dockerignore states that everything should be excluded I was surprised that the non-accessible folder was causing problems. I would expect docker to completely ignore that folder during a build.

This causes some real world problems for me because the official Postgres Dockerfile sets up it's .pgdata directory with the uid/gid 999:999. Once that directory exists I'm unable to build any more docker images.

I'm currently using a workaround where I manually change the owner of .pgdata to my own uid/gid (sudo chown -R $(id -u):$(id -g) .pgdata), and then specify the user in my docker-compose.yml. This is not ideal, and it would be sweet if docker build could stop trying to access directories / files excluded by the .dockerignore.

Output of docker version:

Docker version 20.10.5, build 55c4c88966

Output of docker info:

Client:
 Context:    default
 Debug Mode: false
 Plugins:
  app: Docker App (Docker Inc., v0.9.1-beta3)
  buildx: Build with BuildKit (Docker Inc., v0.5.1-tp-docker)

Server:
 Containers: 16
  Running: 2
  Paused: 0
  Stopped: 14
 Images: 90
 Server Version: 20.10.5
 Storage Driver: overlay2
  Backing Filesystem: extfs
  Supports d_type: true
  Native Overlay Diff: false
 Logging Driver: json-file
 Cgroup Driver: cgroupfs
 Cgroup Version: 1
 Plugins:
  Volume: local
  Network: bridge host ipvlan macvlan null overlay
  Log: awslogs fluentd gcplogs gelf journald json-file local logentries splunk syslog
 Swarm: inactive
 Runtimes: io.containerd.runc.v2 io.containerd.runtime.v1.linux runc
 Default Runtime: runc
 Init Binary: docker-init
 containerd version: 05f951a3781f4f2c1911b05e61c160e9c30eaa8e.m
 runc version: 12644e614e25b05da6fd08a38ffa0cfe1903fdec
 init version: de40ad0
 Security Options:
  apparmor
  seccomp
   Profile: default
 Kernel Version: 5.9.16-1-MANJARO
 Operating System: Manjaro Linux
 OSType: linux
 Architecture: x86_64
 CPUs: 16
 Total Memory: 31.18GiB
 Name: casper
 ID: FD7O:BNQ7:AKSX:JJZS:EVSM:QTFF:CRHV:O54Q:SNSR:UJ7U:U27X:VRSB
 Docker Root Dir: /var/lib/docker
 Debug Mode: false
 Registry: https://index.docker.io/v1/
 Labels:
 Experimental: false
 Insecure Registries:
  127.0.0.0/8
 Live Restore Enabled: false

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions