Права на файлы в 1С-Битрикс: почему не пишется upload или cache

После переноса сайта, ручного деплоя, распаковки архива или восстановления из бэкапа 1С-Битрикс часто начинает вести себя странно: не загружаются файлы, не очищается кэш, не создаются миниатюры, не пишутся логи, не работает композит. Во многих случаях причина простая — права на файлы и директории.

Самое опасное решение — поставить chmod 777 на весь проект. Это быстро маскирует проблему, но создаёт риск безопасности. Лучше понять, какой пользователь запускает PHP и какие директории должны быть доступны на запись.

Какие директории должны писаться

Битрикс регулярно пишет во временные и рабочие директории. Минимально нужно проверить:

• upload;
• bitrix/cache;
• bitrix/managed_cache;
• bitrix/stack_cache;
• bitrix/html_pages;
• local/logs, если используется;
• временные директории, заданные в настройках PHP.

ls -la upload
ls -la bitrix/cache
ls -la bitrix/managed_cache
ls -la bitrix/stack_cache
ls -la bitrix/html_pages

Понять пользователя PHP

Права нужно выдавать не абстрактно, а под конкретного пользователя. PHP-FPM может работать от www-data, nginx, apache или пользователя сайта.

ps aux | grep php-fpm
ps aux | grep nginx

На хостингах пользователь часто совпадает с владельцем аккаунта. На VPS это зависит от настройки пула PHP-FPM.

Проверить путь целиком

Иногда права нормальные на самой папке upload, но нет права прохода по родительской директории. Для этого удобно использовать namei.

namei -l /var/www/site.ru/upload

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

Настроить владельца и группу

Один из рабочих подходов — сделать владельцем проекта пользователя деплоя, а группу дать веб-серверу. Для writable-директорий дать группе право записи.

chown -R deploy: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 {} \;

chmod -R g+rw upload bitrix/cache bitrix/managed_cache bitrix/stack_cache bitrix/html_pages

Это пример, а не универсальная команда. На конкретном сервере имена пользователей и групп нужно проверить.

Проблемы после cron

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

crontab -l
ls -la bitrix/cache | head

Cron лучше запускать от того же пользователя, что и сайт, или аккуратно настроить общую группу.

Файлы, созданные root

После ручных команд от root часто появляются файлы, которые веб-сервер не может изменить. Например, кэш очистили от root, а потом новые директории создались с неправильным владельцем.

find upload bitrix/cache bitrix/managed_cache -user root | head

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

Логи ошибок

Ошибки прав обычно видны в PHP error log или nginx error log. Ищите Permission denied, failed to open stream, mkdir, fopen, unlink.

tail -n 150 /var/log/nginx/error.log
tail -n 150 /var/log/php-fpm/error.log

Если лог Битрикс не пишется, возможно, проблема прав мешает даже логированию. Тогда серверные логи особенно важны.

Чек-лист

1. Проверить upload и кэш-директории.
2. Понять пользователя PHP-FPM.
3. Проверить путь через namei -l.
4. Проверить файлы, созданные root.
5. Проверить пользователя cron.
6. Настроить владельца и группу без chmod 777 на весь проект.
7. Проверить загрузку файла через админку.
8. Проверить очистку кэша и создание новых файлов.

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