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

Почему возникает ошибка

Архив мог быть распакован от имени root или другого системного пользователя. Тогда PHP, запущенный от bitrix, www-data либо пользователя пула PHP‑FPM, не получает права на запись.

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

Сначала определите реальную конфигурацию

Перейдите в корень нужного сайта и проверьте текущего владельца, группу и пользователя веб‑процесса:

pwd
ls -la
ps aux | grep -E 'php-fpm|httpd|apache2'
namei -l /home/bitrix/www

На классической BitrixVM владельцем проекта часто является bitrix:bitrix, но это не универсальное правило. На хостинге, в контейнере или при нескольких пулах PHP‑FPM имя будет другим.

Не запускайте команды из чужой инструкции вслепую. Ошибка в текущем каталоге или владельце может изменить права не того проекта и нарушить работу соседних сайтов.

Команды из оригинальной статьи

В сохранённой версии 2021 года предлагалось перейти в корень сайта и выполнить:

find . -type d -exec chmod 775 {} \;
find . -type f -exec chmod 664 {} \;
find . -type d -exec chown bitrix:bitrix {} \;
find . -type f -exec chown bitrix:bitrix {} \;

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

Безопаснее сначала посмотреть будущий охват без изменения файлов:

find . -type d | head -50
find . -type f | head -50
find . ! -user bitrix -ls | head -100

Если используются ACL, разные владельцы каталогов или read‑only‑части, массовый chown может быть неправильным решением. В BitrixVM предпочтительно использовать штатные операции управления правами, когда они доступны.

Как проверить результат

  1. Повторите действие, которое вызывало ошибку.
  2. Запустите «Проверку системы» в административной панели.
  3. Проверьте журналы Nginx, Apache и PHP‑FPM.
  4. Убедитесь, что новые файлы создаются с ожидаемым владельцем и маской.
  5. Удалите тестовые файлы и очистите управляемый кеш средствами Битрикса.

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