SQL Server Backup Device Access Denied – 3 Fixes That Work

Why This Error Happens

You try to backup a database in SQL Server. You get: Cannot open backup device 'C:\Backups\mydb.bak'. Operating system error 5(Access is denied.)

I know this error is infuriating. I've seen it on SQL Server 2016, 2019, and 2022. It always means the SQL Server service account can't write to that folder. But the fix depends on why it can't.

Let's fix it step by step. Stop after each fix and test.

Fix 1: The 30-Second Check – Is the Path Correct?

This one trips up everyone. You think the path exists, but maybe you typed it wrong. Or the drive letter is different on the server.

1. Open File Explorer on the SQL Server machine (not your local PC).
2. Go to the folder you specified in the backup command. For example, C:\Backups.
3. Check that the folder exists and you can create a file there manually (right-click → New → Text Document).
4. If the folder doesn't exist, create it. Or fix the backup path to an existing folder.

That's it. 30 seconds. If the path is wrong, you're done. If not, move on.

Fix 2: The 5-Minute Fix – Grant Folder Permissions to SQL Server Service Account

Most times, the SQL Server service account just doesn't have write access. Here's how to find which account runs SQL Server and give it permissions.

Step 1 – Find the Service Account

Open SQL Server Configuration Manager (on the server). Go to SQL Server Services. Look for the service named SQL Server (MSSQLSERVER) or something similar, like SQL Server (SQLEXPRESS). In the Log On As column, you'll see the account name. It's often NT SERVICE\MSSQLSERVER or NT AUTHORITY\SYSTEM or a domain user like DOMAIN\sqladmin.

Write down that account name.

Step 2 – Give Permissions to the Folder

1. Right-click the backup folder (e.g., C:\Backups) → Properties → Security tab.
2. Click Edit → Add.
3. Type the service account name from step 1. If it's NT SERVICE\MSSQLSERVER, type exactly that. Click Check Names to verify it resolves.
4. Grant Modify permission (or at least Write).
5. Click OK, OK, and OK again.

Now test your backup. If it works, great. If not, this might be a network path issue or a proxy account problem – see Fix 3.

Fix 3: The 15+ Minute Fix – Check SQL Server Credentials and Network Paths

This is for when you're backing up to a network drive or a UNC path. The service account might not have network access, or you need to use a credential.

Check If It's a Network Path

Your backup path might look like: \\Server\Share\backup.bak or X:\backup.bak where X: is a mapped drive. Mapped drives don't work for SQL Server. Use the UNC path instead.

Grant Network Permissions

1. On the remote server, share the folder and give Modify permission to the SQL Server service account (or the machine account if using LOCAL SYSTEM).
2. Make sure the SQL Server service account has access to the network. If it's NT SERVICE\MSSQLSERVER, it's a virtual account and can't access other machines. You'll need to change the service to run as a domain user, or use a SQL Server Credential.

Use a SQL Server Credential (for network backups)

1. In SQL Server Management Studio (SSMS), connect to the instance.
2. In Object Explorer, expand Security → right-click Credentials → New Credential.
3. Give it a name like BackupNetworkCred. In Identity, type a domain user that has access to the network share. Enter the password.

BACKUP DATABASE YourDB
TO DISK = '\\Server\Share\YourDB.bak'
WITH CREDENTIAL = 'BackupNetworkCred';

This works. I've used it many times.

One More Thing – Check the SQL Server Agent Proxy (if using jobs)

If you're running the backup from a SQL Server Agent job, the job might run under a different account. Open the job step, look at Run as. If it's not the SQL Server service account, that account needs folder permissions too.

When All Else Fails

Restart the SQL Server service. Yes, really. Sometimes permissions don't refresh until the service restarts. I've seen it happen in SQL Server 2017. Just restart and try again.

If none of these work, check the Windows Event Viewer (Application log) for more details. The error there might say something like 'Access denied for user X' that points you to the exact account.

You can beat this. Start with Fix 1, then Fix 2, then Fix 3. Most people stop at Fix 2.