← На главную

Перенос журнала регистрации 1С на новый сервер или в другую базу данных — стандартная задача для системного администратора и программиста 1С. Однако в процессе её выполнения часто возникает неприятная ошибка: «Доступ к файлу 1Cv8.lgf запрещён - 5(0x00000005): Access is denied». Эта проблема блокирует запуск информационной базы и парализует работу пользователей.

В этой статье мы подробно разберем, почему возникает данная неполадка, проанализируем популярные решения с технических форумов, выясним причины небезопасности некоторых из них и по шагам настроим корректные права доступа. Также мы рассмотрим особенности работы со старым текстовым форматом логов .lgf и современным форматом базы данных SQLite .lgd.

Выясняем причину: почему операционная система блокирует доступ?

Ошибка с кодом 5 (0x00000005) в операционной системе Windows всегда однозначно указывает на проблему с правами доступа (NTFS Permissions). Когда мы вручную копируем файлы журнала регистрации из каталога одной базы в каталог другой (особенно если файлы переносятся между разными серверами), операционная система выполняет следующие действия:

1. Перенос владельца файла: Файлы получают в качестве владельца ту учетную запись, под которой администратор выполнял копирование.
2. Сброс или сохранение прав (ACL): В зависимости от метода копирования файлы либо сохраняют старые разрешения исходного сервера, либо наследуют права родительской папки нового сервера, которые могут не соответствовать требованиям службы 1С.

В это же время сервер приложений «1С:Предприятие» функционирует как системная служба. По умолчанию в Windows она запускается от имени специального локального пользователя — USR1CV8 (или аналогичного, например, USR1CV83, в зависимости от версии платформы). Когда служба пытается прочитать или записать данные в перенесенный файл 1Cv8.lgf, операционная система видит, что у пользователя USR1CV8 нет прав на этот файл, и возвращает ошибку Access is denied.

Критика простого решения: почему нельзя давать доступ группе «Все»?

На многих форумах, включая приведенный в начале статьи диалог, быстрым решением называют предоставление полного доступа (Full Control) группе «Все» (Everyone) на папку с базой данных или файлами логов. Рассмотрим подробнее, почему это решение крайне опасно:

• Нарушение конфиденциальности: Журнал регистрации содержит информацию обо всех действиях пользователей, изменениях данных, попытках авторизации и ошибках системы. Давая доступ группе «Все», вы позволяете любому пользователю сети или локальному пользователю сервера прочитать эти конфиденциальные данные.
• Угроза целостности данных: Любой неавторизованный процесс или злоумышленник сможет беспрепятственно удалить файлы журнала регистрации или внести в них изменения, скрывая следы несанкционированных действий в программе 1С.
• Противоречие регламентам безопасности: В крупных компаниях и государственных учреждениях использование группы «Все» для критически важных каталогов является грубым нарушением стандартов информационной безопасности (например, ISO 27001).

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

Различие форматов журнала регистрации: .lgf против .lgd

Перед тем как приступать к переносу логов, проанализируем, в каком формате хранится ваш журнал регистрации. Платформа 1С:Предприятие поддерживает два формата хранения:

1. Текстовый формат (.lgf и .log): Исторический формат, использовавшийся по умолчанию до версии 8.3.5. Данные пишутся в текстовые файлы последовательно.

   При переносе такого журнала в файле 1Cv8.lgf обязательно требуется отредактировать уникальный идентификатор (UID) информационной базы, заменив его на актуальный UID новой базы данных, иначе связь с метаданными будет нарушена.

2. Формат базы данных SQLite (.lgd): Современный формат, применяемый по умолчанию в новых версиях платформы. Все записи хранятся в едином файле базы данных SQLite.

   Важное предупреждение: Категорически запрещено копировать файл 1Cv8.lgd «на горячую» при работающей службе сервера 1С. Это гарантированно приведет к блокировкам транзакций и повреждению структуры файла логов с ошибкой database disk image is malformed. Для этого формата редактировать UID вручную внутри файла не требуется.

Разберем по шагам: правильный алгоритм переноса журнала регистрации

Проанализируем правильную и безопасную последовательность действий для переноса логов между серверными базами на MS SQL Server.

Шаг 1. Остановка службы Агента сервера 1С

Для предотвращения блокировок файлов и повреждения индексов необходимо временно остановить службу сервера приложений. Для этого воспользуемся консолью управления службами Windows или командной строкой, запущенной от имени администратора:

net stop "1C:Enterprise 8.3 Server Agent"

Убедимся, что процессы rphost, rmngr и ragent полностью завершили свою работу в диспетчере задач.

Шаг 2. Определение UID баз данных и подготовка папок

Перейдем в каталог кластера серверов 1С. По умолчанию он располагается по пути:

C:\Program Files\1cv8\srvinfo\reg_1541\

Внутри этой директории находятся папки, названия которых соответствуют уникальным идентификаторам (UID) информационных баз в кластере. Найдем папку-источник (старая база) и папку-приемник (новая база). Внутри каждой из них находится папка 1Cv8Log.

Шаг 3. Копирование файлов журнала

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

Шаг 4. Корректировка конфигурационного файла (для формата .lgf)

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

1. Откроем скопированный файл 1Cv8.lgf с помощью любого текстового редактора (например, Блокнота).
2. В самом начале файла найдем строку, содержащую старый UID базы данных.
3. Заменим этот идентификатор на новый UID (название папки новой базы в кластере).
4. Сохраним изменения и закроем файл.

Если используется формат .lgd, пропускаем этот шаг — платформа автоматически свяжет SQLite-базу при первом старте.

Шаг 5. Тонкая настройка прав безопасности (Безопасный метод)

Теперь решим ключевую проблему с ошибкой доступа, не подвергая систему уязвимостям. Настроим права доступа NTFS для сервисного пользователя 1С:

1. Нажмем правой кнопкой мыши на скопированную папку 1Cv8Log в каталоге новой базы и выберем пункт «Свойства».
2. Перейдем на вкладку «Безопасность» и нажмите кнопку «Изменить» (или «Дополнительно» для более детального контроля).
3. В открывшемся окне нажмем кнопку «Добавить».
4. В поле ввода имен выбираемых объектов введем имя пользователя, от имени которого запущена служба 1С. В стандартных конфигурациях это локальный пользователь USR1CV8. Если сервер 1С работает в доменной среде под сервисной доменной учетной записью, укажем её (например, DOMAIN\1c_service). Нажмем «Проверить имена» для валидации.
5. Выделим добавленного пользователя в списке разрешений и установим флажок напротив пункта «Полный доступ» (Full control) в колонке «Разрешить».
6. Нажмем кнопку «Дополнительно». В окне дополнительных параметров безопасности убедимся, что права применяются к «Этому контейнеру, его объектам и дочерним контейнерам». При необходимости установим флажок «Заменить все записи разрешений дочернего объекта наследуемыми от этого объекта». Это гарантирует, что права распределятся на все внутренние файлы логов (.log, .lgf или .lgd).
7. Применим все изменения, последовательно нажимая «ОК».

Шаг 6. Запуск службы и проверка работоспособности

После успешного применения прав доступа запустим службу Агента сервера 1С:

net start "1C:Enterprise 8.3 Server Agent"

Теперь запустим информационную базу в режиме «1С:Предприятие» или «Конфигуратор». Зайдем в меню «Администрирование» — «Журнал регистрации» и убедимся, что вся история успешно отображается, новые события регистрируются, а ошибка доступа больше не появляется.

Резюме

Мы проанализировали проблему с правами доступа к журналу регистрации 1С при переносе базы данных на другой сервер. Быстрое решение с предоставлением прав группе «Все» является небезопасным, поэтому мы подробно разобрали корректный метод настройки прав NTFS для системной учетной записи USR1CV8. Соблюдение этой инструкции позволит вам переносить логи быстро, корректно и без рисков для информационной безопасности предприятия.