I have an AlwaysOn setup in which the jobs are running on domain service account which have been given access to a file share for backups. The jobs are not able to run.

This is the error message which I get

https://ola.hallengren.com Msg 50000, Level 16, State 1, Server xxxxx , Procedure DatabaseBackup, Line 457 The directory \xxxxxx\backups$ does not exist. Msg 50000, Level 16, State 1, Server HNATLD1SVRLSQ02, Procedure DatabaseBackup,

Should SQL agent account in the configuration manager run on the same account as the job owner or can it run on the NT\service account as shown in the screenshot attached, because the security context is still that of the job owner which has access to those file shares? What would be the best practice here? Please advice.

enter image description here

We have different service accounts running on the jobs

  • Is the owner a member of the sysadmin role? If so, I believe the job will run under the service account and not the context of the user. Commented Nov 11, 2016 at 19:01
  • Yes the job owner has been given sysadmin permissions. So does it mean the SQL agent account can continue to run on the NT\service account? Commented Nov 11, 2016 at 19:15
  • Is the particular job step running through a proxy with appropriate credential?
    – Nic
    Commented Nov 11, 2016 at 19:20
  • So that is probably your issue. Since the owner is a sysadmin, the job is running as NT\service which isn't a domain user with access to that share. A few options: Like to change the service account to a domain user with filesystem perms and sql sysadmin or use a non-sysadmin account as the owner with filesystem perms & appropriate sql perms. Others as well. Commented Nov 11, 2016 at 19:21
  • Yes the service account is a domain account with permission to fileshare and is sysadmin in the server role properties Commented Nov 11, 2016 at 19:28

2 Answers 2


Add a proxy account for Operating System (CmdExec) jobs and run the Ola jobs under that. This way the proxy account can have proper access to only the backup shares, etc. and you don't have to elevate permissions on the SQL Agent account (and inherently any other jobs running under the SQL Agent security context). Principle of Least Privilege for the win! :)

  • Should the service account also have connect and connect to endpoint permission? Because the backups are still not working Commented Nov 14, 2016 at 16:30
  • What's the error you're getting when running the job as the proxy account? Commented Nov 14, 2016 at 17:08
  • The same saying that the directory does not exist Commented Nov 14, 2016 at 17:36
  • The issue is that you're trying to write to an Admin Share (e.g. the $ at the end indicates this is a hidden share only local admins on the destination server can write to). Either setup the proxy account as a local admin on that server (NOT RECOMMENDED) or create a formal file share for the backups and write to that new path. Commented Nov 14, 2016 at 18:04
  • Oh, and no, the proxy account does not need elevated access within the database engine. The account that owns the job is what the job runs as when connecting to the database. The proxy account takes care of the external access. Commented Nov 14, 2016 at 18:05

This is the service account under which the db engine is running. It's a local service account and not a domain account which was used to run those jobs. Guess this was the problem all along

enter image description here

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.