Problem : SSIS “Access to the path is denied” error?

September 3, 2018

Problem : SSIS “Access to the path is denied” error?

I have created a SSIS package that works just fine from my desktop. I am now testing it by deploying it to the server. The task was imported into the “File System” store. I connected to the SQL Server, from my desktop, with SSMS. I right clicked the package and selected “Execute”  If I just validate the task, it validates without errors. When I go to run the task I get a “Access to the path is denied” error at the start of the first file system task. I am sure it is a permission issue. Based on the info from another thread in another forum:

“Security to network shares is dependent on the user who is running the package. If you are running it yourself, make sure you have permissions to the share. If you are running it from SQL Agent, you might need to use a proxy account (search for SQL Agent Proxy in Books Online) to access it.”

I have some questions:

1. When I select “execute” what account is SQL Server using for permissions for accessing network folders? Is it mine, SQL Server Agent, something else? If it is my account, why would I get an “Access to the path is denied” error?

2. I don’t understand how to use a proxy account, or even if I need one. I assume that when I set the task for scheduling I’ll need one. I read the BOL pages, but I’m still confused as to what I need to set up.

Any info would be greatly appreciated.

Thanks,

 

Solution : SSIS “Access to the path is denied” error?

You are correct, you can use the SQL Server Configuration manager to check what the services are being run as (or use the services in control panel etc). Integration services is most likely to be set up as a local account to the box, Network Service is a common one to be set to. I wouldn’t look at altering it, since that alters it for everything run in that fashion, so not ideal. A network service account can be granted access to a resource, in that you grant that server the resource, but it is less than satisfactory from a security perspective.

When we have put these into production we run them via the SQL Agent, so we get control over the running user and use a proper AD account, making life a lot easier in controlling permissions, as well as being granular to each package, allowing different users per package.