Решено! Проблема с правами доступа на сервере без панели.
Введение
Проблема с правами доступа к файловой системе может возникнуть когда мы управляем сервером без панели управления. Зачем может понадобиться управлять сервером именно так и как это сделать описано в этой статье. Разграничение прав между пользователями, веб-сервером и сервисами требует особого внимания, иначе можем получить неработающий сайт, ошибки при записи файлов и головную боль при каждом обновлении. В этой статье мы рассмотрим основные сложности, связанные с правами доступа, и предложим оптимальные решения.
Основные проблемы с правами доступа
1. Разные пользователи для разных процессов
На сервере могут работать разные пользователи:
- Наш основной пользователь (например,
user), который редактирует файлы через SSH или SFTP. - Веб-сервер (например,
www-dataдля Nginx/Apache), который должен иметь доступ к файлам. - Базы данных, кэш-системы и другие сервисы, которым тоже может потребоваться доступ.
Когда файлы создаются одним пользователем, а веб-серверу требуется их изменять, возникают конфликты: сайт может не обновляться, медиафайлы не загружаться, а плагины не устанавливаться.
2. Ошибки при загрузке файлов через веб-интерфейс
При попытке загрузить файлы через WordPress или другой CMS мы можем столкнуться с ошибками вроде «Не удалось создать файл в директории uploads». Это происходит из-за того, что серверу запрещено записывать файлы, созданные нашим пользователем.
3. Изменение владельца файлов ломает доступ
Один из частых «решений» — просто менять владельца всех файлов на www-data, но тогда мы теряем доступ к ним при редактировании через SFTP или SSH. Обратная смена владельца (user) приводит к тому, что WordPress снова не может работать с файлами. Это очень эмоционально затратно, а при несдержанной натуре и материально невыгодно. Разбитые мониторы ещё никому не шли на пользу 🙂 Давайте подробно разберём пути решения и закроем этот вопрос без жертв.
Оптимальное решение
Чтобы обе стороны (и веб-сервер, и наш пользователь) могли работать с файлами, мы применяем несколько методов:
1. Добавление пользователя в группу веб-сервера
Первым шагом мы добавляем нашего пользователя (user) в группу www-data:
sudo usermod -aG www-data user
После этого у него будет доступ ко всем файлам, принадлежащим www-data.
2. Назначение владельца и группы для веб-проектов
Меняем владельца и группу всех файлов в /var/www на www-data:www-data:
sudo chown -R www-data:www-data /var/www
3. Правильные права доступа к файлам и папкам
Настраиваем права так, чтобы и веб-сервер, и наш пользователь могли работать с файлами:
sudo find /var/www -type d -exec chmod 2775 {} \;
sudo find /var/www -type f -exec chmod 664 {} \;sudo find /var/www -type d -exec chmod 2775 {} \;
sudo find /var/www -type f -exec chmod 664 {} \;Казалось бы всё должно работать! Мы всё сделали, но проблема с правами доступа сохраняется. Всё дело в том, что при создании новых файлов под пользователем, они снова будут с неправильными правами. И тут мы подошли к ключевому моменту.
4. Использование ACL для автоматического наследования прав
Чтобы новые файлы автоматически создавались с нужными правами, используем ACL:
sudo apt install acl -y sudo setfacl -d -m u:user:rwX,g:www-data:rwX /var/www
Теперь при создании файлов они сразу будут доступны и веб-серверу, и нашему пользователю.
Проверка результата
После настройки можно проверить права с помощью:
getfacl /var/www
И протестировать загрузку файлов через CMS, редактирование через SFTP и выполнение скриптов.
Проблема с правами доступа — не проблема! Заключение.
Проблемы с правами доступа на сервере без панели — частая головная боль, но их можно решить. Грамотное использование владельцев, групп и ACL позволяет добиться стабильной работы без необходимости вручную менять права после каждого обновления. Настроив систему правильно, мы избавляем себя от лишних проблем в будущем.
При таком подходе все пользователи и службы будут иметь доступ к нужным папкам и вы больше не увидите «Permisson denied», а сможете кодить в удовольствие.
Как всегда, вопросы в комментариях. Удачи!