Проверка доступности файлов ядра

При работе модулей на сайте 1С-Битрикс могут возникать ситуации, когда файлы ядра становятся недоступны для чтения или записи веб-сервером. Это приводит к различным сбоям в работе сайта и модулей. В этой статье разберём, как диагностировать и устранить проблему.

Признаки нарушения доступности файлов

Обратите внимание на следующие симптомы — они могут указывать на проблемы с правами доступа к файлам ядра:

• Не сохраняются настройки модуля. Вы изменяете настройки в административной панели, нажимаете "Сохранить", но изменения не применяются или сбрасываются.
• Остановился обмен данными. Агенты модуля перестали выполняться, обмен заказами или товарами с МоимСкладом не происходит, хотя агенты активны и cron настроен корректно.
• Ошибки при работе с кешем. Сайт начинает работать нестабильно, отдельные страницы или компоненты перестают корректно обновляться.

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

Как проверить доступность файлов

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

Настройки → Инструменты → Проверка системы → вкладка Проверка доступа

На этой странице выберите вариант Проверка ядра и нажмите кнопку Проверить.

Если все файлы ядра доступны — система сообщит об этом. Если же обнаружены проблемные файлы, они будут перечислены в списке с пометкой "Недоступны для чтения или записи".

Обратите внимание на пути файлов в списке. Если среди них встречаются:

• файлы модулей (например, /rbs.moysklad/...)
• файлы кеша (например, /bitrix/cache/... или /bitrix/managed_cache/...)
• файлы логов модулей

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

Причины возникновения проблемы

Наиболее частая причина — cron-скрипты запускаются от имени пользователя root, а не от пользователя веб-сервера (например, www-data, bitrix, apache).

Когда cron-задание выполняется от root, все создаваемые файлы (кеш, логи, временные файлы) получают владельца root. Веб-сервер, работающий от другого пользователя, не может прочитать или изменить эти файлы — и возникает конфликт прав.

Это касается:

• Скрипта агентов cron_events.php — если он добавлен в crontab пользователя root.
• Скрипта run_all.php модуля товаров — если установлен модуль товаров и скрипт запуска агентов модуля также добавлен в crontab root.

Ещё одна распространённая причина — файлы сайта были загружены на сервер от имени пользователя root (например, при ручном копировании, переносе сайта или распаковке архива). В этом случае сами файлы модулей уже имеют неверного владельца. Когда агенты обращаются к таким файлам, они создают кеш и логи, которые также получают неправильные права — и проблема распространяется дальше.

Как исправить проблему

1. Исправить пользователя для cron-скриптов

В первую очередь необходимо убедиться, что все cron-скрипты запускаются от имени пользователя веб-сервера, а не от root. Обратитесь к вашему хостинг-провайдеру и попросите проверить:

• От какого пользователя запускаются cron-задания на сервере.
• Что скрипт агентов cron_events.php выполняется от того же пользователя, от которого работает веб-сервер.
• Если установлен модуль товаров и скрипт run_all.php также добавлен в cron — он тоже должен запускаться от пользователя веб-сервера.

2. Исправить владельца файлов сайта

Если файлы сайта были загружены на сервер от имени root или другого пользователя — необходимо сменить владельца всех файлов сайта на пользователя веб-сервера. Обратитесь к хостинг-провайдеру и попросите рекурсивно сменить владельца файлов в директории сайта на корректного пользователя.

3. Удалить проблемные файлы и кеш

Этот шаг актуален, если второй пункт был пропущен (проблема была только в cron) или же были точечно исправлены права у отдельных файлов, но кеш, созданный с неверными правами, всё ещё остаётся на сервере.

к сведению

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

Через административную панель Битрикс очистить такой кеш не получится, так как у веб-сервера нет доступа к этим файлам. Используйте SSH, SFTP или файловый менеджер панели хостинга.

Необходимо очистить содержимое следующих директорий относительно корня сайта:

• /bitrix/cache/
• /bitrix/managed_cache/
• /bitrix/stack_cache/

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

После удаления кеш будет автоматически пересоздан при обращениях к сайту — уже с корректными правами.

4. Повторная проверка ядра

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

Необходимо исправить абсолютно все файлы, отображаемые в результатах проверки. Если после первой очистки всё ещё остаются проблемные файлы — повторите удаление кеша и проблемных файлов, затем снова запустите проверку.

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

Совет

После устранения проблемы рекомендуется проверить работу модулей: убедитесь, что настройки сохраняются корректно и обмен данными возобновился.