Skip to main content

NinjaOne Backup — Error 305: Unable to Access Local Storage

Audience: T1 / T2 Use when: Backup pre-flight fails with "Error 305: UNABLE_TO_ACCESS_LOCAL_STORAGE," or a backup hangs / sits in-progress and never completes (see symptom note below).

What This Error Means

NinjaOne can see the storage location is configured (unlike Error 303), but Lockhart cannot actually access it. The storage path exists in NinjaOne's configuration, but the machine running the backup can't read from or write to it.

This is a permissions or connectivity issue — not a configuration gap.

Symptom — hanging backups: A backup that hangs, stalls, or stays "in progress" for far longer than normal and never completes is a common early sign of an inaccessible local storage device (NAS/local share). Lockhart is waiting on a device it can't read from or write to. If you see a stuck/hung backup, treat inaccessible local storage as a leading suspect and work this page's steps — don't just wait for it to clear. (A backup that hangs and then times out mid-job, after the connection was already established, is more likely Error 121: Windows Semaphore Timeout or Error 319: NAS Timed Out — see NinjaOne — Backup Alert Response.)

Most Common Causes

Cause Quick Test
SYSTEM account lacks access to the NAS share Try mapping the share as SYSTEM
NAS share permissions require explicit user authentication Check share ACL on NAS
NAS is offline or unreachable Test-NetConnection NAS-HOSTNAME -Port 445
NAS drive is failing Check NAS SMART status
Wrong UNC path in NinjaOne storage location Compare NinjaOne path to actual NAS share path

Step 1 — Test Basic Connectivity

# Can the device reach the NAS at all?
Test-NetConnection -ComputerName "NAS-HOSTNAME" -Port 445

# Can it access the share path?
Test-Path "\\NAS-HOSTNAME\backups\ninjaone"

If these fail: the NAS is offline or there's a network path issue. Fix connectivity first.

Step 2 — Test SYSTEM Account Access

Lockhart runs as the SYSTEM account. SYSTEM must have explicit read/write access to the NAS share — it does NOT automatically inherit domain permissions.

# Use PsExec to run a command as SYSTEM and test share access
# (Download PsExec from Sysinternals if not present)
psexec -s cmd.exe /c "dir \\NAS-HOSTNAME\backups\ninjaone"

# If access is denied as SYSTEM: the NAS share needs explicit permissions for SYSTEM
# Or: the dtcbackup credentials stored in NinjaOne aren't being passed correctly

Alternative test — check if NinjaOne is passing credentials: The storage location in NinjaOne should use the dtcbackup credential. If the NAS is configured to require explicit authentication (not open to SYSTEM), the dtcbackup credential must be correct. See: Error 315: NAS Authentication Failed

Step 3 — Verify the UNC Path in NinjaOne

  1. NinjaOne → Organization → Backup → Storage Locations → check the configured path
  2. Confirm it matches exactly: \\NAS-HOSTNAME\backups\ninjaone
  3. Check hostname vs. IP — if the NAS hostname changed or DNS is broken, the path may be stale
# Resolve the NAS hostname to confirm DNS is working
Resolve-DnsName "NAS-HOSTNAME"

Step 4 — Check NAS Drive Health

A failing NAS drive can cause 305 if the NAS is online but its storage is degraded:

  1. Log into NAS admin panel (Synology DSM or QNAP QTS)
  2. Storage Manager → HDD/SSD → check SMART status for all drives
  3. Check RAID status if applicable — a degraded RAID can still mount but respond slowly or drop connections

Step 5 — Recreate the Share (If Corrupted)

If the NAS share path exists but is somehow inaccessible:

  1. Delete and recreate the backups/ninjaone folder on the NAS
  2. Re-apply dtcbackup read/write permissions
  3. Update and save the storage location in NinjaOne (even if the path didn't change — this triggers a re-test)
  4. Trigger a manual backup run
Back to top