Как убрать ошибку «нет прав на запуск требуемого вида клиента» в 1С 8.3

Сообщение Нет прав на запуск требуемого вида клиента означает одно: ярлык пытается открыть базу тем клиентом (толстым, тонким или веб), на который у роли пользователя нет права. Данные целы, база не сломана — не хватает одной галочки либо в ярлыке, либо в правах.

Лечится это двумя путями. Быстрый — поменять вид клиента в списке баз, тогда права править не придётся. Правильный — выдать пользователю право на нужный вид клиента: в типовых через профиль групп доступа, в самописных через роль в Конфигураторе.

Ниже — оба пути с точными путями меню, разбор для Бухгалтерии 3.0, ЗУП 3.1, УТ 11 и ERP, отдельно веб-клиент и COM-соединение, плюс типичные промахи, из-за которых 1С 8.3 продолжает писать «нет прав на запуск» даже после правки ролей.

Что значит «нет прав на запуск требуемого вида клиента» в 1С 8.3

Платформа 8.3 умеет подключаться к базе пятью разными способами. Каждый способ — это отдельное право в роли. Сеанс проверяет право в момент подключения, ещё до открытия интерфейса, поэтому ошибка вылетает сразу после ввода пароля.

В типовых конфигурациях на БСП (Бухгалтерия 3.0, ЗУП 3.1, УТ 11, КА 2, ERP 2) этим управляют служебные роли с говорящими названиями: «Запуск тонкого клиента », «Запуск толстого клиента», «Запуск веб-клиента», «Запуск внешнего соединения». Обычным пользователям толстый клиент не выдают сознательно — типовые профили его не содержат.

Быстрая диагностика: почему 1С пишет «нет прав на запуск»

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

Способ 1. Сменить вид клиента в списке баз и в ярлыке

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

Через окно запуска 1С

1. Откройте окно со списком баз (1cestart.exe или обычный ярлык «1С:Предприятие»).
2. Выделите нужную базу и нажмите Изменить.
3. Дойдите до второй страницы кнопкой Далее.
4. В поле Основной режим запуска выберите Тонкий клиент вместо Выбирать автоматически.
5. Нажмите Готово и запускайте базу.

Если режим «Тонкий клиент» уже стоит, а ошибка та же — значит прав нет вообще ни на один вид клиента, переходите к способу 2.

Через свойства ярлыка на рабочем столе

Правый клик по ярлыку → Свойства → поле Объект. Нужно, чтобы путь указывал на тонкий клиент:

"C:\Program Files\1cv8\8.3.27.1508\bin\1cv8c.exe" ENTERPRISE /S"srv-1c\buh30"

Для файловой базы:

"C:\Program Files\1cv8\8.3.27.1508\bin\1cv8c.exe" ENTERPRISE /F"D:\Bases\Buh30"

Разница в одной букве: 1cv8.exe — толстый клиент, 1cv8c.exe — тонкий. Номер релиза в пути подставьте свой.

Через файл ibases.v8i

Когда список баз раздаётся централизованно, правьте его напрямую. Личный список лежит в %APPDATA%\1C\1CEStart\ibases.v8i, общий — в файле, указанном в 1CEStart.cfg параметром CommonInfoBases.

[Бухгалтерия 3.0]
Connect=Srvr="srv-1c";Ref="buh30";
ID=4c2f1e90-1f3a-4d3b-9b7a-2d1f4a6c8e11
App=ThinClient
WA=1
Version=8.3

Параметр App принимает три значения: Auto, ThinClient, ThickClient. Поставьте ThinClient — и все, кто получает этот список, перестанут упираться в ошибку.

Способ 2. Выдать право на запуск в профиле групп доступа

Это основной способ для типовых конфигураций. Роли там не правят в Конфигураторе — их набор задаётся профилем группы доступа.

Бухгалтерия 3.0 и ЗУП 3.1

1. Зайдите в базу под пользователем с полными правами.
2. Откройте Администрирование → Настройки пользователей и прав → Профили групп доступа.
3. Найдите профиль, по которому работает пользователь, и откройте его.
4. Перейдите на вкладку Разрешенные действия (роли).
5. Отметьте Запуск тонкого клиента (при необходимости — Запуск веб-клиента).
6. Запишите и закройте профиль.
7. Попросите пользователя перезайти в базу.

Если служебных ролей запуска в списке не видно, включите их показ: в части релизов это команда Еще → Показывать служебные роли, в части — флажок над списком. По умолчанию они скрыты, чтобы не путать бухгалтеров.

УТ 11, КА 2 и ERP 2

Путь тот же: НСИ и администрирование → Администрирование → Настройки пользователей и прав → Профили групп доступа. Дальше всё совпадает с Бухгалтерией.

Отдельно проверьте, что пользователь действительно входит в группу доступа с этим профилем: Администрирование → Настройки пользователей и прав → Группы доступа → откройте группу → вкладка Участники.

Пользователь создан в Конфигураторе — частая ловушка

Если учётную запись добавили через Администрирование → Пользователи в Конфигураторе, в справочнике «Пользователи» её может не быть. Тогда у пользователя нет групп доступа, нет ни одной роли — и при входе он получает ровно это сообщение.

Лечение: откройте базу в тонком клиенте под администратором, зайдите в Администрирование → Настройки пользователей и прав → Пользователи, найдите учётную запись в списке (она подтянется как «не сопоставленная») либо создайте пользователя заново из интерфейса, а дубль из Конфигуратора удалите.

Способ 3. Право на вид клиента в роли через Конфигуратор

Нужен для самописных конфигураций, доработанных баз и старых обработок, у которых своя роль. Для типовых — только если профили групп доступа в конфигурации не используются.

1. Откройте базу в Конфигураторе.
2. Общие → Роли → двойной клик по нужной роли.
3. В левом дереве объектов встаньте на самую первую строку — корень Конфигурация.
4. В правой части найдите права Тонкий клиент, Толстый клиент, Веб-клиент, Внешнее соединение, Automation.
5. Поставьте галочку на нужном виде клиента.
6. Закройте окно роли и нажмите F7 — обновление конфигурации базы данных.
7. Проверьте вход пользователем, у которого была ошибка.

Пункт 6 пропускают чаще всего: роль поправлена, а в рабочей базе действуют старые права. Обновление конфигурации БД требует, чтобы в базе не было активных сеансов.

Способ 4. Режим запуска в карточке пользователя

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

Откройте Администрирование → Пользователи → карточка пользователя → вкладка Прочие → поле Режим запуска. Значения:

• 🔄 Авто — платформа выбирает сама, с учётом настройки базы;
• 💻 Тонкий клиент — всегда тонкий, даже если ярлык ведёт на 1cv8.exe;
• 🖥️ Толстый клиент — всегда толстый; если права на него нет, получаем нашу ошибку.

Самый коварный случай: в карточке стоит Толстый клиент, а роль даёт только тонкий. Пользователь меняет ярлыки, чистит кэш, переустанавливает платформу — и всё без толку, потому что вид клиента ему навязан карточкой. Поставьте Авто или Тонкий клиент.

Нет прав на запуск требуемого вида клиента в браузере

Веб-клиент — отдельное право, и тонкий клиент его не покрывает. Типичная картина: на рабочем месте база открывается, а по ссылке публикации пользователь видит то же сообщение.

Что проверить по порядку:

1. В профиле групп доступа отмечена роль Запуск веб-клиента (для типовых).
2. В роли на корне конфигурации стоит право Веб-клиент (для самописных).
3. Пользователь заходит в базу под своей учётной записью, а не под сохранённой в браузере чужой.
4. Публикация ведёт на ту же базу, которую вы правили, — в default.vrd проверьте строку соединения.
5. После правки ролей пользователь закрыл все вкладки с 1С: старый сеанс продолжает жить и ошибка повторяется.

COM-соединение, обмены и задания по расписанию

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

Соединение = Новый COMОбъект("V83.COMConnector");
Сеанс = Соединение.Connect("Srvr=""srv-1c"";Ref=""buh30"";Usr=""Обмен"";Pwd=""********""");

Что выдать пользователю Обмен:

• в типовых — роль Запуск внешнего соединения в его профиле групп доступа;
• в самописных — право Внешнее соединение на корне конфигурации;
• для V83.Application вместо COMConnector — ещё и право Automation.

Отдельно про регламентные задания. В клиент-серверном режиме они выполняются на сервере и в этом праве не нуждаются. А вот в файловой базе задания часто поднимают отдельным сеансом через COM — там право Внешнее соединение обязательно.

Типичные ошибки при лечении

• ❌ Чистят кэш 1С. Удаление каталогов кэша в %LOCALAPPDATA%\1C\1cv8 на эту ошибку не влияет. Время потрачено зря.
• ❌ Правят роль и не нажимают F7. Без обновления конфигурации БД новые права в рабочей базе не появятся.
• ❌ Выдают право «Толстый клиент» вместо смены ярлыка. Пользователь получает доступ к режиму «Все функции» и монопольному режиму, которые ему не нужны.
• ❌ Меняют поставляемый профиль. После очередного обновления конфигурации правка исчезает, ошибка возвращается.
• ❌ Добавляют роль в профиль, но не включают пользователя в группу доступа. Роль есть, а связи с человеком нет.
• ❌ Назначают профиль «Администратор», чтобы «просто заработало». Это не лечение, а дыра в разграничении доступа.
• ❌ Путают с сообщениями вида «Недостаточно прав на просмотр справочника». Те относятся к конкретному объекту, а наша ошибка — к самому факту подключения.
• ❌ Переустанавливают платформу. Права хранятся в базе, а не в клиенте.

Чем проверить результат

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

Журнал регистрации. В типовых: Администрирование → Обслуживание → Журнал регистрации. В Конфигураторе: Администрирование → Журнал регистрации. Отфильтруйте по пользователю и смотрите события начала сеанса — у успешного входа будет указан вид приложения (тонкий клиент, веб-клиент).

Отчёт по правам. Администрирование → Настройки пользователей и прав → Отчеты → Права доступа (в части конфигураций отчёт называется Сведения о правах доступа). Отчёт покажет, какие роли фактически собрались у пользователя из всех его групп доступа.

Список активных пользователей. Администрирование → Обслуживание → Активные пользователи: в колонке с приложением видно, каким именно клиентом подключены коллеги. Удобно, чтобы понять, у кого ярлык «не такой».

Как не столкнуться с ошибкой снова

• 📌 Раздавайте базы общим списком через CommonInfoBases и ставьте в нём App=ThinClient. Тогда вид клиента не зависит от самодельных ярлыков.
• 📌 Держите один свой профиль-копию на каждую роль в компании и обновляйте только его.
• 📌 Толстый клиент оставьте администратору и программисту. Остальным он не нужен и создаёт риски.
• 📌 Новых пользователей создавайте только из интерфейса базы, а не в Конфигураторе.
• 📌 После каждого обновления конфигурации проверяйте вход одним «рядовым» пользователем — так ошибка всплывает до начала рабочего дня, а не в 9:05.

Если не помогло

Сообщение осталось после всех правок — пройдите по короткому списку.

1. Проверьте, что правили ту же базу, в которую входите. На клиент-серверной связке легко открыть тестовую копию с похожим именем.
2. Убедитесь, что у пользователя нет второй учётной записи с похожим ФИО, и он выбирает нужную в списке.
3. Посмотрите, нет ли у пользователя профиля с пустым набором ролей — такой профиль перебивает ожидания, роль запуска надо включить именно в него.
4. Проверьте расширения конфигурации: если расширение добавляет свою роль, она должна быть включена в профиль наравне с типовыми.
5. Завершите все сеансы пользователя в консоли администрирования кластера и попросите войти заново.
6. В файловой базе откройте её толстым клиентом под администратором и выполните Тестирование и исправление с проверкой логической целостности — редкий, но реальный случай повреждения служебных таблиц пользователей.

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

Частые вопросы