#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 устанавливает разрешения (загруженные файлы, кэш, …), Но пользователь хоста должен получить доступ к этим файлам.