«Не удалось записать файл» в 1С-Битрикс не означает, что всему сайту нужен chmod 777. Причиной могут быть неверный владелец, запрет прохода по родительской папке, ACL, заполненный диск, read-only mount или SELinux. Массовый chown на /home/bitrix/ext_www затронет соседние сайты и может разрушить разделение доступа.
Ниже — порядок для Linux-администратора BitrixVM/BitrixEnv. Пути типовые, но пользователь PHP, DocumentRoot, версия окружения и дополнительные сайты устанавливаются по фактической конфигурации. Команды диагностики не заменяют проверку проекта; пример исправления ограничен одним каталогом данных.
1. Как определить точный сайт и процесс PHP
Запишите домен, действие и полный путь из ошибки. Сопоставьте его с конфигурацией virtual host и корнем нужного сайта. /home/bitrix/www — типовой основной корень, дополнительные площадки могут располагаться отдельно. Символические ссылки и bind mounts требуют отдельного учёта.
Посмотрите рабочие процессы:
ps -eo user,group,pid,comm,args | grep -E 'php-fpm|httpd|apache2|nginx'
ls -ld /home/bitrix/www
readlink -f /home/bitrix/wwwНе выбирайте root по master-процессу. Для PHP-FPM важны user/group рабочего pool; для Apache с PHP-модулем — рабочие процессы Apache. Nginx может читать статические файлы от другого пользователя. Имя bitrix не предполагается для произвольного хостинга.
Производитель прямо связывает режимы с устройством конкретного сервера: необходимый уровень прав. Права файловой системы и роли пользователей CMS — отдельные уровни.
2. Как читать владельца и режимы
stat -c '%A %a %U:%G %n' /home/bitrix/www/upload
namei -l /home/bitrix/www/upload/import
id bitrixПуть import приведён как пример проблемной папки. namei показывает компоненты пути: доступ к конечному файлу не поможет, если на одном из родителей отсутствует право прохода x.
Для каталога r позволяет получать имена, x — обращаться к объектам, w вместе с x — создавать и удалять записи. Для файла w разрешает изменение содержимого. Поэтому запрет записи в файл не всегда запрещает его удаление пользователю с правами на родительский каталог.
755/644 и 775/664 не являются магическими наборами. Второй вариант даёт группе запись. Нужно понимать состав группы и принадлежность процессов. 777/666 расширяют запись до любого локального пользователя и не исправляют SELinux, read-only или недостаток места.
3. Как отличить права от проблем файловой системы
df -h /home/bitrix/www
df -i /home/bitrix/www
findmnt -T /home/bitrix/www/upload
lsattr -d /home/bitrix/www/uploadСмотрите не только байты, но и inode. Для mount проверьте отсутствие неожиданного ro и правильность подключённого тома. Immutable-атрибут и ограничения сетевой файловой системы также могут препятствовать записи. Не снимайте атрибуты и не перемонтируйте том, пока не установлена причина.
Привяжите ошибку к журналу PHP/веб-сервера и времени запроса. Permission denied, No space left on device и Read-only file system требуют разных действий. HTTP 403 тоже может происходить из конфигурации web server, а не из Unix-режима.
4. Как проверить ACL и фактическое право процесса
getfacl -p /home/bitrix/www/upload/import
sudo -u bitrix test -x /home/bitrix/www/upload/import
printf 'traverse exit=%s\n' "$?"
sudo -u bitrix test -w /home/bitrix/www/upload/import
printf 'write permission exit=%s\n' "$?"Код 0 означает успешную проверку test. Она не создаёт файл и не доказывает, что реальный HTTP-запрос завершится: процессы могут иметь другой контекст или ограничения. Используйте только установленное в шаге 1 имя пользователя.
В getfacl смотрите named user/group, mask и effective. Видимое rwx может ограничиваться маской. Default ACL влияет на новые дочерние объекты. chmod может изменить ACL mask; при активной ACL сначала согласуйте её модель, а не накладывайте обычные режимы поверх.
5. Как сохранить метаданные до исправления
Для небольшого конкретного каталога используйте Linux Bash под оператором с sudo. Сначала проверьте, что цель — нужный каталог, а не symlink:
site_root=$(realpath -e /home/bitrix/www) || exit 1
[ ! -L /home/bitrix/www/upload/import ] || exit 1
target_dir=$(realpath -e /home/bitrix/www/upload/import) || exit 1
case "$target_dir" in
"$site_root"/upload/import) ;;
*) printf 'Неожиданная область изменения\n' >&2; exit 1 ;;
esac
umask 077
metadata_file="$HOME/bitrix-import-before-$(date +%Y%m%d-%H%M%S).acl"
sudo getfacl -R -P --absolute-names --numeric "$target_dir" > "$metadata_file"
[ "$?" -eq 0 ] && [ -s "$metadata_file" ] || exit 1Запускайте блок в отдельной административной Bash-сессии: exit завершит её при несоответствии. Каталог должен существовать. Проверьте содержимое снимка и его область; храните его вне публичного сайта. Рекурсивное чтение тоже создаёт нагрузку на большом дереве.
Метаданные не содержат резервную копию содержимого. Отдельно сохраните пригодную копию данных и параметры mount/SELinux. Не меняйте одновременно дерево из другой сессии: иначе снимок и исходное состояние разойдутся.
6. Как исправить конкретный каталог, не затрагивая весь сайт
Следующий вариант применим только если подтверждены все условия: это каталог импортируемых данных без исполняемых файлов, symlink и вложенных mount; правильный владелец bitrix:bitrix; отдельная ACL-модель отсутствует; для группы действительно согласована запись. Найдите исключения до выполнения:
find -P "$target_dir" -xdev -type l -print
find -P "$target_dir" -xdev -printf '%m %u:%g %p\n'Если найдены неизвестные объекты или другие владельцы, разберите их отдельно. При установленных условиях измените только каталоги и обычные файлы:
sudo find -P "$target_dir" -xdev -type d -exec chown bitrix:bitrix -- {} +
sudo find -P "$target_dir" -xdev -type f -exec chown bitrix:bitrix -- {} +
sudo find -P "$target_dir" -xdev -type d -exec chmod 0775 -- {} +
sudo find -P "$target_dir" -xdev -type f -exec chmod 0664 -- {} +Это пример ограниченной коррекции, не регламент всех BitrixVM. Он не применяется к ключам, конфигурациям с секретами, скриптам и каталогам соседних сайтов. -P не следует по найденным symlink, -xdev ограничивает переход на другую файловую систему, но bind mount на той же файловой системе требует проверки отдельно.
7. Что делать, если Unix-права правильные, а запись не работает
На системе с SELinux проверьте состояние и контекст конкретного пути:
getenforce
ls -Zd "$target_dir"
matchpathcon -V "$target_dir"
sudo ausearch -m AVC,USER_AVC -ts recentДоступность команд зависит от установленных пакетов и включённого SELinux. AVC сверьте по времени, процессу и объекту. На системе, где SELinux выключен, он не причина данного отказа. Не отключайте защиту в качестве первого решения.
Если ожидаемая политика для этого пути уже настроена, а текущая метка ей не соответствует, согласованное restorecon -v для точного объекта может вернуть контекст. Для нового нестандартного пути сначала требуется постоянная политика fcontext и проверка назначения. Не назначайте всему сайту тип, позволяющий запись, только ради одной upload-папки.
8. Почему ошибка возвращается после загрузки файлов
Установите, кто создаёт новые объекты: PHP, SFTP, deployment, cron, интеграция 1С или root-скрипт. Сопоставьте владельца нового файла с процессом. Две разные учётные записи с несогласованными группой и umask снова создадут конфликт после разового chown.
Для Битрикс существуют настройки режимов новых файлов/папок; они описаны в документации производителя. Они не исправляют владельца, права родителей и ACL, не следует добавлять константы во все конфигурации без проверки версии и действующих определений.
Согласуйте процесс публикации и обслуживания. Запуск cron от root может создавать root-файлы, но перевод существующей задачи на bitrix требует проверки её обязанностей. Не меняйте сервисную учётную запись всех заданий в рамках одной ошибки записи.
9. Как проверить исправление и закрыть лишнюю запись
Повторите stat, getfacl и проверки от фактического пользователя PHP. Затем воспроизведите исходное действие в приложении: загрузку, создание кеша или импорт. Проверьте журнал и владельца нового объекта. Успех sudo touch от root не подтверждает работу PHP.
Проверьте также чтение статического файла веб-сервером и отсутствие записи у лишних пользователей. Убедитесь, что секретные конфигурации не попали в общедоступные права. Для upload отдельно проверьте запрет исполнения загруженных скриптов в конфигурации сайта: chmod не является таким запретом.
CMS-ошибка доступа пользователя решается её ролью и группами. Права Bitrix Framework не следует заменять выдачей Unix-записи всем.
10. Как вернуть метаданные и оформить результат
Если изменение не дало нужного результата, а дерево и исходные объекты сохранились, сначала просмотрите восстановление без применения:
sudo setfacl --test --restore="$metadata_file"После проверки области и отсутствия новых конкурентных изменений:
sudo setfacl --restore="$metadata_file"Восстановление по setfacl может вернуть сохранённые ACL, режимы и владельцев с достаточными полномочиями. Оно не восстанавливает содержимое, удалённые объекты и SELinux-контекст; новые файлы требуют отдельного решения.
Зафиксируйте причину, каталог, пользователя процесса, режим до/после, тест приложения и способ предотвращения повторения. Для диагностики BitrixVM и настройки эксплуатации сайта обратитесь в АВАНГАРД ИТ.