Откуда 1С:Предприятие берёт «Операция не разрешена» и как найти виновника

Ошибка «Операция не разрешена» в 1С возникает, когда действие запрещено на одном из уровней: правами пользователя, режимом работы базы, текстом запроса, СУБД или операционной системой. Чтобы найти причину, откройте подробный текст ошибки (Подробнее в окне сообщения) и посмотрите, откуда она пришла: из модуля конфигурации, из запроса, от сервера СУБД или от системного вызова.

Важная деталь для тех, у кого сервер 1С стоит на Linux. Фраза «Операция не разрешена» — это дословный русский перевод системной ошибки Operation not permitted (EPERM). Если она пришла вместе с путём к файлу или каталогу, проблема почти всегда в правах на диске, а не в настройках 1С.

Как понять, на каком уровне запрещена операция

Одна и та же короткая фраза прячет разные причины. Источник выдаёт хвост сообщения: в нём бывает имя модуля, строка запроса, код ошибки СУБД или путь к файлу.

Где смотреть полный текст:

• 🔎 окно ошибки — кнопка Подробнее или ссылка с подробным текстом;
• 📜 журнал регистрации — в БП 3.0 и ЗУП 3.1 путь Администрирование → Обслуживание → Журнал регистрации, отбор по уровню «Ошибка» и по пользователю;
• 🖥 технологический журнал сервера — файл logcfg.xml в каталоге conf платформы, события EXCP;
• 🐘 журнал СУБД — для PostgreSQL файлы в каталоге log кластера, для MS SQL журнал ошибок в SQL Server Management Studio.

Сопоставьте признаки с уровнем:

Права пользователя: роли, профили и группы доступа

Самый частый сценарий в типовых конфигурациях на БСП: пользователь открывает документ или нажимает «Провести», а программа отказывает. Технически это не «поломка», а штатный отказ системы прав.

Иерархия в БП 3.0, ЗУП 3.1 и УТ 11 одинаковая:

1. Роль — набор прав на объекты метаданных (чтение, добавление, изменение, проведение). Задаётся в конфигурации.
2. Профиль группы доступа — набор ролей под должность: «Бухгалтер», «Кладовщик», «Кадровик».
3. Группа доступа — профиль плюс конкретные участники и, при необходимости, ограничения по значениям: организации, склады, подразделения.
4. Пользователь — входит в одну или несколько групп. Права из разных групп суммируются.

Где это настраивается: Администрирование → Настройки пользователей и прав. Там же ссылки на списки «Пользователи», «Группы доступа» и «Профили групп доступа».

Порядок проверки прав

1. Откройте карточку пользователя и посмотрите, в каких группах доступа он состоит.
2. В группе проверьте профиль и вкладку с ограничениями: если пользователю открыта только одна организация, документ по другой организации он не запишет.
3. Посмотрите, включено ли ограничение доступа на уровне записей (RLS). Флажок находится в тех же настройках пользователей и прав.
4. Проверьте даты запрета изменения данных. В БП 3.0 флажок и настройка — в Администрирование → Настройки пользователей и прав. Документ за закрытый период не перепроводится, даже если ролей достаточно.

Нестандартные роли

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

Блокировки данных и монопольный режим

Конфликты блокировок обычно дают свои тексты: «Конфликт блокировок при выполнении транзакции», «Превышено максимальное время ожидания предоставления блокировки», «Ошибка блокировки объекта». Но пользователи пересказывают их как «не разрешает записать», поэтому этот уровень стоит проверить.

Три разных механизма:

• 🔒 Объектная блокировка — документ открыт на редактирование у другого пользователя. Второй пользователь не сможет его записать, пока первый не закроет форму.
• 🧱 Транзакционная (управляемая) блокировка — две операции одновременно пишут в одни и те же записи регистров. Например, два кладовщика проводят расход по одной номенклатуре. Вторая операция ждёт и падает по таймауту.
• 🚪 Монопольный режим — нужен для обновления структуры базы, загрузки файла .dt, тестирования и исправления. Пока в базе есть другие сеансы, установить его нельзя.

Что делать по каждому случаю:

Для файловой базы признак висящего сеанса — файл 1Cv8tmp.1CD рядом с 1Cv8.1CD. Его наличие при закрытой у всех программе говорит о том, что какой-то процесс 1cv8.exe остался в памяти. Сначала завершите процесс через диспетчер задач на том компьютере, где он висит, и только потом трогайте файлы.

«Операция не разрешена в предложении ГДЕ»: ошибка в тексте запроса

Если в подробном тексте видно слово ГДЕ и фрагмент запроса, права пользователя ни при чём. Платформа отказалась выполнять конструкцию, которую язык запросов в этом месте не допускает. Ошибка возникает при формировании отчёта, открытии списка или в своей обработке.

Две типичные причины:

1. Агрегатная функция в условии ГДЕ. СУММА, КОЛИЧЕСТВО, МАКСИМУМ вычисляются после группировки, а ГДЕ отбирает записи до неё. Условие на итог переносят в ИМЕЮЩИЕ.
2. Сравнение строки неограниченной длины. Реквизит типа «Строка» без длины (часто это «Комментарий») нельзя напрямую сравнивать в условии. Его приводят к строке фиксированной длины.

Как было и как надо:

// Ошибка: агрегат в ГДЕ
ВЫБРАТЬ
    Продажи.Номенклатура,
    СУММА(Продажи.Сумма) КАК Сумма
ИЗ
    РегистрНакопления.Продажи КАК Продажи
ГДЕ
    СУММА(Продажи.Сумма) > 10000
СГРУППИРОВАТЬ ПО
    Продажи.Номенклатура

// Правильно: условие на итог в ИМЕЮЩИЕ
ВЫБРАТЬ
    Продажи.Номенклатура,
    СУММА(Продажи.Сумма) КАК Сумма
ИЗ
    РегистрНакопления.Продажи КАК Продажи
СГРУППИРОВАТЬ ПО
    Продажи.Номенклатура
ИМЕЮЩИЕ
    СУММА(Продажи.Сумма) > 10000

Для строки неограниченной длины:

ГДЕ
    ВЫРАЗИТЬ(Док.Комментарий КАК СТРОКА(200)) = &Комментарий

Если запрос сидит в типовом отчёте без доработок, а ошибка появилась после обновления, проверьте подключённые расширения и внешние отчёты. Чаще всего ломается именно доработка, написанная под прежнюю структуру объектов.

СУБД, файловая система и драйверы

В клиент-серверной базе сервер 1С подключается к СУБД под отдельным логином. Если у этого логина отобрали права или базу восстановили из копии под другим владельцем, платформа получит отказ от СУБД и передаст его пользователю.

PostgreSQL

Признак — в подробном тексте ERROR: permission denied for table или permission denied for schema. Что проверить:

• владельца базы и таблиц: после восстановления из дампа под пользователем postgres таблицы могут принадлежать не той роли, которая прописана в параметрах базы на кластере 1С;
• что роль, указанная в свойствах информационной базы в консоли кластера, совпадает с владельцем;
• свободное место в табличном пространстве и на разделе с каталогом временных файлов.

MS SQL Server

Логину сервера 1С нужна роль db_owner в базе. Ошибка часто появляется после переноса базы на другой сервер: логин создали заново, а пользователь внутри базы остался «осиротевшим» и не привязан к нему. Сопоставление логина и пользователя базы — задача администратора СУБД.

Linux: системная ошибка EPERM

Здесь «Операция не разрешена» приходит от ядра. Причины в порядке частоты:

1. Владелец каталога не тот. Служба сервера 1С обычно работает от пользователя usr1cv8; файловая база, опубликованная через Apache, — от www-data или apache.
2. На файл установлен атрибут неизменяемости. Права rwx при этом выглядят нормально, но даже root не может изменить файл.
3. Включён SELinux, и контекст каталога не разрешает запись службе.
4. Раздел смонтирован только на чтение или сетевой ресурс отдаёт «чужого» владельца.

Команды для проверки:

ls -l /path/to/base
lsattr /path/to/base/1Cv8.1CD
getenforce
mount | grep /path/to

Если lsattr показывает флаг i, снимите его командой chattr -i <файл>. Владельца меняют так:

chown -R usr1cv8:grp1cv8 /path/to/base

Антивирус, права Windows и служба сервера 1С

На Windows отказ от системы обычно звучит как «Отказано в доступе», но 1С может обернуть его в собственное сообщение. Под подозрением две группы причин.

Антивирус и защита от программ-вымогателей

Антивирус держит файл базы или временный файл в момент записи, и платформа получает отказ. Особенно агрессивно ведёт себя функция контролируемого доступа к папкам в Защитнике Windows: она молча блокирует запись в защищённые каталоги.

Что добавить в исключения:

• 📁 каталог файловой базы целиком;
• 📁 каталог кластера сервера srvinfo (по умолчанию в каталоге установки платформы или в профиле пользователя службы);
• 📁 пользовательский кэш %APPDATA%\1C\1cv8 и %LOCALAPPDATA%\1C\1cv8;
• ⚙️ исполняемые файлы 1cv8.exe, 1cv8c.exe, ragent.exe, rmngr.exe, rphost.exe.

Учётная запись службы

Служба «Агент сервера 1С:Предприятия» работает от выделенного пользователя, обычно USR1CV8. Ему нужны права на изменение каталога srvinfo и на каталоги, куда обработки выгружают файлы. Если обработка пишет файл на сетевой ресурс, доступ нужен именно этой учётной записи, а не бухгалтеру, который нажал кнопку: код на сервере выполняется от имени службы.

Для файловой базы в общей папке права нужны всем пользователям 1С: и на уровне общего ресурса, и на уровне NTFS. Чтения недостаточно — платформа создаёт рядом служебные файлы.

Веб-клиент и тонкий клиент: что работает иначе

Бывает, что в тонком клиенте всё работает, а в браузере то же действие отказывает. Причина в ограничениях браузера, а не в правах базы.

• 🌐 Работа с файлами. Для выбора, сохранения и открытия локальных файлов веб-клиенту нужно расширение работы с файлами. Без него выгрузка и загрузка через диалог файла недоступны.
• ⏳ Синхронные вызовы. В современных браузерах модальные окна и синхронные методы запрещены. Конфигурация с параметром «Режим использования синхронных вызовов», разрешающим их, выдаст ошибку в браузере. Типовые конфигурации свежих редакций написаны асинхронно; страдают старые доработки.
• 🧩 COM-объекты и внешние компоненты. В веб-клиенте COM недоступен. Код, создающий Excel.Application на клиенте, в браузере не выполнится.
• 🪟 Всплывающие окна. Блокировщик браузера не даёт открыть печатную форму или отчёт в новом окне. Разрешите всплывающие окна для адреса публикации.

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

Тонкий клиент тоже ограничен: он не исполняет код, привязанный к толстому клиенту, а на Linux и macOS не работает с COM. Если обработка писалась под толстый клиент обычного приложения, в управляемом режиме она будет отказывать.

Порядок действий администратора при сбое

Логика простая: двигайтесь от узкого к широкому. Ошибка у одного пользователя — почти наверняка права или его клиент. У всех — изменения в конфигурации, СУБД или на сервере. Только в одном отчёте — текст запроса или доработка.

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

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