При разработке механизмов интеграции часто возникает задача программного чтения или записи файлов, расположенных на удаленном сетевом ресурсе в домене Active Directory. Стандартный метод платформы 1С Файл.Существует() при указании UNC-пути вида \\server\share\file.txt неожиданно возвращает Ложь, хотя при интерактивной проверке под учетной записью администратора или пользователя файл прекрасно открывается. В этой статье мы подробно разберем, почему возникает эта проблема, как работает контекст выполнения в 1С и как пошагово диагностировать и устранить ограничения доступа.
Первое, с чего необходимо начать анализ ситуации — это четкое определение контекста, в котором выполняется код. Рассмотрим простой пример кода:
ПутьКФайлу = "\\fileserver\exchange\import.xml";
ФайлНаДиске = Новый Файл(ПутьКФайлу);
Если ФайлНаДиске.Существует() Тогда
// Обработка файла
Иначе
Сообщить("Файл не найден или доступ ограничен!");
КонецЕсли;
Если этот код выполняется в клиентском контексте (на стороне тонкого или толстого клиента), операционная система запрашивает файл от имени того пользователя Windows, под которым запущена сессия 1С на рабочем компьютере. В этом случае проверка обычно проходит успешно, так как у пользователя есть необходимые права в домене.
Однако, если этот же код выполняется на стороне сервера приложений 1С (например, внутри общего модуля с флагом Сервер, в модуле менеджера или в регламентном задании), запрос к сетевой папке инициирует процесс сервера rphost.exe. В этот момент права текущего пользователя 1С (авторизованного в информационной базе) не имеют никакого значения. Платформа 1С не поддерживает имперсонацию (выполнение кода ОС от имени пользователя 1С), поэтому все обращения к файловой системе происходят исключительно от имени учетной записи операционной системы, под которой запущена служба «Агент сервера 1С:Предприятия».
Служба Агента сервера 1С работает в изолированной среде Windows, известной как Session 0. Это накладывает существенные ограничения на сетевое взаимодействие:
Чтобы исключить влияние клиентского контекста и гарантированно запустить проверку от имени службы сервера 1С, мы можем использовать механизм фоновых заданий. Напишем простую процедуру во внешнем модуле и запустим ее в фоне:
Процедура ВыполнитьПроверкуНаСервере(ПутьКФайлу) Экспорт
ФайлНаСервере = Новый Файл(ПутьКФайлу);
Доступен = ФайлНаСервере.Существует();
ЗаписьЖурналаРегистрации(
"ТестДоступаКФайлу",
УровеньЖурналаРегистрации.Информация,
,
,
"Проверка пути: " + ПутьКФайлу + ". Результат: " + Строка(Доступен)
);
КонецПроцедуры
Запустим эту процедуру асинхронно через менеджер фоновых заданий:
ПараметрыЗапуска = Новый Массив;
ПараметрыЗапуска.Добавить("\\fileserver\exchange\import.xml");
ФоновыеЗадания.Выполнить("ИмяОбщегоМодуля.ВыполнитьПроверкуНаСервере", ПараметрыЗапуска);
После выполнения перейдем в Журнал регистрации 1С. Если мы увидим запись со значением Ложь, это со стопроцентной уверенностью указывает на то, что у учетной записи службы сервера 1С нет физического доступа к сетевому ресурсу, либо доступ заблокирован политиками безопасности самой платформы 1С.
Очень частая ошибка системных администраторов — предоставление прав только на уровне общего доступа папки (Share Permissions) без настройки прав на уровне файловой системы (NTFS Security), либо наоборот. Для успешного доступа учетной записи Агента 1С должны быть предоставлены права в обоих местах:
DOMAIN\usr1cv8) должна иметь права на "Чтение" (или "Изменение", если требуется запись файлов).Если служба 1С работает под локальной системной учетной записью (например, Network Service или Local System), то для предоставления доступа на сетевом ресурсе необходимо давать права не пользователю, а учетной записи самого компьютера, на котором установлен сервер 1С (например, DOMAIN\SERVER1C$).
Для того чтобы полностью исключить платформу 1С из цепочки возможных виновников и проверить доступ напрямую на уровне операционной системы, используем профессиональный инструмент администратора — утилиту PsExec из пакета Sysinternals от Microsoft.
Проанализируем ситуацию по шагам:
DOMAIN\usr1cv8 и password на ваши данные):
psexec -u DOMAIN\usr1cv8 -p password cmd.exe
dir \\fileserver\exchange\
Если команда dir возвращает ошибку «Отказано в доступе» (Access is Denied), это окончательно доказывает, что проблема кроется в настройках прав Active Directory, групповых политиках или настройках сетевого общего доступа. На этом этапе необходимо передать информацию системным администраторам сети.
Если же команда dir успешно вывела список файлов, но в 1С метод Файл.Существует() по-прежнему возвращает Ложь, значит, на сервере 1С включены внутренние ограничения платформы.
Разберем две внутренние причины блокировки файловых операций в самой платформе:
Если исполняемый код вызывается внутри безопасного режима (например, при использовании внешних отчетов и обработок, загруженных из справочника "Дополнительные отчеты и обработки" БСП), платформа превентивно блокирует работу с любыми внешними ресурсами. Проверка существования файла вернет Ложь без вызова исключения. Чтобы решить эту проблему, необходимо настроить профили безопасности или разрешить выполнение обработки без ограничений (в режиме полной безопасности).
Если в консоли администрирования кластера 1С для вашей информационной базы включены профили безопасности, сервер 1С будет блокировать любые попытки обращения к файловой системе за пределами разрешенных путей. Для исправления ситуации необходимо зайти в свойства профиля безопасности в консоли администрирования 1С и явно добавить ваш UNC-путь \\fileserver\exchange\ в список разрешенных путей для чтения/записи.
Для успешного решения проблемы доступа сервера 1С к сетевым ресурсам придерживайтесь следующего алгоритма:
USR1CV8.PsExec для проверки доступности каталога из-под учетной записи службы 1С в ОС Windows.