Complete Fix to Solve SQL Server Backup Access Denied

A “SQL Server backup access denied” error can derail data protection efforts, especially when maintaining High Availability (HA) and integrity is critical. Across SQL Server 2019, 2022, and older versions, error 5—often tied to this access issue—typically stems from insufficient permissions for the SQL Server service account. If you’re seeing this error (or error 5) in SSMS or SQL Agent logs, Windows is blocking the write request.

This guide breaks down root causes and actionable fixes to resolve the issue. You’ll learn to configure service accounts, manage NTFS permissions, and navigate network security to avoid repeated backup access issues.

Top Causes of SQL Server Operating System Error 5

While there are several technical nuances, most access denied issues boil down to simple permission gaps. Here are the primary reasons you are seeing SQL Server backup error 5 access denied:

• Insufficient Folder Permissions for SQL Service Account: The #1 cause. The account running SQL Server lacks “Write” or “Modify” NTFS permissions for the backup target folder.

• Invalid Backup Path: A mistyped or deleted file path prevents SQL Server from writing the .bak file, triggering error 5.

• Unsupported Network Share Access: Local SQL service accounts (e.g., NT Service\MSSQLSERVER) can’t authenticate to network shares, leading to backup access denied errors.

• UAC/Windows Security Restrictions: Strict UAC or Group Policy settings block the SQL process from accessing protected folders.

• Security Software Blocking: Antivirus/ransomware tools may flag large .bak files as threats, locking them and causing error 5.

• Incorrect Remote Path Usage: Using your local device’s file path (not the server’s) for remote backups results in access failure.

• SQL Agent Account Mismatch: Scheduled backups fail if the SQL Agent account has fewer permissions than the SQL Database Engine account.

• Locked File During Restore: Restoring over an existing database file locked by another process triggers permission denied errors.

Step-by-Step Solutions (With Commands & Screenshots)

To fix SQL Server backup access get denied errors (including error 5), align Windows security settings with SQL Server’s requirements. Below are actionable fixes for the most common issues, starting with the top cause: missing folder permissions.

Fix 1 – Grant Permissions to SQL Server Service Account

Most backup access denied issues of SQL Server occur because the SQL Server service account lacks write permissions to the backup folder. Follow these steps to resolve it.

1. Open SQL Server Configuration Manager.
2. Click on SQL Server Services in the left-hand navigation pane.
3. Identify the Log On As account for your specific instance (e.g., NT Service\MSSQLSERVER or a domain user like CORP\sql_svc). Keep this name handy, as this is the “user” that needs permission.
4. Open Windows Explorer and navigate to the folder where you want to save your backups.
5. Right-click the folder, select Properties, and navigate to the Security tab.
6. Click Edit, then click Add and type the exact service account name, then click OK.
7. Check the box for Full Control (or at minimum, Modify) and click Apply.
8. To ensure these permissions apply to all future backup files and subdirectories, I recommend running this icacls command in an elevated Command Prompt:

:: This ensures the SQL account has full rights and that new files inherit those rights.

:: Replace C:\SQLBackups and NT Service\MSSQLSERVER with your specific details.

icacls "C:\SQLBackups" /grant "NT Service\MSSQLSERVER":(OI)(CI)F /T

By completing these steps, you resolve the core permission gap that triggers the backup access denied error. If you recently changed your service account, don’t forget to restart the SQL Server service for the new security token to take effect.

Fix 2 – Backup to a Local Drive First

If you are receiving the access denied message while trying to back up to a network share or a mapped drive, the problem often lies in how Windows handles network authentication for services. In my experience, “Operating System Error 5” frequently occurs because the SQL Server service account lacks the “network token” required to access another machine.

To isolate whether the issue is the network or the folder permissions, follow this sequence:

1. Create a new folder directly on the server’s local C: or D: drive (e.g., C:\LocalBackupTest).
2. Assign “Full Control” permissions to the SQL Server service account for this local folder using the icacls method from Fix 1.
3. Execute a T-SQL backup command manually in SQL Server Management Studio (SSMS) to this local path to see if the engine can write locally:

-- Test backup to local drive to bypass network permission issues

BACKUP DATABASE [YourDatabaseName]

TO DISK = 'C:\LocalBackupTest\Test.bak'

WITH INIT, STATS = 10;

GO

4. Confirm the result: If this local backup succeeds, you have proven that the SQL Server engine is healthy, and the SQL Server backup access denied error is related to your network configuration.
5. Avoid mapped drives: If you were using a drive letter like Z:\, switch to a UNC path (e.g.,  \\ServerName\BackupShare\). Mapped drives are session-specific and invisible to the SQL Server service account, which triggers immediate access denied errors.

Fix 3 – Configure Network Share Access (NAS/SMB)

Resolving the backup database access denied errors for network shares (NAS/SMB) requires checking two permission layers: Share Permissions and NTFS Permissions. Many DBAs overlook Share Permissions (even with correct NTFS settings), so follow these steps to configure access properly:

1. Verify the Service Account Type: Ensure your SQL Server service is running under a Domain Account (e.g., CORP\sql_svc) or a Managed Service Account (gMSA).
2. Avoid LocalSystem/NetworkService for Network Backups: Don’t use the LocalSystem account for backups to a remote share. LocalSystem has no credentials to access resources outside the local machine, which is a guaranteed way to trigger SQL Server backup error 5 access denied.
3. Configure Share Permissions: On the remote server hosting the share, right-click the folder → Properties > Sharing > Advanced Sharing > Permissions. Add the SQL Server service account and grant it Change and Read permissions.
4. Configure NTFS Permissions: On the same remote folder, go to the Security tab. Add the SQL Server service account and grant it Modify or Full Control. Remember: The most restrictive permission wins between Share and NTFS.
5. Use Universal Naming Convention (UNC) Paths: In your backup script, always use the format \\ServerName\ShareName\Folder\Backup.bak.
6. Test Access via T-SQL: Run the xp_cmdshell (if enabled) or a DIR command to see if the SQL engine can see the path:

-- Check if SQL Server can see the network directory

EXEC xp_cmdshell 'dir "\\RemoteServer\BackupShare\"';

GO

Fix 4 – Change SQL Server Service Account Safely

Sometimes, the quickest way to resolve a access denied error—especially when dealing with complex network environments—is to change the SQL Server service account to a dedicated domain user. If your SQL engine is currently running as LocalSystem or NT Service\MSSQLSERVER, it effectively has “no ID” when it tries to talk to other servers or specific secured drives.

Changing the account is a standard procedure, but doing it incorrectly can lead to service start failures. Follow this sequence to change the account safely:

1. Open SQL Server Configuration Manager. Don’t use the standard Windows Services app (services.msc) to change SQL accounts, as it won’t correctly update the underlying security dependencies and registry keys.
2. Locate “SQL Server Services” in the left sidebar and find your instance in the list.
3. Right-click the service (e.g., SQL Server (MSSQLSERVER)) and select Properties.
4. Go to the “Log On” tab. Select “This account” and enter the credentials for a dedicated domain user account (e.g., YOURDOMAIN\sql_backup_svc).
5. Enter the password and click OK. Configuration Manager will automatically grant this new account the necessary local rights to run the database engine.
6. Restart the service when prompted.
7. Re-run your backup. Since you have assigned a specific identity to the engine, you can now easily grant this user “Full Control” on any local or network folder.

Fix 5 – Run SQL Agent Jobs Without Permission Errors

A common DBA frustration: Manual SSMS backups work, but scheduled SQL Agent jobs fail with the backup access denied error of the SQL Server. This happens because manual backups use your Windows identity, while scheduled jobs use the SQL Server Agent service identity—often different from the SQL Database Engine account. Follow these steps to fix SQL Server backup error 5 for scheduled jobs:

1. Check the SQL Agent Service Account: Open SQL Server Configuration Manager and note the “Log On As” account for SQL Server Agent (it’s often different from the Database Engine account).
2. Grant Permissions to the Agent Account: Navigate to your backup folder properties (as in Fix 1) and ensure the SQL Server Agent account has “Modify” or “Full Control” permissions.
3. Verify Job Step Owner: In SSMS, go to SQL Server Agent > Jobs. Right-click your backup job > Properties > General tab. Check the Owner—if it’s a local user without backup path access, the job may fail.
4. Align Proxy Account (Optional): If using a Proxy Account for job steps, ensure that the proxy identity has NTFS permissions on the target backup folder.
5. Restart SQL Agent Service: If you updated the Agent service account or its AD group memberships, restart the service to activate the new security token.

Fix 6 – Resolve Antivirus/Ransomware Blocking

Even with correct account permissions, SQL Server Operating system error 5 might stem from antivirus (AV), EDR, or ransomware protection tools. These tools may flag sqlservr.exe’s large .bak file writes as suspicious activity. Follow these steps to resolve the issue:

1. Check Security Logs: Review logs in your AV/EDR tool (e.g., Windows Defender, CrowdStrike) for entries where sqlserver.exe was blocked from writing to your backup directory.
2. Exclude the Backup Directory: Add your backup folder (e.g., D:\SQLBackups) to your security software’s exclusion list to prevent file locking during SQL backup writes.
3. Trust SQL Processes: Add sqlserver.exe and sqlagent.exe as trusted processes to authorize their heavy disk I/O operations.
4. Exclude Backup File Extensions: If allowed by policy, exclude .bak and .trn files from real-time scanning—this fixes errors and boosts backup performance.
5. Adjust Windows Defender’s Controlled Folder Access: Either disable the feature or add SQL Server as an allowed app, as it’s a common cause of unexplained access denied issues.

Fix 7 – Restore Failures (Overwrite/Locked File Issues)

The SQL Server backup access denied errors aren’t limited to backups—they might occur during restores too. This typically happens when the SQL engine can’t overwrite existing .mdf/.ldf files (locked by another process) or lacks “Delete/Modify” permissions for the restore destination folder.

Follow these steps to fix restore-related access denied issues:

1. Validate Destination Folder Permissions: Ensure the SQL Server service account has “Full Control” over the restore destination folder (this is often different from your backup folder).
2. Check File Read-Only Status: If restoring over an existing database, verify the existing .mdf/.ldf files aren’t set to “Read-only” (right-click files > Properties > uncheck Read-only if enabled).
3. Use the WITH REPLACE Clause: For overwriting existing databases, add the REPLACE command in your T-SQL restore script to grant explicit permission to discard old files:

RESTORE DATABASE [YourDB]

FROM DISK = 'C:\Backups\YourDB.bak'

WITH REPLACE, -- Overwrites existing database files

RECOVERY;

4. Relocate Files with WITH MOVE: If the original file path doesn’t exist on the target server, use the MOVE option to redirect .mdf/.ldf files to a valid, permissioned directory (fixes persistent error 5).
5. Close Existing Connections: Release file locks by setting the database to SINGLE_USER mode or taking it offline before restoring—this resolves OS access denials from other applications holding file handles.

Fix “SQL Server Backup Access Denied” Instantly with i2Backup

Manual permission management is a common weak spot in backup strategies, which may trigger errors (like Operating System Error 5). For a long-term fix, use a professional data protection platform like i2Backup—its centralized management and automated security bypass permission gaps that derail backups and restores.

Key Features of i2Backup

• Broad Compatibility: Fully supports SQL Server (and other mainstream databases like Oracle, MySQL) across Windows, Linux, Unix, and virtualization environments (VMware, Hyper-V, etc.) with formal compatibility certifications, ensuring reliable protection in diverse enterprise setups.
• Centralized & Intelligent Management: Built on a distributed architecture, with a user-friendly B/S web interface for centralized control and backup scheduling. Instant alerts and live status updates keep IT teams informed of task progress and system health.
• Streamlined Data Lifecycle Governance: Automates backup, deduplication, tamper prevention, recovery, and secure cleanup; customizable retention policies and smart cleanup reduce operational burden and optimize storage.
• Fast, Flexible Recovery: Enables file-level, point-in-time, and cross-platform restoration (to physical servers, VMs, or cloud); instant VM recovery minimizes downtime; supports bare-metal/cloud recovery with automatic driver installation.
• Comprehensive Monitoring & Reporting: Real-time visibility into backup activities; email and SMS alerts keep administrators updated on task status, ensuring timely response to potential issues.

By centralizing management, automating security, and addressing permission gaps at the source, i2Backup serves as a long-term solution protect your data.

How to Prevent SQL Server Backup Access Denied Errors

Reactive troubleshooting is stressful and risks data loss—proactive management ensures consistent, reliable backup windows. Use these proven strategies to stop SQL Server backup error 5 (Access is denied) from recurring:

• Use a Dedicated Backup Directory: Avoid root drives or system folders. Create a dedicated folder (e.g., S:\SQLBackups) and apply required NTFS permissions for the SQL Server service account upfront. This isolates backup traffic and simplifies security audits.
• Standardize Service Accounts: Skip default accounts like LocalSystem and avoid mixing accounts across instances. Use a single Domain Service Account or Group Managed Service Account (gMSA) for consistent permission application across your entire SQL environment, including network shares.
• Test Backups and Restores Weekly: Unverified backups are useless. Schedule weekly automated jobs to restore a random database to a test environment—this confirms the service account has full read/write permissions and prevents backup access denied errors during emergencies.
• Automate Permission Checks: Use a PowerShell script or T-SQL job (with xp_fileexist) to validate backup directory accessibility before backups run. Set up email alerts for unreachable paths to address issues before backups fail.
• Monitor SQL Agent Failures: Configure Database Mail and SQL Server Agent Alerts for Error 5 and receive instant SMS/email notifications if it occurs, avoiding delays in resolution.

Conclusion

Resolving a SQL server backup access denied error (Operating System Error 5) ultimately comes down to ensuring the SQL Server service account has explicit NTFS and share permissions to your target directory. By identifying your service identity, standardizing your backup paths, and utilizing professional tools like i2Backup, you can eliminate these permission gaps for good.

Don’t wait for a production failure to find a security drift. My final advice is to test your backups and restores weekly to ensure that your permissions remain intact and your disaster recovery plan is truly airtight.