docker build throws an error if a file anywhere in the build context tree can't be read by the current user, even if that file has nothing to do with the build.

[paul-tcell]

Description

docker build throws an error if there is a file unreadable by the current user in the build context directory or any subdirectory of the context dir. Even if the file is unused by the build itself.

Appears related to #6521.

Steps to reproduce the issue:
In some temp directory, create a Dockerfile
e.g

FROM alpine
CMD echo "hello"

in that dir, also create an unreadable file
e.g

touch file_that_has_nothing_to_do_with_build.log
sudo chown root:root file_that_has_nothing_to_do_with_build.log
sudo chmod 0600 file_that_has_nothing_to_do_with_build.log

run docker build:
docker build -t foo .

Describe the results you received:
error checking context: 'no permission to read from '/tmp/docker_error/file_that_has_nothing_to_do_with_build.log''.

Describe the results you expected:
docker building the image.

Additional information you deem important (e.g. issue happens only occasionally):

Output of docker version:

Client:
 Version:      17.06.1-ce
 API version:  1.30
 Go version:   go1.8.3
 Git commit:   874a737
 Built:        Thu Aug 17 22:51:12 2017
 OS/Arch:      linux/amd64

Server:
 Version:      17.06.1-ce
 API version:  1.30 (minimum version 1.12)
 Go version:   go1.8.3
 Git commit:   874a737
 Built:        Thu Aug 17 22:50:04 2017
 OS/Arch:      linux/amd64
 Experimental: false

Output of docker info:

Containers: 16
 Running: 1
 Paused: 0
 Stopped: 15
Images: 113
Server Version: 17.06.1-ce
Storage Driver: aufs
 Root Dir: /var/lib/docker/aufs
 Backing Filesystem: extfs
 Dirs: 200
 Dirperm1 Supported: true
Logging Driver: json-file
Cgroup Driver: cgroupfs
Plugins: 
 Volume: local
 Network: bridge host 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: 6e23458c129b551d5c9871e5174f6b1b7f6d1170
runc version: 810190ceaa507aa2727d7ae6f4790c76ec150bd2
init version: 949e6fa
Security Options:
 apparmor
 seccomp
  Profile: default
Kernel Version: 4.10.0-32-generic
Operating System: Linux Mint 18.2
OSType: linux
Architecture: x86_64
CPUs: 16
Total Memory: 31.31GiB
Name: minty
ID: JYRK:VELJ:H2CK:NMO3:A24S:FUCJ:MVCL:L34I:3CA6:BMDV:DTAY:RQ4Q
Docker Root Dir: /var/lib/docker
Debug Mode (client): false
Debug Mode (server): false
Username: ********
Registry: https://index.docker.io/v1/
Experimental: false
Insecure Registries:
 127.0.0.0/8
Live Restore Enabled: false

WARNING: No swap limit support

Additional environment details (AWS, VirtualBox, physical, etc.):
Physical linux desktop.

[thaJeztah]

When running docker build <some-path>, here's what happens:

The content of <some-path>, except for files excluded through a .dockerignore file, is added to a tar-archive, and uploaded to the daemon (which could be running on the same machine, or a remote machine).

On the daemon, the archive is extracted, then the Dockerfile is evaluated. Each command (some exceptions) in the Dockerfile starts a new container, and if files from the build-context are needed (e.g. a COPY or ADD statement), those files are copied to the container, after which the results are committed to a new image.

Given that the client does not evaluate the Dockerfile, it does not know if a specific file is needed (or not) during build; it simply compresses all files, and sends them to the daemon. If the client does not have permissions to access a file, that step will fail, which is what you're seeing.

How to resolve this?

• If possible structure your project-directory such, that only files and directories that are actually needed for your build are in the build-context.
• Exclude files that are not needed for the build by adding a .dockerignore file. Doing so prevents this problem, but also can speed up build if there are many files that are not needed for your Dockerfile.

Docker 17.06 also adds an (currently experimental) feature to stream the context to the daemon to use this feature, the daemon must be started with experimental features enabled, and you can set the --stream option on docker build (see #32677). This feature add a "session" where the daemon can request files from the client (instead of just uploading all files).

I think that feature would also resolve the problem you're seeing.

I'm closing this issue, because this is not a bug, but due to the way build (currently) works, but feel free to continue the conversation

[mmcclenn]

I would like to see this issue reopened again, since I am running into the same problem.

Here is my suggestion: add an option to docker build, --ignore-unreadable. If this option is given, unreadable files will be left out of the tar file (or the stream) that is sent to the daemon rather than aborting the build.