Skip to main content

NinjaOne Backup — Error 315: NAS Authentication Failed

Audience: T1 / T2 Use when: Backup fails with "Error 315: Credentials failed when authenticating to Network Storage device," or any NinjaOne backup alert reading "credentials invalid" against a NAS target.

What This Error Means

Lockhart reached the NAS (network connectivity is fine) but the NAS rejected the authentication attempt. The credentials stored in NinjaOne's backup storage location don't match what the NAS currently requires.

Most Common Causes

Cause Signal
NAS encrypted volume is locked after a reboot — check this first NAS rebooted recently (power event, firmware update); NAS web UI is up but the share is unreachable; credentials in IT Glue are unchanged
dtcbackup password was changed on the NAS but not updated in NinjaOne Error started after a NAS password rotation
dtcbackup account was deleted or disabled on the NAS Account doesn't appear in NAS user list
NAS was factory reset — cleared all local accounts All NAS settings reset
NAS was replaced with a new unit New NAS, no dtcbackup account created yet
SMB authentication negotiation failure (version mismatch) Connectivity works but auth fails even with correct credentials

Step 0 — Check the NAS Volume Is Unlocked (Encrypted NAS) — Do This First

Some client NAS units encrypt the backup volume. After any reboot, an encrypted volume stays locked until someone unlocks it — and while it's locked, the share doesn't exist, so Lockhart's failed connection surfaces as a credentials error even though the stored credentials are fine. Resetting credentials here wastes time and fixes nothing.

  1. Log into the NAS web UI and check volume/storage status. A locked encrypted volume shows as locked/not mounted while the NAS itself is otherwise up.
  2. If locked: get the volume encryption password from IT Glue for that site's NAS (e.g., the "UNAS-2 Encryption" entry) — this is a separate credential from the dtcbackup account.
  3. Unlock the volume, confirm the backups share is reachable again, and trigger a manual backup run. Done — do not touch the NinjaOne storage location credentials.

Platform behavior:

Platform Behavior after reboot
UniFi UNAS (UNAS Pro / UNAS 2) No auto-unlock exists. Encrypted volumes must be manually unlocked after every reboot. Any reboot of the unit will re-trigger this alert until someone unlocks it.
QNAP QTS Supports auto-unlock of encrypted volumes on boot. DTC allows enabling auto-unlock on QNAP backup targets — turn it on so reboots don't silently take down backups.

If the site's NAS is a UNAS with an encrypted volume, note it on the client's IT Glue/Halo asset so the next tech checks this before credentials.

Step 1 — Test Authentication Manually

# Try to map the share with dtcbackup credentials
# Replace with actual NAS hostname and the dtcbackup password from IT Glue
net use \\NAS-HOSTNAME\backups\ninjaone /user:dtcbackup [password]

# If "Access denied": credentials are wrong or account is locked/deleted
# If "Network path not found": connectivity issue (different problem — see Error 316)
# If it works: credentials are fine — the issue is with how NinjaOne stored them

Step 2 — Verify dtcbackup Account on the NAS

Synology DSM:

  1. Control Panel → User & Group → Users tab
  2. Find dtcbackup — confirm it exists, is not disabled, and is not expired
  3. Check the account's share permissions: it should have Read/Write on backups

QNAP QTS:

  1. Control Panel → Privilege → Users
  2. Find dtcbackup — confirm active
  3. Check Shared Folder Permissions for backups — should be Read/Write

Step 3 — Update Credentials in NinjaOne

If the password was changed on the NAS or a new NAS was set up:

  1. NinjaOne → Administration → Organizations → select the client org
  2. Org settings → Backup → Storage Locations
  3. Click the storage location → Edit
  4. Update the Username and Password fields with the current dtcbackup credentials
  5. Save
  6. Trigger a manual backup run

Step 4 — Recreate the dtcbackup Account (If Deleted)

If the account was removed:

Synology:

  1. Control Panel → User & Group → Create
  2. Username: dtcbackup, password per DTC credential standard
  3. Do NOT add to the administrators group
  4. Shared Folder Permissions: Read/Write on backups only
  5. Update NinjaOne storage location credentials (Step 3)

QNAP:

  1. Control Panel → Privilege → Users → Create
  2. Same naming and permission structure

Step 5 — SMB Version Check (If Credentials Are Correct But Auth Still Fails)

If credentials are verified correct but Error 315 persists, the issue may be SMB authentication negotiation:

# Check SMB negotiation with NAS
Get-SmbConnection | Where-Object {$_.ServerName -like "*NAS*"} | Select ServerName, Dialect, UserName

# If Dialect is 1.0 on a Windows Server 2016+ device: SMBv1 authentication behavior may differ
Get-SmbServerConfiguration | Select EnableSMB1Protocol, EnableSMB2Protocol

Update NAS firmware to support SMBv2/v3 if SMBv1 mismatch is the cause.

If net use returns "System error 86 — the specified network password is not correct" (not Access Denied), the password is verified correct, and the same credential works from another machine: this is an NTLM auth-level (LmCompatibilityLevel) problem on the affected server, not an SMB dialect issue and not a NinjaOne credential issue. See NinjaOne Backup — SMB Credentials Rejected (System Error 86): LmCompatibilityLevel / NTLMv2.

Back to top