Под каким пользователем 1С выполняются регламентные задания и как правильно настроить их права?

Программист 1С v8.3 (Управляемые формы) IT и автоматизация бизнеса
← На главную

Вопрос о том, в каком контексте и под чьим именем запускаются регламентные задания в 1С, является фундаментальным для обеспечения безопасности и стабильности системы. Часто разработчики сталкиваются с ситуациями, когда код, успешно работающий в интерактивном режиме, «падает» с ошибкой доступа при запуске по расписанию — своевременно узнать о сбоях поможет мониторинг регламентных заданий в Telegram. Разберем детально механизмы работы платформы в различных режимах и выясним, как управлять правами фоновых процессов.

Разграничение понятий: Пользователь ОС и Пользователь информационной базы

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

  1. Пользователь операционной системы (ОС): Это учетная запись Windows или Linux, под которой запущена служба 1C:Enterprise 8.3 Server Agent (обычно это USR1CV8). Именно этот пользователь определяет права доступа платформы к файловой системе сервера, сетевым папкам и реестру.
  2. Пользователь информационной базы (ИБ): Это учетная запись внутри 1С. Она определяет права доступа к метаданным (документам, справочникам) и выполнение проверок Rls (Row Level Security) — проанализировать ограничения поможет обработка анализа ролей и прав доступа RLS.

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

Регламентные задания в клиент-серверном режиме

В клиент-серверном варианте за запуск отвечает планировщик заданий, работающий внутри процесса rmngr.exe. Когда наступает время запуска, создается отдельный фоновый сеанс в процессе rphost.exe. Для управления сеансами сервера можно использовать внешние инструменты. Выясним, кто становится «лицом» этого сеанса:

Если в настройках регламентного задания (в консоли кластера или программно) не указан конкретный пользователь ИБ, платформа создает специальный служебный сеанс. В журнале регистрации такой пользователь часто отображается с пустым именем или как системный процесс.

Важное правило прав доступа: Согласно документации ИТС, если пользователь не задан, выполнение происходит с правами, которые определяются набором ролей, указанных в свойстве конфигурации ОсновныеРоли. Проанализируем два сценария:

Особенности файлового режима

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

Для выполнения заданий в базе должен быть открыт хотя бы один сеанс 1С:Предприятия. Платформа раз в 60 секунд проверяет расписание и инициирует фоновый процесс. Несмотря на то что задание запускается «внутри» чьего-то сеанса, оно выполняется в параллельном потоке. Правила использования Основных ролей здесь работают так же, как в серверном варианте.

Если ваша файловая база опубликована на веб-сервере (Apache или IIS), регламентные задания могут выполняться самим веб-сервером даже без запущенных клиентских приложений 1С. В этом случае права на уровне ОС будут принадлежать пользователю, под которым запущен пул приложений веб-сервера.

Как программно назначить пользователя для задания

В конфигураторе для предопределенных регламентных заданий поле «Имя пользователя» отсутствует. Однако мы можем установить его программно. Рассмотрим пример кода, который позволяет назначить администратора для выполнения конкретного задания:


Менеджер = РегламентныеЗадания.НайтиПредопределенное(Метаданные.РегламентныеЗадания.ОбновлениеИндексаПолнотекстовогоПоиска);
Если Менеджер <> Неопределено Тогда
    Менеджер.ИмяПользователя = "АдминистраторРобот";
    Менеджер.Использование = Истина;
    Менеджер.Записать();
КонецЕсли;

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

Решение проблемы с COM-объектами (Excel, Word)

Часто встречается ситуация: регламентное задание должно прочитать файл Excel, но выдает ошибку COM, хотя под обычным пользователем всё работает. Выясним причину: серверные процессы 1С запускаются в неинтерактивной сессии, где у пользователя ОС нет «рабочего стола». Для оперативного мониторинга подобных сбоев разработан модуль отправки ошибок фоновых заданий в Telegram.

Решение: Для пользователя, под которым работает служба 1С (например, USR1CV8), необходимо вручную создать папки профиля рабочего стола. Без них компоненты Microsoft Office отказываются инициализироваться.

Создайте следующие директории (в зависимости от разрядности ОС и Office):

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

Доступ к сетевым ресурсам и папкам

Еще одна типичная ошибка — «Файл не найден» при обращении к сетевому диску (например, Z:\Otchet.xlsx). Разберем, почему так происходит:

  1. Сетевые диски: Диски вроде Z: являются виртуальными и существуют только внутри сеанса конкретного пользователя ОС. Сервер 1С их не видит. Всегда используйте UNC-пути, например: \\ServerName\ShareFolder\File.xlsx.
  2. Права доступа: Если служба 1С запущена под локальным пользователем (.\USR1CV8), она не сможет выйти за пределы сервера в сеть. Для доступа к сетевым папкам других серверов необходимо перевести службу 1С на запуск из-под доменной учетной записи.

Использование привилегированного режима

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

Если в общем модуле установлен флаг «Привилегированный», то код внутри него выполняется без проверки прав доступа. Это идеальное решение для регламентных заданий, которым нужно собирать данные из разных разделов учета или записывать системные журналы, не наделяя фонового пользователя избыточными правами.

Пример вызова в коде:


// В модуле регламентного задания
Процедура ВыполнитьОбработкуДанных() Экспорт
    // Вызываем метод из привилегированного модуля
    ОбщийМодульСервер.ЗаписатьДанныеБезПроверкиПрав();
КонецПроцедуры

Как отличить регламентное задание от обычного пользователя в коде

Иногда требуется изменить логику программы, если она выполняется фоново (например, не выводить предупреждения или отправлять ошибки на почту, а не в Сообщить). Посмотрим, как это реализовать:


Сеанс = ПолучитьТекущийСеансИнформационнойБазы();
Если Сеанс.ИмяПриложения = "BackgroundJob" Тогда
    // Мы находимся в контексте фонового/регламентного задания
    ЗаписатьЛогВФайл("Робот начал работу");
Иначе
    Сообщить("Вы запустили обработку вручную");
КонецЕсли;

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

Подводя итог, можно сказать: стабильность регламентных заданий зависит от правильной комбинации прав пользователя ОС (для работы с внешним миром) и настроек пользователя ИБ или использования привилегированного режима (для работы с данными). Проектируя систему с нуля, всегда закладывайте использование UNC-путей и проверяйте настройки Основных ролей в вашей конфигурации.

← На главную