Cannot Open Backup Device: Operating System Error 5 (Access Is Denied)

Almost everyone meets this the first time they back up to a network share, and almost everyone spends the first ten minutes checking the wrong account.

The reason it wastes time is that the path usually works fine when you test it yourself. You can browse to it, you can create a file in it, so the permissions look correct. They are correct, for you. The backup is not running as you.

The Thing That Explains Most of These

SQL Server backs up as the service account, not as the person who ran the command. Your own access to that folder is irrelevant.

Find out who is actually being refused:

SELECT  servicename,
        service_account,
        startup_type_desc,
        status_desc
FROM    sys.dm_server_services;

That service_account is the identity that needs permission on the backup path.

A virtual account cannot reach a network share. NT SERVICE\MSSQLSERVER and NT AUTHORITY\SYSTEM present as the machine account when they leave the box, so if you are backing up to \\fileserver\backups, permission has to be granted to DOMAIN\SERVERNAME$, not to a user. That single fact accounts for a large share of these errors.

Confirm It Is Really a Permissions Problem

Operating system error 5 says access denied, but the same Msg 3201 appears with other OS errors that mean completely different things:

Read the number before assuming permissions. OS error 2 on a path you can see in Explorer nearly always means a mapped drive, which is covered below.

Prove It Is the Service Account, Not the Path

Operating system error 5 and operating system error 3 arrive as the same Msg 3201 and need opposite fixes, so the first job is telling them apart. 2 backups of 1 database to 2 paths on SQL Server 2025 CU8: the first folder exists and the service account is denied write on it, the second folder is not there at all.

sys.dm_os_file_exists is the discriminator, and it answers as the service account rather than as you. file_is_a_directory of 1 on the denied folder says SQL Server can see that folder perfectly well, so error 5 is about rights on a path it has already found. file_is_a_directory of 0 with parent_directory_exists of 1 on the second says the folder is simply missing, and no permission change will help. xp_fileexist returned the identical 3 values for both paths, so use whichever you prefer. Neither needs xp_cmdshell.

Msg 3013 follows both failures and is noise. The 3201 line carries the only 2 facts that matter, the path SQL Server actually tried and the operating system error number it got back.

The Fixes, by Cause

Local Path

Grant the service account Modify on the folder, not just Read. A backup writes, and it also has to create the file.

icacls "D:\Backups" /grant "NT SERVICE\MSSQLSERVER":(OI)(CI)M

Use the account sys.dm_server_services reported, not a guess.

Network Share

Two sets of permissions have to agree, and people usually fix only one:

• Share permissions, on the share itself
• NTFS permissions, on the underlying folder

Grant both to the machine account if SQL Server runs under a virtual account (DOMAIN\SQLSERVER01$, note the dollar sign), or to the domain service account if it uses one.

Test it as SQL Server rather than as yourself:

-- Does SQL Server itself think it can see the path?
EXEC master.dbo.xp_fileexist '\\fileserver\backups\test.txt';

A Parent directory exists of 0 means SQL Server cannot see the folder at all, which is a permissions or path problem rather than anything to do with the backup command.

A Mapped Drive That Only You Can See

BACKUP DATABASE [YourDb] TO DISK = N'Z:\Backups\YourDb.bak';

Mapped drives are per user session and SQL Server will not have yours. Z: exists for you and does not exist for the service. This gives OS error 2 or 3 rather than 5, which is the giveaway.

Always use the UNC path, never a drive letter:

BACKUP DATABASE [YourDb] TO DISK = N'\\fileserver\backups\YourDb.bak';

It Worked Yesterday and Fails Today

Three things change underneath a working backup job:

• The service account password changed, or the account was locked, so it can no longer authenticate to the share
• Antivirus started scanning the backup folder. This shows as OS error 32, and backup folders should be excluded from real-time scanning anyway
• The share was recreated, which resets share-level permissions even when NTFS permissions survive

Stopping It Recurring

• Exclude backup folders from antivirus. It causes intermittent failures that are miserable to diagnose precisely because they only happen sometimes.
• Use UNC paths in every backup job, so nothing depends on a drive mapping that exists in one session.
• Grant to a group, not to the account. When the service account changes you change one group membership rather than hunting every folder.
• Alert on backup age, not on job failure. A job that fails and is retried by hand still leaves a gap if nobody notices.

Common Questions

Related Scripts

• Cannot Bulk Load, Access Is Denied (Error 4861), the same service-account lesson when the folder in the message is an import folder, not a backup folder
• Get Backup Coverage, which databases have no recent backup at all
• Backup Failed or the Restore Is Stuck, the router for when the message is not 3201 at all
• Get Backup Chain Integrity, find the gaps before you need them
• Get Last Database Backup Times
• SQL Agent Job Failed: Finding the Step That Actually Broke, the router for when this turned up in a job step rather than in your own session
• Database Cannot Be Opened, It Is in the Middle of a Restore