Ошибка файловой системы SSIS при копировании файлов между серверами

Я могу копировать файлы между двумя серверами, скажем, сервер A и сервер B вручную, и у меня есть разрешения на папки с обеих сторон.

Я использую задачу файловой системы для копирования файлов.

Когда мой источник и место назначения находятся внутри сервера, пакет отлично работает в visual studio, а также в SSISDB.

Когда мой источник и место назначения находятся на разных серверах, пакет отлично работает в визуальной студии, но пакет выходит из строя в SSISDB. Он говорит, что доступ запрещен. Моя учетная запись сопоставляется с SSISDB.

Любая идея решить эту проблему.

Пакет отлично работает с помощью агента SQL Server Agent. Задание выполняется через учетную запись прокси.

В любом случае мы можем настроить пакет для прогона через учетную запись прокси.

Скриншот ошибки

введите описание изображения здесь

Ответ 1

Во-первых, @Nick.McDermaid предоставил очень полезную ссылку в комментариях, чтобы узнать больше о Какие учетные данные пользователя использует каталог служб Integration Services для выполнения пакетов?

Предлагаемые решения

После поиска есть много проблем, которые могут вызвать эту проблему, поэтому я предоставил много решений, которые могут решить вашу проблему.

При запуске пакета SSISDB

1. Разрешения учетной записи SQL Server

Добавить разрешения на чтение и запись в учетную запись, на которую вы вошли в систему по указанным путям

2. Добавить проверку подлинности Windows в учетную запись сети

Вы можете добавить учетную запись для проверки подлинности Windows для сетевой учетной записи (используемой как прокси-сервер в агенте sql-сервера) и запустить пакет, используя его.

При запуске пакета из агента SQL

Это не ваше дело, но эти сведения могут помочь

1. Разрешения учетной записи SQL Server

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

  • NT SERVICE\SQLSERVERAGENT
  • NT SERVICE\MSSQLSERVER

2. Настройка прокси-сервера

Вы можете настроить прокси-сервер для пакета SSIS и запустить задание, используя эту учетную запись прокси.

Вы можете обратиться к одной из следующих ссылок, чтобы узнать больше:

3. Карта сетевых дисков для экземпляра SQL Server

В некоторых статьях предлагается сопоставить сетевые диски, которые вы используете на SQL Server (а не в ОС). Вы можете обратиться к одной из следующих ссылок, чтобы узнать больше:

4. Добавление роли SysAdmin

Добавить роль SysAdmin в следующие учетные записи:

  • NT SERVICE\SQLSERVERAGENT
  • NT SERVICE\MSSQLSERVER

Другие ссылки, имеющие аналогичную проблему

Ответ 2

Вы просматривали разрешения для MSDB для своей учетной записи домена. Я бы сделал следующие шаги. У меня была аналогичная проблема

1) развертывание пакета на сервере (как вы уже сделали)

2) Убедитесь, что пакеты загружены и доступны в каталогах служб Integration Services под SSISDB

3) Переустановите проект и попробуйте его.

Если все эти мелкие, все еще пакеты не работают в SSISDB, я бы поставил задачу планировщика Windows с помощью CMD (DTEXUI/File/'Path Path). Извиняюсь, если это не касается разговоров о планировщике окон.

Ответ 3

Я столкнулся с подобной проблемой некоторое время назад: мне пришлось копировать файлы с сервера на тот, который выполняет SSIS, прежде чем загружать их.

Если пакет был настроен для использования только локальных каталогов, он работал каждый раз. Если я запустил его вручную, он работал с разными машинами. Но когда дело дошло до SQL Agent + разных машин, это не сработало.

Я понял, что это проблема с локальными и учетными записями AD, сканируя через SQL-журналы и немного скриптов в Visual Studio.

Я решил эту проблему:

  • создание неинтерактивной учетной записи пользователя, которую я предоставил достаточно на машине SSIS (более или менее sysadmin на SQL Server, очень мало доступа к папкам на сервере... соответствует вашим потребностям)
  • предоставление этой учетной записи доступа к другой папке сервера (через ACL)
  • обновление моей службы SQL Agent для использования этой "юридической" учетной записи AD
  • сделано!

Это работает каждый день, начиная с почти года без каких-либо проблем.

Ответ 4

В ответах и ​​комментариях есть много догадок и красных сельдей. Он не имеет ничего общего с прокси-серверами SQL Agent, подключенными дисками, MSDB или sysadmin. По мере того как вы в конце концов узнали о своем вопросе, выполнение в SQL-агенте прекрасное, это просто, когда вы запускаете его в интерактивном режиме, щелкнув правой кнопкой мыши в каталоге служб Integration Services, что проблема возникает.

В заключительной части вашего вопроса указывается, что первопричина здесь понятна:

В любом случае мы можем настроить пакет для прогона через учетную запись прокси.

Интерактивный пользователь (один щелчок правой кнопкой мыши по каталогу) не имеет прав, и вам нужен способ запуска из каталога как другой пользователь, который имеет права.

Просто для подтверждения: если вы нажмете "Просмотр контекста" в своем журнале SSIS, он покажет вам, с каким пользователем он работал, что будет отличаться от успешных выполнения пакета из SQL-агента.

Я выкопал меню исполнения и конфигурации в каталоге, а также create_execution sp, и я не вижу способа запустить его как другого пользователя.

У меня есть два предложения:

  • Использовать Run As при запуске SSMS и запускаться как другой пользователь
  • Просто оберните пакет в SQL-агент, который позволяет использовать другие учетные записи для запуска пакета (либо учетной записи службы SQL-агента, либо прокси-сервера).

Ответ 5

У меня была похожая ошибка. После того, как я последовал ответу Хади выше, я получил его частично работающим. Задача "Файловая система" работает из NT SERVICE\SQLSERVERAGENT в качестве вызывающей стороны, но не использует мою учетную запись пользователя. Так что я думаю, в любом случае это разрешение вопроса.

Одна не связанная с этим проблема, возможно, только у меня, заключается в том, что я случайно использую Projection.Connections вместо Package.Connections, но развертываю только пакет, а не весь проект. Исправлено, и работа агента SQL Server работала.