moby: Docker build is not running cause the permission of one folder not used in the build process

This image has a startup script that create mysql initial database and change permissions of files in /var/lib/mysql that directory is mounted from local directory volumes/lib the files are owned by mysql user that is create inside the container when you try to build the image and this files exists docker build fail.

How to reproduce

  1. clone the repo:
git clone https://github.com/wiliamsouza/docker-mysql.git
  1. build the image:
docker build -t wiliamsouza/mysql .
  1. run the container:
docker run --name mysql -p 3306:3306 -d \
-v `pwd`/volumes/log:/var/log/mysql \
-v `pwd`/volumes/lib:/var/lib/mysql \
-v `pwd`/volumes/conf.d:/etc/mysql/conf.d \
-e MYSQL_ROOT_PASSWORD=rootpass \
-e MYSQL_DATABASE=mydb \
-e MYSQL_USER=myuser \
-e MYSQL_PASSWORD=mypass -t wiliamsouza/mysql

  1. Change the Dockerfile to use ubuntu version to 14.04.

  2. try build the image using other tag

docker build -t wiliamsouza/mysql:1404 .

Obtained result:

2014/06/18 23:12:04 Error checking context is accessible: 'no permission to read from 'volumes/lib/ib_logfile0''. Please check permissions and try again.

Expected result: Build the image with different tag

After the first run the state of tree and permissions is:

$ tree
.
├── clean.sh
├── Dockerfile
├── fig.yml
├── README.md
├── repos.sh
├── startup
├── supervisord.conf
└── volumes
    ├── conf.d
    │   └── bind.cnf
    ├── lib
    │   ├── ibdata1
    │   ├── ib_logfile0
    │   ├── ib_logfile1
    │   ├── mydb [error opening dir]
    │   ├── mysql [error opening dir]
    │   └── performance_schema [error opening dir]
    └── log
        └── error.log

7 directories, 12 files

$ ls -l volumes/lib/
total 28684
-rw-rw---- 1 syslog netdev 18874368 Jun 18 23:11 ibdata1
-rw-rw---- 1 syslog netdev  5242880 Jun 18 23:11 ib_logfile0
-rw-rw---- 1 syslog netdev  5242880 Jun 18 23:11 ib_logfile1
drwx------ 2 syslog netdev     4096 Jun 18 23:11 mydb
drwx------ 2 syslog root       4096 Jun 18 23:11 mysql
drwx------ 2 syslog netdev     4096 Jun 18 23:11 performance_schema

$ uname -a

Linux envy 3.13.0-29-generic #53-Ubuntu SMP Wed Jun 4 21:00:20 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux

$ docker version

Client version: 1.0.0
Client API version: 1.12
Go version (client): go1.2.1
Git commit (client): 63fe64c
Server version: 1.0.0
Server API version: 1.12
Go version (server): go1.2.1
Git commit (server): 63fe64c

$ docker info

Containers: 3
Images: 47
Storage Driver: aufs
 Root Dir: /var/lib/docker/aufs
 Dirs: 53
Execution Driver: native-0.2
Kernel Version: 3.13.0-29-generic
WARNING: No swap limit support

About this issue

  • Original URL
  • State: closed
  • Created 10 years ago
  • Comments: 26 (14 by maintainers)

Commits related to this issue

Most upvoted comments

@wiliamsouza , here is a possible workaround: create a .dockerignore file and put your volumes directory in it.

+10
domq on Feb 10, 2015

Is this really a bug? I’d image if you did sudo docker build it would work just fine. If your user in the container is writing stuff to a dir with perms that make it so your user where the client is run doesn’t have access it seems to be expected behavior.

+6
cpuguy83 on Feb 10, 2015

We don’t want to ignore errors, this was discussed in #6644 . Warning only works in some cases where the user can actually cancel the build. If there are paths that user knows shouldn’t be included in build context(for permissions or any other reason) they should be listed in .dockerignore. If there are issues with .dockeringore (https://github.com/docker/docker/issues/6521#issuecomment-121633272) please create a new issue and provide details about the contents of your context dir and paths in .dockerignore.

+5
tonistiigi on Sep 9, 2016

I’m having this same issue and not sure how to resolve it. I am running docker build within a folder where I have installed a bunch of node and bower dependencies. Even though I have node_modules in my .dockerignore file, it’s still complaining (I’m assuming because .dockerignore only comes into play when you do a COPY or ADD command):

FATA[0003] Error checking context is accessible: 'can't stat 'src\client\mobile\node_modules\bower\node_modules\update-notifier\node_modules\latest-version\node_modules\package-json\node_modules\got\node_modules\read-all-stream\node_modules\readable-stream\node_modules\core-util-is''. Please check permissions and try again.

$ docker version

Client version: 1.6.2
Client API version: 1.18
Go version (client): go1.4.2
Git commit (client): 7c8fca2
OS/Arch (client): windows/amd64
Server version: 1.6.2
Server API version: 1.18
Go version (server): go1.4.2
Git commit (server): 7c8fca2
OS/Arch (server): linux/amd64

The workaround for me right now is to work out of another folder that doesn’t have those node_modules installed, but I don’t think I should have to. So consider this my “me too” 😃

+5
abeniwal on Jul 15, 2015

Why does docker build have to tar up the entire contents of the directory containing the Dockerfile, as opposed to only those files that are explicitly requested through an ADD command?

+5
domq on Feb 10, 2015

+1 Came across this randomly when trying to build a Dockerfile out of my $HOME.

Interestingly it seems to be something from battle.net client that it is hung up on in my case.

Error checking context is accessible: 'no permission to read from 'Library/Preferences/net.battle.Identity.prefs''. Please check permissions and try again.

Easy enough to workaround by placing the Dockerfile in it’s own folder.

$ docker version
Client version: 1.7.1
Client API version: 1.19
Go version (client): go1.4.2
Git commit (client): 786b29d
OS/Arch (client): darwin/amd64
Server version: 1.7.1
Server API version: 1.19
Go version (server): go1.4.2
Git commit (server): 786b29d
OS/Arch (server): linux/amd64
+3
djdefi on Jul 20, 2015

Maybe the client should stick around a bit more then, and the server should tell it what files it wants (using relative, symlink-free paths only for security)?

+2
domq on Apr 16, 2015

Warning in this scenario is a lot nicer, but honestly the client shouldn’t be worried about these files in the first place. I understand the reason why this can’t be done but this is an implementation issue, not an intended behavior.

I was bit by this earlier because I included a Dockerfile in the root of my Jekyll site and use the image to house the tools to build the site. When I run the container, I mount the entirely of the project into the container and then let Jekyll output the result into _site. Of course, the next time through this cycle, the docker build complains because some files in _site are owned by root and are not world readable. The fact that docker build can fail because of files in the periphery doesn’t seem right.

+1
crawford on Dec 17, 2015

I’m not sure if it’s expected behavior, I agree with @domq that docker build should only use/stat files and dirs that are in the Dockerfile, why should it check other files?

+1
iyn on Apr 16, 2015

I ran into this issue after CircleCI updated their build environment to Docker 1.4.1. Worked fine previous to that with the same build procedure.

+1
hobofan on Jan 1, 2015
Read more comments on GitHub
← moby: docker build hangs/crashes when useradd with large UID
moby: Docker build that fails with overlay storage backend only? →