在服务器之间复制文件时出现 SSIS 文件系统任务错误

Question

I can copy files between two servers say Server A and Server B manually and I have permissions to folders on either side.

I am using File System Task to Copy files.

When my Source and Destination are within the Server the Package works fine in visual studio as well as SSISDB.

When my Source and Destination are in different Servers the Package works fine in visual studio but package fails in SSISDB. It is saying access is denied. My Account is mapped to SSISDB.

Any idea to solve this issue.

The package runs fine using the the SQL Server Agent JoB. The job is run through the proxy account.

Any way we can configure Package to Run through proxy account.

Error Screenshot

Answer 1

First of all @Nick.McDermaid provided a very helpful link in the comments to learn more on Which user credentials does Integration Services Catalog use to execute packages?

Suggested Solutions

After searching there are many issues that may causes this problem, so i will provide many solutions that can solve your problem.

When Running package SSISDB

1. SQL Server Accounts Permissions

Add Read & Write permissions to the The account you are logged in on the specified paths

2. Add a windows authentication to the Network account

You can add a Windows authentication login for the network account (used as proxy in sql server agent) and run the package using it.

When Running package from SQL Agent

This is not your case, but these infos may helps

1. SQL Server Accounts Permissions

Add Read & Write permissions to the following accounts on the specified paths:

• NT SERVICE\\SQLSERVERAGENT
• NT SERVICE\\MSSQLSERVER

2. Setting up a Proxy

You can setup a proxy for the SSIS package and run the job using that proxy account.

You can refer to one of the following links to learn more:

• Running a SSIS Package from SQL Server Agent Using a Proxy Account
• Setting up a Proxy Account to run SQL Server Integration Services (SSIS) 2012 packages

3. Map Network Drives to SQL Server instance

Some articles suggests to map the network drives you are using on SQL Server (not the OS).You can refer to one of the following links to learn more:

• Make Network Path Visible For SQL Server Backup and Restore in SSMS
• Configure Network Drive Visible for SQL Server During Backup and Restore Using SSMS

4. Adding SysAdmin Role

Add SysAdmin Role to the following accounts:

• NT SERVICE\\SQLSERVERAGENT
• NT SERVICE\\MSSQLSERVER

Other Links having Similar issue

• Access denied when trying to run an agent job
• How to resolve SSIS access denied error in SQL Server Management Studio
• Can't access a network share when executing a package from the SSIS Catalog
• "Access to the path is denied" error in SSIS package
• File system task error ; Access to the path " " is denied
• [File System Task] Error: An error occurred with the following error message: "Access to the path is denied."
• Access To The Path Is Denied Error
• File system Task -copied from one folder to another folder get the error - Access path is denied

Answer 2

Have you looked at permissions on MSDB for your domain account. I would follow these steps. I have had similar issue

1) deploy the package in server ( as you have already done)

2) Ensure packages are Loaded and Available in Integration Services Catalogs Under SSISDB

3) Redeploy the project and try it.

If these all fine, still package failing in SSISDB, i would try windows scheduler task with CMD (DTEXUI/ File/'Package Path'). Apologies if it isnt relevant talking about windows scheduler.

Answer 3

I ran onto a similar issue some time ago : I had to copy files from a server to the one executing SSIS before loading them.

If the package was configured to use only local directories, it worked every time. If I launched it manually, it worked with different machines. But when it came to SQL Agent + different machines, it failed.

I figured it was a problem with local and AD accounts by crawling through SQL logs and a bit of scripting in Visual Studio.

I solved this issue by :

1. creating a non interactive user account that I granted enough on the SSIS machine (more or less sysadmin on SQL Server, a very few folder access on server... fit to your needs)
2. granting this account to have access to the other server's folder (through ACL)
3. updating my SQL Agent service to use this "legal" AD account
4. done !

This has been working every day since almost a year without a single problem.

Answer 4

There are a lot of guesses and red herrings in the answers and comments posted. It has nothing to do with SQL Agent proxies, mapped drives, MSDB or sysadmin. As eventually gleaned from your question, the execution in SQL Agent is fine, it's just when you run it interactively by right clicking in the Integration Services catalog that the issue occurs.

The final part of your question indicates the root cause is understood here:

Any way we can configure Package to Run through proxy account.

The interactive user (the one right clicking on the catalog) doesn't have rights and you need a way to run from the catalog as a different user that does have rights.

Just for confirmation: if you click View Context in your SSIS log it will show you which user it ran as, which will be different to the successful package executions from SQL Agent.

I dug around the execution and configuration menus in the catalog as well as the create_execution sp, and I don't see any way to run it as a different user.

I have two suggestions:

1. Use Run As when starting SSMS and run as a different user
2. Just wrap the package up in a SQL Agent, which allows you to use other accounts to run the package (either the SQL Agent service account or a proxy)

Answer 5

I got a similar error. Trying to move the file from one folder to another using File System task and got the following error message and

Solution: Create Connection manager to point to the Source file location and Create a variable named "DesVariable" to show the destination file path(eg) C:\\abc. In the File system, Task properties set the following

IsSourcePathVariable: False SourceConnection : SourceFileConnectionManager

IsDestinationPathVariable: True DestinationVariable: DesVariable

Then it went through

[Move/Copy file-file system task properties]

FileSystemTask properties