Как исправить ошибку совместного доступа к файлу root, сбой авторизации и откат конфигурации в 1С?

При сопровождении информационных баз на платформе 1С:Предприятие 8.3 администраторы и разработчики иногда сталкиваются с пугающим сценарием: Конфигуратор внезапно выдает критическую ошибку «Ошибка совместного доступа к файлу root», при попытке входа сообщает, что «Пользователь ИБ не идентифицирован», а после повторного открытия выясняется, что конфигурация самопроизвольно откатилась на неделю или даже на месяц назад. Разберем детально, почему это происходит и как гарантированно восстановить стабильную работу системы.

Причины сбоя: от внутреннего кэша до динамических обновлений

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

1. Ошибка совместного доступа к файлу root. В структуре базы данных 1С объект root представляет собой корневой дескриптор метаданных, хранящийся в служебной таблице Config (или в ConfigSave при несохраненных изменениях). Конфликт совместного доступа возникает при коллизиях блокировок: когда рабочий процесс кластера rphost, фоновое задание или зависшая сессия Конфигуратора удерживают монопольный дескриптор в памяти либо на уровне СУБД.
2. Самопроизвольный откат конфигурации. Платформа 1С не откатывает базу сама по себе без технических оснований. В подавляющем большинстве случаев причина кроется в регулярном применении так называемого «динамического обновления» (обновления конфигурации базы данных без перезапуска сеансов пользователей). При динамическом обновлении платформа не переписывает конфигурацию полностью, а дописывает инкрементальные версии в таблицу Config. Если при очередной фиксации изменений происходит сбой совместного доступа к root, цепочка инкрементов повреждается. В итоге сервер не может собрать актуальное состояние и сбрасывает метаданные до последней корректной монопольной версии, которая применялась недели назад.
3. Ошибка «Пользователь ИБ не идентифицирован». В ряде сборок платформы (в частности, в релизе 8.3.27.1989) присутствует признанная разработчиками ошибка в механизме аутентификации. Сбой проявляется в том, что окно выбора пользователя и ввода пароля не появляется вовсе, а платформа аварийно прекращает попытку входа, теряя контекст учетной записи.

Шаг 1. Очистка кэша и принудительное завершение зависших процессов

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

1. Остановим службу сервера 1С:Предприятия (ragent). В Linux это выполняется системным менеджером служб, в Windows — через оснастку управления службами.
2. Проверим диспетчер процессов и убедимся, что процессы rphost, rmngr и ragent полностью завершили работу. Если процессы зависли, завершим их принудительно.
3. Очистим серверный кэш базы. Перейдем в рабочий каталог кластера серверов (каталог srvinfo) и удалим содержимое папок временных файлов сеансов, не затрагивая конфигурационные файлы кластера (1cv8wsrv.lst, 1cv8reg.lst) и файлы лицензий.
4. Очистим локальный кэш пользователя на машине разработчика в каталогах %LOCALAPPDATA%\1C\1cv8 и %APPDATA%\1C\1cv8. Именно старый клиентский кэш нередко пытается применить поврежденное состояние метаданных.

Шаг 2. Восстановление таблиц конфигурации на уровне СУБД

Если после очистки кэша и перезапуска службы кластера зайти в Конфигуратор не удается из-за ошибки доступа к root, обратимся к средствам СУБД (PostgreSQL или MS SQL Server). Разберем, как убрать «зависшее» промежуточное состояние обновления.

Создадим резервную копию базы данных средствами СУБД, после чего выполним очистку таблицы несохраненной конфигурации:

DELETE FROM ConfigSave;

Данная команда удаляет несохраненный черновик конфигуратора, который удерживает блокировку объекта root. Основная рабочая конфигурация при этом остается нетронутой. После очистки таблицы ConfigSave запустим Конфигуратор в монопольном режиме.

Если же повреждена основная таблица Config, загрузим эталонный файл конфигурации (.cf), созданный до сбоя, при помощи пакетного режима запуска Конфигуратора или утилиты ibcmd:

1cv8.exe DESIGNER /S "server\base" /N "Admin" /P "Pass" /LoadCfg "C:\backup\backup.cf" /UpdateDBCfg

Шаг 3. Устранение ошибки «Пользователь ИБ не идентифицирован»

Для обхода ошибки авторизации на нестабильных релизах платформы используем следующие проверенные методы:

1. Явное указание параметров в строке запуска. В настройках информационной базы в окне запуска пропишем ключи авторизации /N "ИмяПользователя" и /P "Пароль". Прямая передача параметров позволяет обойти сбойный интерфейс выбора пользователя.
2. Настройка аутентификации пользователя. Откроем список пользователей и проверим настройки учетных записей администраторов. Пользователю необходимо обязательно задать пароль в рамках аутентификации 1С:Предприятия либо перевести авторизацию на доменную учетную запись операционной системы (Windows/Kerberos). Ошибка чаще всего возникает у учетных записей с пустым паролем.
3. Использование тонкого клиента. Для пользовательской работы рекомендуется отдавать предпочтение тонкому клиенту, так как ошибка идентификации затрагивает преимущественно толстый клиент и Конфигуратор.

Шаг 4. Обновление платформы на стабильный релиз

Релиз 8.3.27.1989 содержит множество критических ошибок управления сеансами и блокировками метаданных. Единственным фундаментальным решением является переход на исправленную сборку.

Обновим серверную и клиентскую части платформы до актуальных стабильных сборок ветки: 8.3.27.2214, 8.3.27.2342 или более старших версий. В них разработчики полностью переработали стек авторизации и исправили утечки дескрипторов блокировок в рабочих процессах rphost.

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

Регламент предотвращения откатов конфигурации в будущем

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

1. Полный отказ от динамического обновления. Обновление конфигурации базы данных («накатывание изменений») на продуктивных базах должно производиться только монопольно с ключом F7 при предварительно установленной блокировке сеансов и остановленных регламентных заданиях.
2. Использование хранилища конфигурации. Ведение коллективной разработки через Хранилище конфигурации 1С защищает метаданные от локальных повреждений: даже при повреждении таблицы Config в рабочей базе актуальная версия всегда хранится в репозитории хранилища.
3. Тестирование и исправление. После ликвидации сбоя обязательно выполним в Конфигураторе регламентные процедуры: «Проверка логической целостности конфигурации» и «Реструктуризация таблиц информационной базы».