Дженкинс неправильно разрешения тома

Question

У меня есть виртуальная машина с Oracle Linux, где я установил Docker и создал контейнеры, используя файл docker-compose. Я поместил том jenkins в общую папку, но при запуске docker-compose я получил следующую ошибку для Jenkins:

Дженкинс | коснуться: не может коснуться '/var/jenkins_home/copy_reference_file.log': Дженкинсу отказано в доступе | Невозможно написать в /var/jenkins_home/copy_reference_file.log. Неправильные разрешения тома? Дженкинс вышел с кодом 1

Вот декларация объемов

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

Answer 1

Это легко исправить с помощью параметра -u. Имейте в виду, это будет работать от имени пользователя root (uid=0)

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

Answer 2

Как сказал Хашибаски, у вашего пользователя в контейнере другой идентификатор пользователя: groupid, чем у пользователя на хосте.

Чтобы обойти это, нужно запустить контейнер без (проблемного) сопоставления тома, а затем запустить bash для контейнера:

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

Попав внутрь оболочки контейнера, запустите команду id, и вы получите следующие результаты:

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

Выйдите из контейнера, перейдите в папку, которую вы пытаетесь сопоставить, и запустите:

chown -R 1000:1000 .

Теперь, когда разрешения совпадают, вы сможете запустить исходную команду docker с сопоставлением томов.

Answer 3

Проблема в том, что у вашего пользователя в контейнере другой ID пользователя: groupid, как у пользователя на хосте.

у вас есть две возможности:

1. Вы можете убедиться, что у пользователя в контейнере тот же идентификатор пользователя: groupid, что и у пользователя на хосте, у которого есть доступ к подключенному тому. Для этого вам нужно настроить пользователя в Dockerfile. Создайте пользователя в файле Docker с тем же идентификатором пользователя: groupid, а затем переключитесь на этого пользователя https://docs.docker.com/engine/reference/builder/

2. Вы можете убедиться, что у пользователя на хосте тот же идентификатор пользователя: groupid, что и у пользователя в контейнере. Для этого введите контейнер с docker exec -it <container-name> bash и показать идентификатор пользователя id -u <username> идентификатор группы id -G <username>, Измените разрешения подключенного тома на этот идентификатор пользователя: groupid.

Answer 4

Возможно, вы находитесь под 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/:

Флаг --privileged предоставляет все возможности контейнера, а также снимает все ограничения, налагаемые контроллером cgroup устройства. Другими словами, контейнер может делать почти все, что может делать хост. Этот флаг существует для особых случаев использования, таких как запуск Docker внутри Docker.

Answer 5

В качестве обновления ответа @Kiem, используя $UID, чтобы убедиться, что контейнер использует тот же идентификатор пользователя, что и хост, вы можете сделать это:

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

Answer 6

Хорошо использоватьdocker-compose.yml.

Инициализировать вы должны датьpriviledged:true&user:rootследующее.

      version: '3'
services:
  jenkins:
    container_name: jenkins
    image: jenkins/jenkins:lts
    ports:
      - "8080:8080"
      - "50000:50000"
    privileged: true
    user: root
    volumes:
      - ./jenkins_home:/var/jenkins_home
    restart: always

Тогда вы сможете успешно запустить контейнер jenkins, запустив "docker-compose up -d".

Answer 7

Прежде всего вы можете подтвердить своего текущего пользователя, используя echo $USERи после этого вы можете указать, кто является пользователем в Dockerfile, как показано ниже (в моем случае пользователь root) снимок экрана

Answer 8

У меня была аналогичная проблема с только что добавленным Minikube/Kubernetes.

      securityContext:
  fsGroup: 1000
  runAsUser: 0

при развертывании -> спецификация -> шаблон -> спецификация

Answer 9

используйте эту команду

      $ chmod +757 /home/your-user/your-jenkins-data

Answer 10

Была аналогичная проблема в MacOS, я установил Jenkins с помощью helm поверх Minikube/Kubenetes после многих намерений, которые я исправил, добавив runAsUser: 0 (от имени root) в values.yaml, который я использую для развертывания jenkins.

master:
  usePodSecurityContext: true
  runAsUser: 0
  fsGroup: 0

Просто будьте осторожны, потому что это означает, что вы будете запускать все свои команды как root.

Answer 11

Эту ошибку решают, используя следующую комнаду.

Перейти к вашему пути подключения данных jenkins: /media

Запустите следующую команду:

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

перезапустите контейнер док-станции jenkins

docker-compose restart jenkins

Answer 12

У меня была та же проблема, которая была решена после отключения SELINUX. Не рекомендуется отключать SELINUX, поэтому установите собственный модуль и включите его. Оно работает. Только изменение разрешений не будет работать на CentOS 7.