Почему XML-файл не копируется на сетевой диск из 1С через VBScript и как это исправить?

В практике разработки на платформе 1С часто возникает задача передачи данных во внешние системы через общие сетевые ресурсы. Одной из типичных схем является формирование XML-файла и его последующее перемещение в сетевую папку. Однако разработчики часто сталкиваются с ситуацией, когда обычные текстовые файлы (.txt) копируются без проблем, а при попытке скопировать .xml система выдает ошибку "Разрешение отклонено" (Permission Denied). Разберем по шагам, почему это происходит и как правильно настроить процесс в клиент-серверном режиме работы.

Анализ контекста выполнения кода

Прежде всего, проанализируем, где именно исполняется код. Когда мы запускаем внешнюю обработку в клиент-серверной базе, код с директивой &НаСервере выполняется от имени учетной записи, под которой запущена служба "Агент сервера 1С:Предприятия". Это критически важный момент. Даже если вы авторизованы в Windows под учетной записью администратора, сервер 1С может работать под ограниченной системной учетной записью (например, USR1CV8 или NetworkService).

Выясним причину разного поведения файлов разных форматов. Рассмотрим ситуацию: .txt копируется, а .xml — нет. Это часто вводит в заблуждение, заставляя думать, что права доступа настроены верно. На самом деле, для сетевых ресурсов могут быть настроены политики безопасности, которые фильтруют содержимое или расширения файлов.

Причина 1: Сетевые диски и сессии пользователей

В коде автора часто фигурируют пути вида W:\Import\. Это типичная ошибка при работе на сервере. Сетевые диски (Mapped Drives) являются объектами сеанса конкретного пользователя. Служба 1С работает в так называемой "Сессии 0", где ваши подключенные диски W:, S: или Z: просто не существуют.

Решение: Всегда используйте полные сетевые пути в формате UNC. Разберем на примере изменения кода:

// Вместо использования буквы диска W:\
// Используем прямой сетевой путь \\ServerName\ShareName\
КодФункции = "Function copy | |Set objFSO = CreateObject(""Scripting.FileSystemObject"") |objFSO.CopyFile ""\\SourceServer\sw\1.xml"" , ""\\TargetServer\Import\"", true | |End Function";

Причина 2: Блокировка файла процессом 1С

Проанализируем механику записи XML. В 1С для этого обычно используются объекты ЗаписьXML. Если после завершения записи не был вызван метод Закрыть(), файл остается захваченным процессом rphost.exe. При попытке копирования через FileSystemObject операционная система откажет в доступе, так как дескриптор файла не освобожден.

Посмотрим на правильную последовательность действий в 1С:

Запись = Новый ЗаписьXML;
Запись.ОткрытьФайл(ПутьКФайлу);
// ... логика записи данных ...
Запись.Закрыть(); // Обязательный шаг перед копированием!

Причина 3: Фильтрация расширений (FSRM и Антивирусы)

Почему же .txt проходит? В системном администрировании существует роль FSRM (File Server Resource Manager). Она позволяет блокировать запись определенных типов файлов в сетевые папки. Часто администраторы разрешают текстовые логи, но запрещают структурированные данные (XML, скрипты, исполняемые файлы) для защиты от вирусов-шифровальщиков.

Также стоит проверить антивирус на сервере. XML-файл подвергается более глубокому анализу (парсингу) со стороны защитных систем. Если антивирус считает операцию подозрительной (скрипт MSScriptControl пытается записать .xml на удаленный ресурс), он может заблокировать именно эту операцию, игнорируя при этом простые .txt.

Рекомендуемое решение через встроенные функции 1С

Использование MSScriptControl.ScriptControl для копирования файлов в современной платформе 8.3 избыточно и потенциально небезопасно. Платформа обладает мощным встроенным функционалом, который работает стабильнее и прозрачнее для системы прав. Рассмотрим использование метода КопироватьФайл().

Преимущество этого метода в том, что он выполняется в контексте сервера 1С напрямую, без создания дополнительных COM-объектов. Посмотрим на пример реализации:

&НаСервере
Процедура СкопироватьФайлНаСервер(ЛокальныйПуть, СетевойПуть)
    
    // Используем UNC-путь для сетевого назначения
    ИмяФайлаПриемника = "\\192.168.1.100\Public\Import\data.xml";
    
    Попытка
        КопироватьФайл(ЛокальныйПуть, ИмяФайлаПриемника);
        ЗаписьЖурналаРегистрации("КопированиеФайла", УровеньЖурналаРегистрации.Информация, , , "Файл успешно скопирован");
    Исключение
        ИнформацияОбОшибке = КраткоеПредставлениеОшибки(ИнформацияОбОшибке());
        ЗаписьЖурналаРегистрации("КопированиеФайла", УровеньЖурналаРегистрации.Ошибка, , , ИнформацияОбОшибке);
        ВызватьИсключение "Не удалось скопировать файл: " + ИнформацияОбОшибке;
    КонецПопытки;
    
КонецПроцедуры

Диагностика прав доступа

Если даже встроенная функция выдает ошибку доступа, выполним следующую проверку:

1. Выясним, от какого пользователя запущена служба "Агент сервера 1С:Предприятия" (обычно это USR1CV8).
2. Перейдем к целевой сетевой папке на сервере-приемнике.
3. В свойствах папки на вкладке "Безопасность" (Security) проверим, есть ли у пользователя USR1CV8 права на "Запись" и "Изменение".
4. Важно: если сервер 1С и файловый сервер находятся в разных доменах или рабочих группах, права нужно настраивать для конкретного сетевого пользователя, чьи учетные данные известны обоим серверам.

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

Итоги и рекомендации

Для стабильной работы системы придерживаемся следующих правил:

• Отказ от VBScript: Используйте встроенную функцию КопироватьФайл(), она более предсказуема в среде 1С.
• Только UNC-пути: Забудьте про буквы дисков (Z:, W:) в серверном коде. Только \\Server\Folder\file.xml.
• Контроль закрытия файлов: Всегда проверяйте, что ЗаписьXML или ТекстовыйДокумент закрыты перед попыткой их перемещения.
• Проверка прав службы: Убедитесь, что именно пользователь службы 1С (а не вы лично) имеет доступ к сетевой шаре.

Соблюдение этих правил позволит избежать большинства проблем с правами доступа при работе с внешними файловыми ресурсами.