#Признаки проблемы и применимость
«Проверка системы» Битрикс сообщает об ошибке доступа к файлам или каталогам. Причина может быть в владельце файла, группе процесса PHP, режиме доступа или запрете файловой системы, а не в том, что всем файлам якобы нужны права 777.
#Причины и отличительные признаки
| Возможная причина | Как узнать | Что делать |
|---|---|---|
| Разные владельцы после переносаРазные владельцы после переноса. Часть файлов создана root, а веб-процесс не может писать | Часть файлов создана root, а веб-процесс не может писать | Уточнить владельца только проблемных объектов |
| PHP-FPM работает под другим пользователемPHP-FPM работает под другим пользователем. Один пул пишет файл, другой получает Permission denied | Один пул пишет файл, другой получает Permission denied | Сопоставить пользователя пула и каталога |
| Каталог/диск недоступенКаталог/диск недоступен. Read-only filesystem, квота или закончился inode | Read-only filesystem, квота или закончился inode | Проверить диск, монтирование и квоты |
#Пошаговая диагностика и исправление
- Запустите штатную проверкуАвторизуйтесь администратором Битрикс → «Настройки» → «Инструменты» → «Проверка системы». Откройте раздел проверки доступа к диску и запустите выбранный режим: сначала папку загрузок или ядро, затем полный при необходимости. Скопируйте конкретный путь и тип отказа.
- Определите пользователя PHPВ панели хостинга откройте настройки домена/пула PHP-FPM и запишите служебного пользователя, под которым обрабатываются запросы. Пользователь SSH и процесса PHP могут различаться. Не выполняйте команды chown только по имени владельца с экрана без проверки.
- Посмотрите права ровно проблемного каталогаЧерез SSH выполните команду для пути из отчёта; просмотрите владельца, группу и разрешения каталога, не меняя их. Для доступа к файлу требуются права прохода по родительским каталогам, не только запись в сам файл.
- На Linux с установленной утилитой namei; подставьте настоящий путьLinux · Терминал (Bash)КомандаНа Linux с установленной утилитой namei; подставьте настоящий путь.
namei -l /полный/путь/к/проблемному/каталогу
- Исключите заполнение разделаНа Linux через SSH посмотрите свободное место и inode; при исчерпании места запись невозможна даже при правильных разрешениях. Квоты пользователя уточняйте у хостинга. Ничего не удаляйте до определения владельца файлов.
- Только чтение показателей; не проверяет пользовательские квотыLinux · Терминал (Bash)КомандаТолько чтение показателей; не проверяет пользовательские квоты.
df -h; df -i
- Проверьте политику безопасности и монтированиеЕсли права выглядят корректными, журнал Linux может содержать отказ SELinux/AppArmor, а файловая система может быть смонтирована read-only. Передайте сообщение администратору; обход политик защиты или отключение SELinux не является безопасным решением.
- Исправьте конкретный объект после резервной копииУстановите владельца и права только проблемному каталогу с учётом модели разделения сайтов, согласуйте операцию с хостером. Избегайте chown -R всего сайта и chmod -R 777: это даёт возможность посторонним процессам изменять код.
- Повторите проверку и штатную операциюЗапустите тот же пункт «Проверки системы» и попробуйте загрузить маленький тестовый файл или создать копию страницы в защищённой зоне. Должны исчезнуть конкретные ошибки доступа. Если веб-процесс стал писать в каталоги кода без необходимости, верните исходные права.
#Проверка результата
Проверка выбранного пути проходит, запись туда доступна только ожидаемому служебному пользователю, другие сайты и файлы ядра не получили лишних прав.
#Что делать, если не помогло
Если всё ещё Permission denied, проверьте родительские директории, ACL, SELinux/AppArmor и владельца сокета. Не отключайте защиту и не расширяйте права всего дерева.