← На главную

При работе с платформой «1С:Предприятие 8.3» системные администраторы и специалисты часто сталкиваются с ситуацией, когда серверная информационная база доступна локально, но при попытке подключения через тонкий клиент возникает ошибка: Startat Infobase session is not allowed. В русском интерфейсе эта ошибка звучит как «Начало сеанса с информационной базой запрещено». Давайте детально разберем причины возникновения этой проблемы и способы ее эффективного решения.

Анализ основной причины ошибки

Прежде всего, проанализируем саму формулировку ошибки. Сообщение Startat Infobase session is not allowed чаще всего сигнализирует о том, что сервер 1С по какой-то причине отклоняет запрос на создание новой сессии. Это может быть связано как с административными настройками самой базы, так и с техническими ограничениями на уровне операционной системы. Рассмотрим ситуацию из практики: на сервере вход в базу осуществляется без проблем, но удаленные пользователи (через тонкий клиент) зайти не могут. Это сразу сужает круг поиска до прав доступа службы 1С и сетевых настроек.

Решение №1: Изменение учетной записи службы 1С:Предприятия

Как показал опыт обсуждения, одной из самых быстрых и действенных мер является проверка учетной записи, от имени которой запущена служба 1C:Enterprise 8.3 Server Agent. Разберем по шагам, как проверить и изменить эти настройки:

1. Откроем консоль управления службами Windows (services.msc).
2. Найдем в списке службу «Агент сервера 1С:Предприятия 8.3».
3. Перейдем в свойства службы на вкладку «Вход в систему» (Log On).
4. Посмотрим, какая учетная запись там указана. Часто при установке создается специальный пользователь, например, User1cv8.
5. Если установлена пользовательская запись, попробуем временно переключить ее на «С системной учетной записью» (Local System account).
6. Перезапустим службу и проверим подключение тонкого клиента.

Важное замечание: Использование Local System часто решает проблему мгновенно, так как у этой записи есть неограниченные права на локальном компьютере. Однако, как справедливо замечено в обсуждении, это может быть небезопасно. Системная учетная запись позволяет серверу 1С выполнять любые команды в системе, включая удаление файлов. Поэтому, если смена пользователя помогла, это сигнал к тому, что нужно правильно настроить права для исходного пользователя User1cv8, а не оставлять службу работать под Local System на постоянной основе.

Решение №2: Настройка прав доступа для сервисного пользователя

Если мы хотим оставить работу службы под специальным пользователем (что правильно с точки зрения безопасности), нам необходимо вручную предоставить ему полные права на критически важные каталоги. Рассмотрим, на какие папки следует обратить внимание:

• Каталог реестра кластера (srvinfo): По умолчанию это путь C:\Program Files\1cv8\srvinfo. Здесь хранятся настройки баз, списки сессий и файлы блокировок. Если у пользователя User1cv8 нет прав на запись в эту папку, он не сможет создать файл сессии для нового подключения.
• Временные файлы (Temp): Служба 1С активно использует папку C:\Windows\Temp и профильную папку AppData\Local\Temp пользователя, под которым она запущена. Проанализируем права на эти директории — у пользователя службы должен быть полный доступ.
• Каталог установки платформы: Убедимся, что есть права на чтение и выполнение файлов в папке bin установленной платформы.

Решение №3: Проверка блокировки сеансов в консоли администрирования

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

1. Запустим консоль администрирования кластера.
2. Раскроем дерево серверов до конкретной информационной базы.
3. Откроем «Свойства» информационной базы.
4. Найдем флаг «Блокировка начала сеансов включена». Если он установлен, тонкий клиент не подключится.
5. Также обратим внимание на поле «Код разрешения». Если там что-то написано, подключение возможно только с использованием специального параметра.

Если нам необходимо зайти в базу, несмотря на блокировку, воспользуемся параметром запуска /UC. В строке подключения или в дополнительных параметрах запуска тонкого клиента укажем код:

/UC КодДоступа

Решение №4: Сетевые протоколы и разрешение имен (IP vs DNS)

Проанализируем ситуацию, описанную в сообщении №7: подключение идет по IP-адресу. В некоторых инфраструктурах это может вызвать конфликт, особенно если на сервере или клиенте активен протокол IPv6. Когда тонкий клиент обращается по IP, сервер может некорректно сопоставить запрос с правами доступа или лицензией.

Рекомендуется выполнить следующие действия:

• Попробовать подключиться не по IP, а по имени сервера.
• Если имя не разрешается (не пингуется), добавим запись в файл hosts на клиентской машине: 192.168.1.10 SERVER1C
• Проверим настройки файрвола. Даже если он «временно отключался», стоит убедиться, что порты 1540, 1541 и диапазон 1560-1591 открыты для входящих соединений.

Решение №5: Очистка кэша сеансовых данных на сервере

Иногда сервер 1С «зависает» в состоянии блокировки сессий даже после того, как в консоли все ограничения сняты. В этом случае поможет принудительная очистка серверного кэша. Разберем этот процесс:

1. Остановим службу 1C:Enterprise 8.3 Server Agent.
2. Перейдем в каталог C:\Program Files\1cv8\srvinfo\reg_1541 (путь может отличаться в зависимости от номера порта и настроек).
3. Найдем папку snccntx. В ней хранятся данные о текущих сеансах и их состояниях.
4. Удалим содержимое этой папки (саму папку можно оставить).
5. Запустим службу заново.

После этой процедуры сервер заново инициализирует таблицы сеансов, и ошибка Startat Infobase session is not allowed должна исчезнуть, если она была вызвана некорректным состоянием кэша.

Заключение

Подводя итог, можно сказать, что ошибка подключения тонкого клиента чаще всего кроется в плоскости прав доступа операционной системы к файлам реестра кластера 1С. Переключение службы на Local System — это отличный диагностический шаг, который подтверждает проблему прав. Однако для промышленной эксплуатации мы рекомендуем тщательно настроить права доступа для выделенного пользователя User1cv8 на папки srvinfo и Temp, а также проверить отсутствие административных блокировок в консоли кластера.