July 21, 2022 at 1:38 pm
I'm in the process of converting from package deployment to project deployment and running some issues that seem to be related to security and active directory shares. I had expected that if I executed the package directly from the catalog, my userid and privileges would be used, while if the package was invoked from a job, the sqlserver agent service id and its privileges would be used.
When a package is directly executed from the catalog (right click – execute) , it will fail when attempting to write to network shares I can control with an Access to path Denied message.
When it is run as a job, and the job step specifies that the package execute as the sql server agent service id, it will get an access to path denied when trying to write to a network share that already has granted full control to the sqlserver agent service id. (but if the file is written to a folder on the ETL server, then copied to a network share, it has no problem)
Any idea what is happening here? Is there a phantom user id in the mix here somewhere?
thanks
Luther
July 22, 2022 at 2:10 pm
Thanks for posting your issue and hopefully someone will answer soon.
This is an automated bump to increase visibility of your question.
Viewing 2 posts - 1 through 1 (of 1 total)
You must be logged in to reply to this topic. Login to reply