Docker неверное разрешение apache2

#apache #symfony #docker-compose

#apache #symfony #docker-compose

Вопрос:

У меня проблема с установкой docker. Когда я запускаю свой docker-compose, у меня возникает эта ошибка :

 front_1 | /var/lock/apache2 already exists but is not a directory owned by www-data.
front_1 | Please fix manually. Aborting.
  

У меня эта ошибка, потому что я добавляю эту строку в свой dockerfile conf :

 RUN usermod -u 1000 www-data
  

Но если я удалю эту строку, мой проект symfony не будет работать с docker.

У вас есть какие-либо идеи по решению моей проблемы?

С наилучшими пожеланиями

Ответ №1:

Как я вижу, вы пытаетесь изменить UID пользователя www-data внутри docker, чтобы иметь тот же идентификатор, что и UID пользователя хост-машины (вы), чтобы вы могли открывать файлы проекта в своей IDE.

Это приводит к проблемам с правами доступа к файлам в службе apache2, которая не может читать свои собственные файлы (config, pid, …) просто потому, что это уже не тот пользователь.

Быстрое «грязное» решение — изменить только владельца файлов проекта symfony на UID 1000, но сохранить group (GID) для www-данных. Это относится только к машине разработчика. Иначе вам это не нужно. Запустите команду внутри контейнера.

 chown -R 1000:www-data /home/project
  

Вы можете создать некоторый псевдоним bash внутри docker, чтобы иметь его под рукой.

Другой вариант — использовать ACL, который установит существующие файлы и папки с разрешениями, которые будут унаследованы для вновь созданных файлов в данной папке. Это может быть помещено в скрипт начальной загрузки внутри контейнера. Но только для режима разработки. Таким образом, вам не нужно будет запускать chown.

 chown -R 1000:www-data /home/project #set for existing files
/usr/bin/setfacl -R -m u:www-data:rwx -m u:0:rwx -m u:1000:rwx /home/project
/usr/bin/setfacl -dR -m u:www-data:rwx -m u:0:rwx -m u:1000:rwx /home/project
  

Каждый -m предназначен для другого пользователя. Первый — www-data (apache2), второй — 0 (root), а третий — 1000 (вы).

Помните, что UID может измениться в любое время. Таким образом, это может создать брешь в безопасности, если упомянутые пользователи не имеют надлежащего UID. Я использовал второй метод только для папок, где PHP через apache2 устанавливает разрешения (загруженные файлы, кэш, …), Но пользователь хоста должен получить доступ к этим файлам.