Bitrix Permission denied: как найти причину ошибки прав доступа

Ошибка Permission denied в 1С-Битрикс обычно означает, что процесс, выполняющий операцию, не получил необходимого доступа к файлу или каталогу.

Но здесь важно сразу разделить две совершенно разные ситуации.

Первая — Linux или другая серверная система запрещает PHP или веб-серверу читать, создавать, изменять или удалять физический файл.

Вторая — сама система прав 1С-Битрикс запрещает конкретному пользователю работать с файлом или разделом сайта.

Внешне проблемы могут быть похожи, но исправляются они по-разному.

Поэтому начинать с массового chmod 777 — плохая диагностика.

Сначала нужно определить, кто именно получил Permission denied и к какому объекту не удалось обратиться.

Сначала сохраните полный текст ошибки

Если сообщение выводится PHP, журналом веб-сервера или самим приложением, сохраните его полностью.

Особенно важен путь к файлу или каталогу.

Например:

Permission denied

само по себе говорит мало.

Гораздо полезнее сообщение, из которого видно, что ошибка возникает при обращении к определённому пути:

/home/site/www/upload/...

или:

/var/www/site/bitrix/cache/...

Тогда уже можно выяснять, кто является владельцем этого объекта и какой процесс пытается с ним работать.

Не меняйте права сразу на весь сайт.

Определите: это системные права или права самого Битрикс

У Bitrix Framework существует собственная система разграничения доступа к файлам и каталогам.

Права могут задаваться для групп пользователей и наследоваться от вышележащих каталогов. Для них используются уровни вроде чтения, записи и полного доступа. В административной части эти права можно управлять через файловый менеджер.

Но такие права не заменяют Unix-права файловой системы.

Если Linux не разрешает PHP открыть или изменить физический файл, выдача администратору «Полного доступа» внутри Bitrix эту проблему не устранит.

И наоборот: если физические права корректны, но пользователь Bitrix не имеет права записи в разделе, изменение chmod на сервере не является правильным решением.

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

Если ошибка возникает при записи файла

Характерный сценарий:

файл существует и сайт его читает, но Bitrix не может его изменить или перезаписать.

Такое бывает после:

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

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

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

Проверьте владельца файла

На Linux-сервере посмотрите фактические права и владельца проблемного объекта.

Например:

ls -l /путь/к/файлу

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

ls -ld /путь/к/каталогу

Важно увидеть:

owner
group
permissions

После этого нужно определить, от какого пользователя выполняется PHP или веб-сервер.

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

Просто изменить цифры прав, не понимая владельца, недостаточно.

Частая проблема после переноса сайта

После переноса файлы могут оказаться принадлежащими другому пользователю.

Например, старый сервер создавал их от одного account, резервная копия была восстановлена через root, а PHP на новом сервере работает от отдельного пользователя сайта.

Внешне всё может выглядеть нормально:

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

Но позже возникают ошибки при попытке:

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

Это хороший признак того, что нужно проверять конкретные каталоги записи, а не исправлять весь Bitrix целиком.

Не ставьте 777 автоматически

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

Это не нормальная универсальная настройка для исправления Permission denied.

Bitrix позволяет задавать права для создаваемых системой файлов и каталогов через константы:

BX_FILE_PERMISSIONS
BX_DIR_PERMISSIONS

В официальной документации приводится пример их определения через dbconn.php.

Но конкретные значения должны соответствовать архитектуре сервера.

Нельзя взять права из чужой инструкции и считать, что они автоматически правильны для Nginx, Apache, PHP-FPM, shared hosting и BitrixVM одновременно.

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

Если новые файлы снова создаются с неправильными правами

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

Например:

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

Тогда проверять нужно не только существующие объекты, но и с какими правами Bitrix создаёт новые файлы и каталоги.

Bitrix использует BX_FILE_PERMISSIONS и BX_DIR_PERMISSIONS при создании файлов и каталогов в соответствующих операциях. В документации также описана функция CheckDirPath, использующая настройки прав при создании каталогов.

То есть одноразовый рекурсивный chmod может убрать симптом, но не причину.

Если ошибка появилась после загрузки файлов по FTP

Это один из самых понятных диагностических сценариев.

FTP-пользователь загрузил файлы.

После этого:

FTP
↓
новый owner/group
↓
PHP пытается изменить файл
↓
Permission denied

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

Поэтому, если проблема появилась после FTP-загрузки, сначала сравните владельца проблемного файла с файлом, который Bitrix создал самостоятельно.

Разница часто сразу показывает причину.

Если не записывается каталог upload

Каталог загрузок должен позволять приложению создавать и изменять необходимые файлы.

Если ошибка появляется при:

загрузке изображения, прикреплении документа, импорте файла или сохранении нового медиаобъекта,

проверьте конкретный каталог, куда Bitrix пытается записать данные.

Не нужно сразу давать запись всему корню сайта.

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

Если проблема связана с кешем

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

Сайт при этом может:

выдавать PHP warnings, работать нестабильно, не обновлять изменения или ломаться только на определённых действиях.

Снова важно смотреть фактический путь из ошибки.

Если сообщение указывает на каталог кеша, сначала проверьте владельца, группу и доступ именно к нему.

Не отключайте кеш только для того, чтобы скрыть Permission denied.

Если Permission denied возникает в административной части

Тогда сначала определите, что именно запрещено.

Если Bitrix показывает собственное сообщение о недостаточных правах пользователя, это может быть прикладная система доступа.

В Bitrix права на файлы и каталоги могут задаваться по группам и наследоваться. Среди уровней доступа существуют запрет, чтение, запись и полный доступ.

То есть пользователь может видеть файл, но не иметь права изменить его.

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

Не меняйте Unix permissions, если сервер вообще не выдаёт системную ошибку записи.

Проверьте наследование прав Bitrix

Прикладные права могут наследоваться от родительского каталога.

Поэтому пользователь иногда получает запрет не потому, что для конкретного файла настроено неправильное правило, а потому, что право пришло сверху.

Официальная документация Bitrix указывает, что при отсутствии явно заданного уровня используется право вышележащего каталога.

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

Иначе можно получить набор противоречивых локальных настроек доступа.

Не путайте .access.php с chmod

Bitrix может использовать .access.php для своих прав доступа к файлам и каталогам. В этих файлах задаются права групп пользователей приложения.

Это не Unix chmod.

Условно:

.access.php

отвечает за то, что разрешено пользователю внутри логики Bitrix,

а:

owner / group / chmod

определяют, что разрешает операционная система процессу PHP или веб-сервера.

При Permission denied нужно понять, какой именно уровень сейчас отказал.

Если Bitrix не может изменить права сам

Есть ещё одна важная ситуация.

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

Официальные материалы Bitrix отдельно предупреждают: если файл нельзя изменить из самой системы из-за физических прав, попытка выполнить ту же операцию другим PHP-скриптом не обязательно поможет — может потребоваться доступ через FTP или SSH от пользователя, имеющего необходимые права.

То есть нельзя исправить любой конфликт ownership просто ещё одним PHP-файлом в корне сайта.

Если Permission denied появился после восстановления backup

После восстановления сравните:

кто владеет восстановленными файлами, кто владеет новыми файлами, создаваемыми сайтом, и от какого пользователя работает PHP.

Если эти значения отличаются, проблема может распространяться только на восстановленную часть сайта.

Это значительно безопаснее диагностировать выборочно, чем запускать рекурсивную смену прав на всём DocumentRoot.

Если ошибка появилась после обновления

Сначала посмотрите, какой файл или каталог не удалось изменить.

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

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

Не стоит обходить это массовым 777.

Нужно привести ownership и модель доступа сайта к согласованной конфигурации.

В чём разница между владельцем и правами

Это часто упускают.

У файла может быть режим:

0644

но этого недостаточно, чтобы сказать, сможет ли конкретный PHP-процесс его изменить.

Нужно знать, кем является процесс относительно файла:

владельцем, членом группы или «остальным» пользователем.

Поэтому правильная диагностика рассматривает вместе:

владелец + группа + mode + пользователь PHP

а не только последние три цифры из FTP-клиента.

Короткий порядок диагностики

При bitrix permission denied проверяйте в такой последовательности:

1. сохранить полный текст ошибки и путь;
2. определить, это физический отказ ОС или прикладные права Bitrix;
3. проверить owner, group и permissions проблемного файла или каталога;
4. определить пользователя PHP/веб-сервера;
5. вспомнить, как появились проблемные файлы — Bitrix, FTP, backup, перенос;
6. сравнить их с нормально работающим файлом;
7. проверить права только нужного каталога;
8. если проблема внутри Bitrix — проверить группы и наследование;
9. проверить настройки прав для вновь создаваемых файлов;
10. исправить реальную причину;
11. повторить исходную операцию;
12. убедиться, что новые файлы создаются правильно.

Так можно убрать не только текущую ошибку, но и причину её повторного появления.

Чего не стоит делать

Не стоит сразу запускать рекурсивный chmod 777 по всему сайту, менять владельца всего сервера наугад, удалять .access.php, выдавать всем группам Bitrix полный доступ или менять одновременно права, PHP и конфигурацию веб-сервера.

Permission denied — это как раз тот случай, где точный путь и конкретный пользователь процесса обычно важнее любых универсальных таблиц chmod.