Как правильно настроить права на файлы сайта в Linux: chmod, chown и 1С-Битрикс

После переноса сайта на новый сервер, восстановления из резервной копии или ручной загрузки файлов можно столкнуться с ошибками: сайт открывается, но изображения не загружаются, кеш не создаётся, обновления CMS завершаются ошибкой, а в журнале появляется Permission denied.

Частая причина таких проблем — неправильно настроенные права на файлы сайта в Linux, владелец файлов или пользователь, от которого работает PHP-FPM.

Разберём, как работают chmod и chown, что означают популярные права 755 и 644, как определить пользователя PHP-FPM и какие права на файлы обычно нужны 1С-Битрикс.

Хотя основной пример в статье — 1С-Битрикс, те же принципы подходят для WordPress, Joomla, Drupal, MODX, Laravel и большинства других PHP-сайтов.

Как работают права на файлы сайта в Linux

У каждого файла и каталога в Linux есть:

• владелец;
• группа;
• права владельца;
• права группы;
• права остальных пользователей.

Посмотреть текущие права можно командой:

ls -la /var/www/site.ru

Например:

drwxr-xr-x  8 www-data www-data 4096 Oct 7 12:00 .
-rw-r--r--  1 www-data www-data  250 Oct 7 12:00 index.php

В данном примере:

www-data www-data

— владелец и группа файла.

А права:

-rw-r--r--

соответствуют значению 644.

Что означают chmod 755 и 644

Для большинства сайтов базовой отправной точкой являются следующие права:

Для каталогов:

755

Для файлов:

644

При 755 владелец каталога может читать, изменять его содержимое и переходить внутрь, а остальные пользователи могут читать каталог и переходить в него.

При 644 владелец файла может читать и изменять его, а остальные пользователи — только читать.

Установить права 755 на каталоги и 644 на файлы можно так:

find /var/www/site.ru -type d -exec chmod 755 {} \;
find /var/www/site.ru -type f -exec chmod 644 {} \;

Однако правильный chmod — это только часть настройки. Нужно учитывать владельца файлов и пользователя PHP-FPM.

Как определить пользователя PHP-FPM

На Debian и Ubuntu PHP-FPM часто работает от пользователя:

www-data

Но на конкретном сервере настройки могут отличаться.

Посмотреть работающие процессы PHP-FPM можно командой:

ps aux | grep php-fpm

Также можно посмотреть настройки пулов:

grep -R "^user\|^group" /etc/php/*/fpm/pool.d/

Например:

user = www-data
group = www-data

Это означает, что PHP-код сайта выполняется от пользователя www-data.

Именно этот пользователь должен иметь возможность записывать данные в каталоги, используемые CMS для кеша, загрузок, обновлений и временных файлов.

Как использовать chown для сайта

Команда chmod изменяет права, а chown — владельца и группу файла.

Если PHP работает от пользователя www-data и эта схема подходит для сервера, владельца сайта можно назначить так:

chown -R www-data:www-data /var/www/site.ru

Затем выставить стандартные права:

find /var/www/site.ru -type d -exec chmod 755 {} \;
find /var/www/site.ru -type f -exec chmod 644 {} \;

Такой вариант часто используется на небольших серверах, где файлы сайта в основном изменяются самой CMS.

Схема прав для разработчика и www-data

Если разработчик регулярно работает с сайтом по SSH, назначать владельцем всех файлов www-data может быть неудобно.

В этом случае можно использовать отдельного пользователя и общую группу.

Допустим, разработчик работает под пользователем:

webmaster

а PHP-FPM — под:

www-data

Добавим пользователя в группу:

usermod -aG www-data webmaster

Затем назначим владельца и группу:

chown -R webmaster:www-data /var/www/site.ru

И при необходимости разрешим запись владельцу и группе:

find /var/www/site.ru -type d -exec chmod 775 {} \;
find /var/www/site.ru -type f -exec chmod 664 {} \;

После добавления пользователя в группу нужно заново войти в SSH-сессию.

Зачем использовать chmod 2775

При совместной работе разработчика и PHP может возникнуть ситуация, когда новые каталоги создаются с другой группой.

Чтобы новые объекты наследовали группу родительского каталога, можно использовать setgid:

chmod 2775 /var/www/site.ru

Для дерева каталогов:

find /var/www/site.ru -type d -exec chmod 2775 {} \;

Это удобно на серверах, где с файлами одновременно работают PHP и пользователь для разработки или деплоя. При этом необходимо учитывать настройки umask.

Какие права на файлы нужны 1С-Битрикс

Права на файлы Битрикс должны позволять PHP выполнять операции, необходимые системе: создавать кеш, загружать документы и изображения, формировать временные файлы, устанавливать обновления и создавать резервные копии.

Запись обычно требуется как минимум в каталог:

/upload/

а также в каталоги кеша:

/bitrix/cache/
/bitrix/managed_cache/
/bitrix/stack_cache/

В зависимости от конфигурации сайта могут использоваться:

/bitrix/html_pages/
/bitrix/backup/

и другие служебные каталоги.

Если проект использует структуру /local/, отдельные операции также могут потребовать возможности записи в неё.

Проверить владельца и права можно командами:

ls -ld /var/www/site.ru/upload
ls -ld /var/www/site.ru/bitrix/cache
ls -ld /var/www/site.ru/bitrix/managed_cache

Permission denied в Битрикс: что проверить

Ошибка Permission denied в 1С-Битрикс не означает, что нужно сразу устанавливать права 777.

Сначала стоит проверить:

• от какого пользователя работает PHP-FPM;
• кому принадлежат файлы сайта;
• какая группа назначена каталогам;
• есть ли у PHP право записи в нужный каталог;
• не были ли файлы распакованы под root;
• не используются ли дополнительные ограничения ACL, SELinux или AppArmor.

Очень часто проблема решается правильным chown, а не расширением прав для всех пользователей системы.

Почему обновления 1С-Битрикс могут не работать

Если обновление запускается через административную панель 1С-Битрикс, операции с файлами выполняет PHP.

Предположим, файлы имеют:

файлы: 644
каталоги: 755
владелец: root

а PHP работает как:

www-data

Сайт может нормально открываться, потому что PHP имеет право читать файлы, но изменить их при обновлении он уже не сможет.

Поэтому при выборе владельца необходимо учитывать не только обычную работу сайта, но и способ установки обновлений.

Почему не стоит ставить chmod 777

При ошибках доступа в интернете часто встречается совет:

chmod -R 777 /var/www/site.ru

Для рабочего сайта использовать такую команду не стоит.

Права 777 позволяют всем пользователям системы читать, изменять и выполнять файлы или каталоги.

Кроме того, использование chmod -R 777 устанавливает одинаковые права и файлам, и каталогам, хотя обычным PHP-, CSS- и JavaScript-файлам право выполнения не требуется.

Если сайт работает только после chmod 777, это сигнал, что нужно найти настоящую причину ошибки доступа.

Почему chmod -R 755 тоже не лучший вариант

Ещё одна распространённая команда:

chmod -R 755 /var/www/site.ru

Она значительно безопаснее 777, но также устанавливает одинаковые права всем объектам.

В результате обычные файлы:

index.php
style.css
script.js

получают флаг выполнения, который им обычно не нужен.

Корректнее разделить файлы и каталоги:

find /var/www/site.ru -type d -exec chmod 755 {} \;
find /var/www/site.ru -type f -exec chmod 644 {} \;

Как проверить владельца файлов сайта

Посмотреть владельца корневого каталога:

ls -ld /var/www/site.ru

Для более подробной проверки:

find /var/www/site.ru -maxdepth 2 -printf '%M %u %g %p\n' | head -50

Так можно быстро обнаружить ситуацию, когда одни файлы принадлежат root, другие — www-data, а третьи — пользователю, который загружал сайт.

Подобная смесь владельцев особенно часто появляется после переноса сайта между серверами.

Проблема после распаковки сайта под root

Рассмотрим распространённый случай:

root@server:/var/www# unzip backup.zip

После распаковки файлы могут принадлежать:

root:root

Nginx и PHP смогут их читать, поэтому сайт откроется. Но запись в каталог, например:

/var/www/site.ru/upload/

может оказаться недоступной для www-data.

Результатом могут стать ошибки загрузки изображений, создания кеша или обновления сайта.

В зависимости от выбранной схемы исправление может выглядеть так:

chown -R www-data:www-data /var/www/site.ru

или через отдельного пользователя и общую группу.

Nginx и PHP-FPM могут работать от разных пользователей

Важно различать пользователя nginx и пользователя PHP-FPM.

Nginx обычно достаточно читать файлы сайта, а большинство операций записи выполняет PHP.

Посмотреть процессы nginx:

ps aux | grep nginx

Посмотреть PHP-FPM:

ps aux | grep php-fpm

Если они работают от разных пользователей — это совершенно нормальная ситуация.

При ошибках записи в CMS в первую очередь следует проверять пользователя PHP-FPM.

Права на файлы WordPress и других CMS

Описанный принцип подходит не только для Битрикс.

Практически любой PHP-сайт работает по похожей схеме:

nginx / Apache
       ↓
PHP-FPM
       ↓
файлы сайта

Различаются в основном каталоги, в которые приложение должно иметь возможность записывать данные.

Например, WordPress использует:

/wp-content/uploads/

а при установке плагинов и обновлений может работать с:

/wp-content/plugins/
/wp-content/themes/

Laravel требуется запись как минимум в:

/storage/
/bootstrap/cache/

У 1С-Битрикс — свои директории кеша, загрузок и системных файлов.

Поэтому конкретные каталоги отличаются, но общий принцип один: PHP должен иметь право записи только там, где это действительно необходимо приложению.

Базовые права для Debian, nginx и PHP-FPM

Если PHP работает от пользователя www-data и такая схема подходит для проекта, базовая настройка может выглядеть так:

chown -R www-data:www-data /var/www/site.ru

find /var/www/site.ru -type d -exec chmod 755 {} \;
find /var/www/site.ru -type f -exec chmod 644 {} \;

После изменения прав необходимо проверить:

• загрузку изображений и документов;
• создание кеша;
• работу административной панели;
• обновление CMS;
• создание резервной копии;
• работу временных файлов.

Если используется отдельный пользователь для разработки или деплоя, лучше построить схему через группы или ACL, а не использовать 777.

Какие права поставить на сайт: краткий итог

Для большинства PHP-сайтов хорошей отправной точкой являются:

каталоги — 755
файлы — 644

Но сами значения 755 и 644 не решают вопрос полностью.

Главное — определить, какой пользователь должен иметь возможность изменять файлы сайта.

На сервере с PHP-FPM это обычно пользователь пула PHP, например www-data, либо группа, которой предоставлены необходимые права.

Поэтому перед изменением chmod или chown полезно выполнить:

ls -ld /var/www/site.ru
ps aux | grep php-fpm

Это позволяет настроить права осознанно, вместо того чтобы пытаться решить ошибку Permission denied небезопасным chmod 777.