Solution for Docker container without permission to write to host directory

When applying the docker container, more often we mount the host directory into the docker container.

When the folder permission of the host belongs to root, we need to set chown for the folder permission user to ensure the normal writing of the contents of the directory.

Here's an example:

The docker version of jenkins was used, and after running, the following error occurred:

[root@localhost CICD]# docker logs -f jenkins 
touch: cannot touch '/var/jenkins_home/copy_reference_file.log': Permission denied
Can not write to /var/jenkins_home/copy_reference_file.log. Wrong volume permissions?

My jenkins mounted directory is/opt/jenkins/xxxxx, created by root users, and uid for jenkins user is 1000

So you need to set up chown as follows:

sudo chown -R 1000:1000 /opt/jenkins

Then restart the container, and the error will be gone.

Add: Describes two ways to handle file permissions when writing volumes from Docker containers

Say in front

Containers are often used as substitutes for native installation tools. It is much better to use containers with the required version on the host than to use outdated tools. However, as long as the container interacts with the host system, the file will leave errors or corrupted permissions.

Fortunately, the solution to this problem does not require scripts.

Problem description

When the container mounts a local directory and writes files to it, its ownership is determined by the user in the container:

nicholas@host:~/source$ mkdir source
nicholas@host:~/source$ docker run -it --rm --volume $(pwd):/source --workdir /source ubuntu
root@a031d11c9515:/source# mkdir subdir
root@a031d11c9515:/source# touch subdir/newfile
root@a031d11c9515:/source# exit
exit
nicholas@host:~/source$ ls -lR
.:
total 4
drwxr-xr-x 2 root root 4096 Jul 16 19:35 subdir
 
./subdir:
total 0
-rw-r--r-- 1 root root 0 Jul 16 19:35 newfile
nicholas@host:~/source$ rm -rf subdir/
rm: cannot remove 'subdir/newfile': Permission denied

In addition, you may not be able to delete these directories and files with wrong ownership.

Solution 1: Remove from the container

1 A very common solution is to change the ownership of files and directories from within the container:

nicholas@host:~/source$ docker run -it --rm --volume $(pwd):/source --workdir /source ubuntu
root@d1c3bee8bb2b:/source# ls -al
total 12
drwxrwxr-x 3 1000 1004 4096 Jul 16 19:35 .
drwxr-xr-x 1 root root 4096 Jul 16 19:39 ..
drwxr-xr-x 2 root root 4096 Jul 16 19:35 subdir
root@d1c3bee8bb2b:/source# chown 1000:1000 subdir/ -R
root@d1c3bee8bb2b:/source# ls -l
total 4
drwxr-xr-x 2 1000 1000 4096 Jul 16 19:35 subdir
root@d1c3bee8bb2b:/source# exit
exit
nicholas@host:~/source$ ls -l
total 4
drwxr-xr-x 2 nicholas lpadmin 4096 Jul 16 19:35 subdir
nicholas@host:~/source$

The disadvantages of this approach are that additional logic needs to be added and that you need to know the user ID and the group ID running the container user.

Solution 2: Create a file with correct ownership

The second solution is more concise and creates files and directories with the correct ownership within the container. Docker provides 1 parameter to set user ID and group ID for users in the container:

nicholas@host:~/source$ docker run -it --rm --volume $(pwd):/source --workdir /source --user $(id -u):$(id -g) ubuntu
groups: cannot find name for group ID 1004
I have no name!@bf7f355f3b65:/source$ touch newfile
I have no name!@bf7f355f3b65:/source$ exit
exit
nicholas@host:~/source$ ls -l
total 4
-rw-r--r-- 1 nicholas nicholas  0 Jul 16 19:42 newfile
drwxr-xr-x 2 nicholas lpadmin 4096 Jul 16 19:35 subdir
nicholas@host:~/source$

This method can help you solve user ID and group ID errors.

Note that for security purposes, running as root inside the container is the worst practice. Dockerfile should always use the USER directive to avoid using root permissions directly.