Docker 18.06 docker build "can't stat" ignored directory that belongs to another user with 700 permission
#380
Comments
|
I am also encountering this issue. I am developing an application which requires a database for development. I am running a local Postgres instance in a Docker container. I mount this Docker container's data directory on my local file system so that the database is persisted between shutdowns. I have added the Postgres container's data directory to my When I try to build my application's Docker image I get the error from the original bug report. Even though I have |
|
I'm running into this as well, same situation as @Noah-Huppert . I came up with a fix that works for now, which is storing the Postgres data folder inside of another folder, and |
|
Thanks @AngelOnFira, that's actually really clever. |
|
i'm experiencing the same thing with docker's root directory. I have a dir structure like the dockerignore contains and /vault/docker is my docker root dir (runs with when building i get and yeah i can work around this by moving /vault/docker into a nested dir |
|
I am experiencing this issue with this version of Docker: The "put it in a subdirectory and ignore the subdirectory" workaround works for me. |
|
I am experiencing this issue on Docker version: Again with a postgres DB volume included in the .dockerignore, but still statted by Docker. Nesting my |
|
Encountered the same issue on |
|
Stumbled on this issue, too using docker version: |
|
I believe I am running into the same problem. Not with a database, but with the containerized application's private file storage. Partial |
|
For me this was caused by running in a folder with a lot of messy folders that were linked to other containers etc. Fixed by moving Dockerfile to a clean, dedicated build folder of its own. |
|
But what does the dockerfile look like? I cannot repro this. |
From the second step of "Steps to reproduce the behavior":
So the example Dockerfile looks like this: |
|
Ok, I think I see why. |
|
in my case following was root cause and soltuions
Solution: |
|
Still happening: |
|
Just add file |
|
The same |
|
I have the same problem but adding the culprit to .dockerignore has no effect |
|
So based on the fact that this problem still exists I'll explain solution that work for me for the last year on different projects: The problem for me was with database storage volume. |
|
Also running into this. Would be nice if .dockerignore respected this. |
Same issue here |
|
Slightly related docker/buildx#1781 |
|
For me the workaround was to stop using dockerignore and do a COPY for specific folders and files. The main reason for this feature would be to avoid including problematic files/folders in the image. But it dies when an ignored file is problematic, like when it belongs to a non-existent user ID. |
|
|
|
Simply just build with |
Even if 'postgres' is included in .dockerignore, Docker still attempts to stat the directory when constructing the build context: docker/for-linux#380 Work around this by moving the Postgres directory and ignoring its parent dir.
SOLVEDafter searching and trying soo many methods , this answer actually solved my issue!experiencing the same issue running the command using 'sudo' is not working for me also, tried adding the path to .dockerignore |
* Unreadable Postgres directory must be inside a readable,
`.dockerignore`d directory
* See docker/for-linux#380
* Fetch `bballgames03.csv`, used by unit tests, from the Internet
Archive
* Upgrade `r-base`
* Unpin `pyopenssl`
* Unpin `urllib3` and install with the `[secure]` extra
* Add instructions for building base image to README
|
This happens to me in a rootless installation of docker: I'm able to build for the first time, but repeating the action fails. It is a headache especially in the case when a user is not allowed to run |
|
I don't get it though, this used to work, right? I'm fairly sure I had a setup where the EDIT: My bad, it's not about the docker version. Build succeeds when using |
|
i have this issue with a sshfs mount too it simply ignores dockerignore :/ i'm not using the snap this workaround still works tho |
|
Is this fixed? is it stuck? What happened here? The issue is still open. |
ye olde open issue: docker/for-linux#380
|
Still not fixed, hit this again today ; the behavior changed however - docker-compose is now in line with docker and fails the same way. |
- repro builds to use fixed uid=1000 inside the container
- in case the file permissions leak into the binaries, they are still reproducible
- chown 1000:1000 fresh_clone
- repro builds to create fresh_clone dir outside git clone
- otherwise the local dev build would still interact with the fresh_clone dir
- due to e.g. recursive "find -exec touch",
- and even the "docker build" cmd itself would try to stat/read it
- see docker/for-linux#380
- and "rm -rf fresh_clone" needs sudo if the host uid is not 1000
- this way the local dev build does not need sudo
to recap:
- local dev builds use the host userid inside the container, directly operate on the project dir
- does not need sudo
- repro builds create a fresh git clone, chown it to 1000, and use userid=1000 inside the container
- if the host userid is 1000, does not need sudo
- otherwise, needs sudo
closes spesmilo#8261
- repro builds to use fixed uid=1000 inside the container
- in case the file permissions leak into the binaries, they are still reproducible
- chown 1000:1000 fresh_clone
- repro builds to create fresh_clone dir outside git clone
- otherwise the local dev build would still interact with the fresh_clone dir
- due to e.g. recursive "find -exec touch",
- and even the "docker build" cmd itself would try to stat/read it
- see docker/for-linux#380
- and "rm -rf fresh_clone" needs sudo if the host uid is not 1000
- this way the local dev build does not need sudo
to recap:
- local dev builds use the host userid inside the container, directly operate on the project dir
- does not need sudo
- repro builds create a fresh git clone, chown it to 1000, and use userid=1000 inside the container
- if the host userid is 1000, does not need sudo
- otherwise, needs sudo
closes spesmilo#8261
- repro builds to use fixed uid=1000 inside the container
- in case the file permissions leak into the binaries, they are still reproducible
- chown 1000:1000 fresh_clone
- repro builds to create fresh_clone dir outside git clone
- otherwise the local dev build would still interact with the fresh_clone dir
- due to e.g. recursive "find -exec touch",
- and even the "docker build" cmd itself would try to stat/read it
- see docker/for-linux#380
- and "rm -rf fresh_clone" needs sudo if the host uid is not 1000
- this way the local dev build does not need sudo
to recap:
- local dev builds use the host userid inside the container, directly operate on the project dir
- does not need sudo
- repro builds create a fresh git clone, chown it to 1000, and use userid=1000 inside the container
- if the host userid is 1000, does not need sudo
- otherwise, needs sudo
closes spesmilo#8261
This has been affecting people for years it seems:
docker/for-linux#380
|
Still relevant and blocker for some situations. |
This allows to put "volumes" subdirectory into .dockerignore and get its contents ignored. Currently the directory that is being ignored may get wrong permissions and operating on it will fail. See also: docker/for-linux#380
and others
Expected behavior
Docker ignores directory which is specified in .dockerignore and proceeds with building an image.
Actual behavior
Docker reports an error: error checking context: 'can't stat '.../DB''.
Steps to reproduce the behavior
Version 18.03 output:
Version 18.06 output:
Output of
docker version:Output of
docker info:Additional environment details (AWS, VirtualBox, physical, etc.)
The text was updated successfully, but these errors were encountered: