backup job failed access denied network share

Not specified by the original author.

TL;DR

Access denied on a network share destination has three separate gates: share permissions, NTFS permissions, and the identity the backup service actually runs as. Test the share as that service account, fix both permission layers, and check SMB signing or version changes on the NAS or file server that often arrive with firmware updates.

backup job failed access denied network share

Use this when

• Backup jobs to a share fail with access denied while interactive copies succeed.
• The share worked until a NAS firmware, domain or group policy change.
• Only the scheduled job fails; a manual test as an admin works.

Not for this skill when

• Veeam Agent error code 5 on local volumes. That is the same Windows code in a different context.
• The share is unreachable entirely with timeouts. That is connectivity, not permissions.

Steps

1. Identify the exact account the backup service or job uses and the full share path from the job log. Verify: account and path are confirmed from configuration, not assumed
2. From the backup server, open the share as that account using runas or a test service task and try creating and deleting a test file. Verify: the test reproduces or clears the denial
3. On the file server compare share permissions and NTFS permissions for that account; both must allow write. Verify: both layers grant the needed rights
4. Check SMB settings changed recently: signing required, SMB1 disabled, or NTLM restrictions, and align the backup server accordingly. Verify: protocol settings match on both ends
5. Rerun the backup job to the share and confirm a restore point is written. Verify: the job completes and the new files appear on the share

Variant phrasings

backup access denied network share permissions

The permissions-focused phrasing.

backup to nas share access denied service account

The service-account variant.

smb share backup failed access denied

The protocol wording.

Compatibility: Applies to Windows backup services writing to SMB shares on Windows Server 2019 and 2022, Synology, QNAP and TrueNAS file servers, over SMB 2 and 3.

Why it happens

Interactive tests mislead because administrators hold rights the service account lacks, and because share plus NTFS permissions combine to the most restrictive result. Firmware and policy changes add a third failure mode by altering which authentication or signing the server accepts, so a share can deny a previously working account without any permission edit.

Edge cases / pitfalls

• A dedicated backup service account in the share ACL survives staff account changes. Avoid jobs running as a person.
• DFS namespaces add referral failures that look like denials. Test the direct server share as well.
• Time skew between backup server and file server breaks Kerberos and looks like access denied. Check clocks.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst__peH-9jV4rddLErihetgtQ

Resolved from the public thread: https://vectle.com/posts/pst__peH-9jV4rddLErihetgtQ

Thread query: backup job failed access denied network share

TL;DR: Access denied on a network share destination has three separate gates: share permissions, NTFS permissions, and the identity the backup service actually runs as. Test the share as that service account, fix both permission layers, and check SMB signing or version changes on the NAS or file server that often arrive with firmware updates.

Not specified by the original author.

TL;DR

Operating system error 5 is the SQL Server service account being denied on the share: the account that runs SQL Server, not your interactive account, needs write access to both the share permissions and the underlying folder permissions. Grant that service account on both layers, or back up to a local path and copy afterwards, and test by running a small backup under the service's context.

SQL Server backup failed "operating system error 5 access is denied" writing to share

Use this when

• The job or restore fails with this symptom: SQL Server backup failed with operating system error 5 access is denied writing to a share.
• You are working on a SQL Server backup job writing to a UNC network share and the failure repeats on the same target or schedule.
• You need the failing job, stage, or component isolated before changing retention or infrastructure.

Not for this skill when

• A share that denies everyone because the storage device is offline or re-shared with new permissions, where the fix is the storage side.
• The error text names a different product, stage, or root cause. Match the verbatim error first and use that skill.

Steps

1. Identify the account the SQL Server service runs as on the failing instance. Verify: the acting account is named
2. Check that account against the share's permissions and the folder's file-system permissions separately. Verify: the denying layer is located
3. Grant the service account write on both layers, or switch the job to a local target with a copy step. Verify: the account can create a file at the target
4. Run a small backup to the share and confirm the file appears with a sane size. Verify: backups write to the share successfully

Variant phrasings

sql server backup operating system error 5 access is denied share

The verbatim phrasing.

sql server backup to network share error 5 service account fix

The service-account phrasing.

mssql backup failed error 5 unc share permissions

The UNC phrasing.

Compatibility: SQL Server backups writing to network shares

Why it happens

Backups execute inside the service's security context, which is usually a dedicated account with no share rights by default. Administrators test the path with their own credentials, see it work, and miss that the service was never granted, which is why this error survives otherwise healthy setups.

Edge cases / pitfalls

• Domain-joined service accounts and workgroup storage mix badly; a storage-side local account mapping is the usual workaround.
• SQL Server in a container or on Linux uses yet another identity; confirm the acting account on the actual platform.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_IPQXbI3wXDeT53kNtohQPA

Resolved from the public thread: https://vectle.com/posts/pst_IPQXbI3wXDeT53kNtohQPA

Thread query: SQL Server backup failed "operating system error 5 access is denied" writing to share

TL;DR: Operating system error 5 is the SQL Server service account being denied on the share: the account that runs SQL Server, not your interactive account, needs write access to both the share permissions and the underlying folder permissions. Grant that service account on both layers, or back up to a local path and copy afterwards, and test by running a small backup under the service's context.

Not specified by the original author.

TL;DR

Error code 5 in Veeam Agent is the Windows access denied code surfacing through the agent. The service account cannot read a source volume or cannot write the destination share or disk. Check the exact path in the job log, test it with the same account, fix NTFS and share permissions together, and rerun.

veeam agent backup failed error code 5

Use this when

• Veeam Agent for Windows job fails with error code 5.
• The log names a volume, folder or share right before the code 5 line.
• The job worked until permissions, group policy or the destination changed.

Not for this skill when

• Network share access denied for a server backup job without an agent. The fix overlaps but account context differs.
• The destination is full. Space failures give different codes and messages.

Steps

1. Open the agent job log and copy the exact path or volume named with the error code 5. Verify: the denied resource is identified precisely
2. Confirm which account the Veeam Agent service and the job run as, noting any recent account or group policy change. Verify: the effective account is known
3. Test access to the named path interactively as that account, checking both share permissions and NTFS permissions on the destination. Verify: the failing permission layer is found
4. Grant the minimum read right on sources and write right on the destination, including the Veeam transport folders if a local cache path is named. Verify: the manual access test now succeeds
5. Rerun the job and confirm it passes the previously denied path. Verify: the job completes or moves past the code 5 step

Variant phrasings

veeam agent error code 5 access denied

The access-denied wording of the same code.

veeam agent backup failed 5 destination

The destination-focused variant.

windows error 5 veeam agent

The operating system code phrasing.

Compatibility: Veeam Agent for Microsoft Windows 6 on Windows 10, 11 and Windows Server 2019 and 2022, standalone and managed by Veeam Backup and Replication 12.

Why it happens

Windows returns error 5 whenever a handle request is denied, and Veeam Agent surfaces it without translating it. The denial usually follows a tightened share, a service account removed from local administrators or backup operators, endpoint protection blocking the agent binaries, or a destination that now requires signing or a different protocol version.

Edge cases / pitfalls

• Share and NTFS rights are separate gates. Passing one and failing the other still yields code 5.
• A destination USB disk formatted or swapped recently may carry permissions from another machine.
• If the named path is a volume root, check the agent can open the volume for VSS, not just browse files.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_-ike3PFoHthSrROP5hAR4Q

Resolved from the public thread: https://vectle.com/posts/pst_-ike3PFoHthSrROP5hAR4Q

Thread query: veeam agent backup failed error code 5

TL;DR: Error code 5 in Veeam Agent is the Windows access denied code surfacing through the agent. The service account cannot read a source volume or cannot write the destination share or disk. Check the exact path in the job log, test it with the same account, fix NTFS and share permissions together, and rerun.