SSIS File System Task Error while copying files between servers
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:
- Use Run As when starting SSMS and run as a different user
- 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)
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.
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
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 :
- 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)
- granting this account to have access to the other server's folder (through ACL)
- updating my SQL Agent service to use this "legal" AD account
- done !
This has been working every day since almost a year without a single problem.