При разработке функционала, связанного с чтением или записью файлов на сетевые ресурсы в контексте &НаСервере, программисты часто сталкиваются с ошибкой доступа. Ситуация осложняется тем, что при интерактивной проверке под учетной записью администратора или пользователя всё работает корректно, но код 1С упорно выдает «Ошибка при осуществлении операции над файлом» (в таких случаях может помочь инструмент для копирования файлов между клиентом и сервером). Проанализируем, почему это происходит и как правильно настроить окружение для стабильной работы.
Первым делом нам необходимо понять базовый принцип работы Windows: любой процесс в системе выполняется от имени определенного пользователя. Сервер 1С (служба ragent) — не исключение. Если вы обращаетесь к локальному диску сервера, прав локального пользователя USR1CV8 обычно достаточно. Однако, как только мы выходим в сеть, правила игры меняются.
Рассмотрим ситуацию, когда служба 1С запущена под локальной учетной записью (например, .\USR1CV8). Для любого другого компьютера в сети этот пользователь является абсолютно неизвестным (анонимным). Даже если вы создадите на другом сервере папку и дадите права «Все», настройки безопасности домена или политики конкретной машины могут блокировать доступ для неавторизованных сущностей.
Чтобы не гадать, какая именно учетная запись пытается достучаться до файла, мы можем использовать методы Windows Script Host прямо из кода 1С. Разберем пример кода, который поможет нам вывести имя пользователя в консоль или журнал регистрации:
// Выполняем строго в серверном контексте
WShell = Новый COMОбъект("WScript.Network");
ИмяПользователяСервера = WShell.UserName;
Сообщить("Сервер 1С работает от имени: " + ИмяПользователяСервера);
Этот метод WScript.Network позволяет быстро подтвердить догадку о том, под кем крутится служба. Если вы видите в результате имя вашей локальной машины и USR1CV8, значит, для доступа к сетевым ресурсам вам придется либо менять пользователя службы, либо использовать обходные пути.
Иногда COM-объекты могут быть ограничены настройками безопасности. В таком случае проанализируем ситуацию с помощью системной утилиты whoami. Это наиболее надежный способ узнать контекст безопасности процесса. Мы можем запустить ее и перенаправить вывод в текстовый файл, который затем прочитаем в 1С:
ИмяФайлаРезультата = ПолучитьИмяВременногоФайла("txt");
Команда = "cmd /c whoami > """ + ИмяФайлаРезультата + """";
ЗапуститьПриложение(Команда, , Истина); // Ждем завершения
ТекстРезультат = Новый ТекстовыйДокумент;
ТекстРезультат.Прочитать(ИмяФайлаРезультата);
Сообщить("Полный контекст пользователя: " + ТекстРезультат.ПолучитьТекст());
Самый правильный и рекомендуемый способ — это перевод службы 1С на работу под доменной учетной записью. Рассмотрим, почему это важно. Доменная запись (например, DOMAIN\1c_service) понятна всем участникам сети. Вы просто добавляете этого пользователя в список разрешений на сетевой папке (вкладки «Доступ» и «Безопасность»), и магия начинает работать.
Важный нюанс: при смене учетной записи службы (особенно если планируется массовый импорт данных из Excel и текстовых форматов) не забудьте через консоль управления службами (services.msc) убедиться, что новому пользователю назначены права Log on as a service (Вход в качестве службы) и он имеет полные права на папку с данными сервера 1С (обычно это C:\Program Files\1cv8\srvinfo) — для этого пригодится перенос файлов 1С в тома на диске.
Если ваша служба работает под системной записью NetworkService, она обращается к сетевым ресурсам от имени компьютера. В этом случае, настраивая права на сетевую папку, нам нужно сделать следующее:
ServerName$).Проанализируем еще одну частую ошибку. Часто системные администраторы подключают сетевые диски (например, диск Z:) для удобства. Однако важно помнить: сервер 1С работает в так называемой «Сессии 0». В этой сессии не существует сетевых дисков, которые вы видите в своем терминальном сеансе или на рабочем столе сервера.
Для работы 1С на сервере (даже если это работа с PDF файлами без внешних компонентов) всегда используйте полные UNC-пути в формате: \\ИмяСервера\ИмяПапки\Файл.ext — для этого подойдёт массовая загрузка файлов из папки в 1С. Попытка обратиться к Z:\Data.xml или файлу в формате DBF из серверного модуля неизбежно приведет к ошибке, даже если права настроены идеально.
Выясним причину, по которой иногда «вроде бы всё дали, но не работает». Права в Windows на сетевой ресурс суммируются по принципу наиболее строгого ограничения в двух местах:
Если на вкладке «Общий доступ» стоит Все — Только чтение, а на вкладке «Безопасность» вы дали USR1CV8 — Полный доступ, то пользователь всё равно сможет только читать файлы. Проверьте оба места и убедитесь, что права Изменение или Полный доступ выданы везде — для этого подойдёт выгрузка прикрепленных файлов из базы 1С.
Если у вас нет домена, но нужно заставить локальную учетную запись .\USR1CV8 ходить в сеть, можно прибегнуть к хитрости «зеркалирования». На удаленном компьютере, где лежит папка, создайте локального пользователя с таким же именем и таким же паролем, как у пользователя, под которым запущен сервер 1С. Windows при попытке входа по сети предложит текущие учетные данные, и удаленная машина их примет как свои.
Соблюдение этих структурных правил и методов диагностики позволит вам быстро и эффективно решать любые проблемы с доступом сервера 1С к файловой системе предприятия. Для этой задачи есть выгрузка файлов 1С в структурированные папки.