docker
docker cp files from host to container have the wrong permission
Description
Files copied into a container with docker cp will still have the host uid:gid. This makes impossible to edit or remove the files inside the container. Moreover, executing docker cp again does not overwrite the file inside the container. To remove the file, the container must be shut down and removed, then started up again.
From the official documentation
The cp command behaves like the Unix cp -a command in that directories are copied recursively with permissions preserved if possible. **Ownership is set to the user and primary group at the destination. For example, files copied to a container are created with UID:GID of the root user. **
Reproduce
docker cp host/path container:target/path -> file is copied, but with host uid:gid
docker cp -a host/path container:target/path -> file is not copied, Error response from daemon: getent unable to find entry "1000" in passwd database. Seems like it is trying to change ownership before moving the file inside the container, but user 1000 does not exist in my host machine.
docker cp container:target/path host/path -> works correctly
docker cp -a container:target/path host/path -> works the same as -a, so uid:gid is not the one from the container but it is changed to match the host.
Expected behavior
docker cp host/path container:target/path -> file is copied to match the container root user (root:root in my case)
docker cp -a host/path container:target/path -> file should be copied but uid:gid should not be changed, so uid:gid will be the one from the host
docker cp container:target/path host/path -> already working
docker cp -a container:target/path host/path -> should copy the file on the host, but uid:gid should still be the root user of the container (root:root in my case)
docker version
Client: Docker Engine - Community
Version: 23.0.3
API version: 1.42
Go version: go1.19.7
Git commit: 3e7cbfd
Built: Tue Apr 4 22:05:41 2023
OS/Arch: linux/amd64
Context: default
Server: Docker Engine - Community
Engine:
Version: 23.0.3
API version: 1.42 (minimum version 1.12)
Go version: go1.19.7
Git commit: 59118bf
Built: Tue Apr 4 22:05:41 2023
OS/Arch: linux/amd64
Experimental: false
containerd:
Version: 1.6.20
GitCommit: 2806fc1057397dbaeefbea0e4e17bddfbd388f38
runc:
Version: 1.1.5
GitCommit: v1.1.5-0-gf19387a
docker-init:
Version: 0.19.0
GitCommit: de40ad0
docker info
Client:
Context: default
Debug Mode: false
Plugins:
buildx: Docker Buildx (Docker Inc.)
Version: v0.10.4
Path: /usr/libexec/docker/cli-plugins/docker-buildx
compose: Docker Compose (Docker Inc.)
Version: v2.17.2
Path: /usr/libexec/docker/cli-plugins/docker-compose
Server:
Containers: 10
Running: 10
Paused: 0
Stopped: 0
Images: 71
Server Version: 23.0.3
Storage Driver: overlay2
Backing Filesystem: extfs
Supports d_type: true
Using metacopy: false
Native Overlay Diff: true
userxattr: 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 runc
Default Runtime: runc
Init Binary: docker-init
containerd version: 2806fc1057397dbaeefbea0e4e17bddfbd388f38
runc version: v1.1.5-0-gf19387a
init version: de40ad0
Security Options:
apparmor
seccomp
Profile: builtin
Kernel Version: 4.15.0-208-generic
Operating System: Ubuntu 18.04.6 LTS
OSType: linux
Architecture: x86_64
CPUs: 12
Total Memory: 62.89GiB
Name: thrawn
ID: 8d2a9ddb-8651-418c-acb3-c3aeae9091a8
Docker Root Dir: /home/docker
Debug Mode: false
HTTP Proxy: http://my-proxy:8080
HTTPS Proxy: http://my-proxy:8080
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 Info
No response
### Tasks
Instead of using docker cp directly, you can use a combination of tar and docker exec to copy files with the desired ownership into the container. $ tar -cC /path/to/host/dir . | docker exec -i container_name tar -xC /path/to/container/dir
If you've already copied the files using docker cp and they have the host's UID:GID, you can adjust the ownership inside the container using the chown command. However, you'll need to do this for each file separately: $docker exec container_name chown root:root /path/to/container/file
Instead of using docker cp directly, you can use a combination of tar and docker exec to copy files with the desired ownership into the container. $ tar -cC /path/to/host/dir . | docker exec -i container_name tar -xC /path/to/container/dir
If you've already copied the files using docker cp and they have the host's UID:GID, you can adjust the ownership inside the container using the chown command. However, you'll need to do this for each file separately: $docker exec container_name chown root:root /path/to/container/file
In some containers I do not have the right to use chown on the files, in particular when the container has not root user. It has been months since I have opened this issue, so I do not remember the problem exacly, but I am sure I had tried chown and it didn't work. Anyway either docker is not working correctly, or the docker documentation is wrong. The solution is not supposed to be some weird hack with tar and docker exec.
I am encountering a similar issue when creating a new container. The container is created and then two files that are needed for startup are copied into the container. These files have the wrong permissions and are not accessible by the server process started in the container. The server process continually restarts until each file is chmod'ed to the correct permissions once the container starts.
What is needed is to be able to tell the cp command what container relative permissions the copied files need to have.
