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.