Jenkins wrong volume permissions

Question

I have a virtual machine hosting Oracle Linux where I've installed Docker and created containers using a docker-compose file. I placed the jenkins volume under a shared folder but when starting the docker-compose up I got the following error for Jenkins :

jenkins | touch: cannot touch ‘/var/jenkins_home/copy_reference_file.log’: Permission denied jenkins | Can not write to /var/jenkins_home/copy_reference_file.log. Wrong volume permissions? jenkins exited with code 1

Here's the volumes declaration

  volumes:
    - "/media/sf_devops-workspaces/dev-tools/continuous-integration/jenkins:/var/jenkins_home"

Answer 1

The problem is, that your user in the container has different userid:groupid as the user on the host.

you have two possibilities:

1. You can ensure that the user in the container has the same userid:groupid like the user on the host, which has access to the mounted volume. For this you have to adjust the user in the Dockerfile. Create a user in the dockerfile with the same userid:groupid and then switch to this user https://docs.docker.com/engine/reference/builder/#user

2. You can ensure that the user on the host has the same userid:groupid like the user in the container. For this, enter the container with docker exec -it <container-name> bash and show the user id id -u <username> group id id -G <username>. Change the permissions of the mounted volume to this userid:groupid.

Answer 2

The easy fix it to use the -u parameter. Keep in mind this will run as a root user (uid=0)

docker run -u 0 -d -p 8080:8080 -p 50000:50000 -v /data/jenkins:/var/jenkins_home jenkins/jenkins:lts

Answer 3

As haschibaschi stated your user in the container has different userid:groupid than the user on the host.

To get around this is to start the container without the (problematic) volume mapping, then run bash on the container:

docker run -p 8080:8080 -p 50000:50000 -it jenkins bin/bash

Once inside the container's shell run the id command and you'll get results like:

uid=1000(jenkins) gid=1000(jenkins) groups=1000(jenkins)

Exit the container, go to the folder you are trying to map and run:

chown -R 1000:1000 .

With the permissions now matching, you should be able to run the original docker command with the volume mapping.

Answer 4

This error solve using following commnad.

goto your jenkins data mount path : /media

Run following command :

cd /media
sudo chown -R ubuntu:ubuntu sf_devops-workspaces

restart jenkins docker container

docker-compose restart jenkins

Answer 5

You may be under SELinux. Running the container as privileged solved the issue for me:

sudo docker run --privileged -p 8080:8080 -p 50000:50000 -v /data/jenkins:/var/jenkins_home jenkins/jenkins:lts

From https://docs.docker.com/engine/reference/commandline/run/#full-container-capabilities---privileged:

The --privileged flag gives all capabilities to the container, and it also lifts all the limitations enforced by the device cgroup controller. In other words, the container can then do almost everything that the host can do. This flag exists to allow special use-cases, like running Docker within Docker.

Answer 6

Had a similar issue on MacOS, I had installed Jenkins using helm over a Minikube/Kubenetes after many intents I fixed it adding runAsUser: 0 (as root) in the values.yaml I use to deploy jenkins.

master:
  usePodSecurityContext: true
  runAsUser: 0
  fsGroup: 0

Just be careful because that means that you will run all your commands as root.

Answer 7

As an update of @Kiem's response, using $UID to ensure container uses the same user id as the host, you can do this:

docker run -u $UID -d -p 8080:8080 -p 50000:50000 -v /data/jenkins:/var/jenkins_home jenkins/jenkins:lts

Answer 8

first of all you can verify your current user using echo $USER command and after that you can mention who is the user in the Dockerfile like bellow (in my case user is root) screenshot

Answer 9

I had same issue it got resolved after disabling the SELINUX. It's not recommended to disable the SELINUX so install custom semodule and enable it. It works. Only changing the permissions won't work on CentOS 7.