Jenkins 错误的卷权限

Jenkins wrong volume permissions

我有一个托管 Oracle Linux 的虚拟机,我在其中安装了 Docker 并使用 docker-compose 文件创建了容器。我将 jenkins 卷放在一个共享文件夹下,但是在启动 docker-compose up 时,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

这是卷声明

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

问题是,容器中的用户与主机上的用户不同userid:groupid。

你有两种可能:

  1. 您可以确保容器中的用户与主机上的用户具有相同的 userid:groupid,后者可以访问已安装的卷。为此,您必须在 Dockerfile 中调整用户。在dockerfile中创建一个相同userid:groupid的用户,然后切换到这个用户https://docs.docker.com/engine/reference/builder/#user

  2. 可以确保主机上的用户与容器中的用户具有相同的userid:groupid。为此,进入带有 docker exec -it <container-name> bash 的容器并显示用户 ID id -u <username> 组 ID id -G <username>。将挂载卷的权限改成这个userid:groupid.

正如 haschibaschi 所说,容器中的用户与主机上的用户不同 userid:groupid。

解决这个问题的方法是在没有(有问题的)卷映射的情况下启动容器,然后在容器上 运行 bash:

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

一旦进入容器的 shell 运行 id 命令,您将得到如下结果:

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

退出容器,转到您要映射的文件夹,然后运行:

chown -R 1000:1000 .

现在权限匹配,您应该可以 运行 带有卷映射的原始 docker 命令。

使用以下命令解决此错误。

转到您的 jenkins 数据装载路径:/media

运行 以下命令:

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

重启詹金斯docker容器

docker-compose restart jenkins

使用 -u 参数很容易修复它。请记住,这将 运行 作为 root 用户 (uid=0)

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

我遇到了同样的问题,但在禁用 SELINUX 后已解决。 不建议禁用 SELINUX,因此请安装自定义 semodule 并启用它。 有用。仅更改权限在 CentOS 7 上不起作用。

首先你可以使用echo $USER命令验证你当前的用户 之后你可以像下面这样提到 Dockerfile 中的用户是谁(在我的例子中用户是 root) screenshot

您可能在 SELinux 下。 运行 特权容器为我解决了这个问题:

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

来自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.

在 MacOS 上有一个类似的问题,我在 Minikube/Kubenetes 上使用 helm 安装了 Jenkins,经过多次修复后,我在 values.yaml 中添加了 运行AsUser: 0(作为 root) ] 我用来部署jenkins.

master:
  usePodSecurityContext: true
  runAsUser: 0
  fsGroup: 0

请小心,因为这意味着您将 运行 以 root 身份执行所有命令。

作为@Kiem 回复的更新,使用 $UID 确保容器使用与主机相同的用户 ID,您可以这样做:

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

我刚添加 Minikube/Kubernetes 时遇到了类似的问题

securityContext:
  fsGroup: 1000
  runAsUser: 0

正在部署 -> 规范 -> 模板 -> 规范