We have a process that runs in SQL Server which executes a DIR command on the local network using a UNC path to check that the files generated by another system are all there, as part of an audit report.

Until this morning all was fine and dandy, we had no issues.

Last night the IT guys tightened up some permissions on the target directories for security.

Now a dir \\server\shared\dir_name fails with an Access is denied error.

We can run this command against the local drive or alternate network UNC paths with no problems.

We have the same issue whether we run from within SQL Server using xp_cmdShell or from the Command Prompt (after logging in to the server with the SQL Server account).

When logged into the server with the account in question, it is possible to browse the network, so Explorer permissions are ok

So it is not related to the SQL Server, nor is it related to the SQL Server Agent account.

It is specific to the rights of one network directory.

We also can no longer use Dir against that network share from our own accounts, even though we are in a domain group that has Full Permissions on the directory!

So what is going on here - is it possible that somehow the Dir command has been blocked on that one directory share for just the SQL Server agent user?


It turns out that it works if we map the drive.

Strange change to network or active directory that means we cannot now use UNC Paths in a DIR command, but the answer was to map a drive letter to the network share then run the process...