Skip to main content

NinjaOne Backup — SMB Credentials Rejected (System Error 86) Despite Correct Password: LmCompatibilityLevel / NTLMv2

Audience: T1 / T2 Use when: A NinjaOne backup to a NAS fails with a credential/authentication error, and manual SMB testing from the affected server returns "System error 86 has occurred. The specified network password is not correct" — but the same credentials work from another machine and/or from the NAS web UI.

This is not a wrong-password problem and not a NinjaOne storage-location problem. The password is correct. The affected Windows server is refusing to send the authentication method the NAS requires. Confirm with the diagnostic step below before changing anything.

What This Error Means

SMB authentication uses NTLM. Windows decides which version of NTLM it will send based on a Local Security Authority (LSA) policy value, LmCompatibilityLevel:

  • Level 2 = "Send NTLM response only" — sends legacy NTLM (NTLMv1-style) only.
  • Level 3+ = "Send NTLMv2 response only" — sends NTLMv2.

Modern NAS platforms (UniFi UNAS / UniFi Drive, and others) require NTLMv2 and reject NTLM-only auth. A server stuck at Level 2 will be rejected at the protocol level with System error 86 even though the password is correct. Other servers on the same VLAN that work fine are already at Level 3.

This is why the failure is per-server, not per-credential: the credential is valid, but the failing server isn't allowed to present it in a form the NAS accepts.

Why This Hides From Normal Troubleshooting

This is an LSA policy, not an SMB client setting. The usual SMB diagnostics do not surface it:

  • Get-SmbClientConfiguration shows signing and guest settings — not the NTLM auth level. It will look clean.
  • net use * /delete (clearing cached sessions) won't fix it — there's nothing wrong with the cached session.
  • Mapping by IP instead of hostname won't fix it — resolution isn't the problem.
  • Re-entering the password won't fix it — the password isn't the problem.

If you've cleared cached credentials, confirmed name resolution, confirmed the account works elsewhere, and you're still getting System error 86 — check LmCompatibilityLevel before anything else.

Diagnostic — Confirm Before Changing Anything

Run on the affected server (CMD or PowerShell):

reg query "HKLM\SYSTEM\CurrentControlSet\Control\Lsa" /v LmCompatibilityLevel

Interpretation:

Result Meaning
LmCompatibilityLevel ... 0x2 Confirmed root cause. Server is NTLM-only; proceed to fix.
LmCompatibilityLevel ... 0x3, 0x4, or 0x5 Already NTLMv2. This is not your cause — stop, do not apply the fix, investigate elsewhere (NAS-side SMB user, share permissions, password mismatch).
Value does not exist / ERROR: ... unable to find Windows default applies (Level 3 negotiate on modern OS). Likely not your cause — investigate elsewhere before forcing a value.

Only proceed to the fix if the query returns 0x2.

Fix

Set the server to send NTLMv2 (Level 3), then reboot. Run in an elevated CMD:

reg add "HKLM\SYSTEM\CurrentControlSet\Control\Lsa" /v LmCompatibilityLevel /t REG_DWORD /d 3 /f

shutdown /r /t 0

After reboot, retest the SMB mount with the NAS File Services credentials (pull the actual credential from IT Glue — do not hardcode):

net use \\<NAS-IP>\<share> /user:.\<fsuser> *

Then re-run the NinjaOne backup job to confirm the credential error clears.

Rollback

If forcing NTLMv2 breaks SMB to some other legacy device this server talks to (a much older appliance that only accepts NTLMv1), restore the prior value. Record the original value from the diagnostic query before changing it. To revert to Level 2:

reg add "HKLM\SYSTEM\CurrentControlSet\Control\Lsa" /v LmCompatibilityLevel /t REG_DWORD /d 2 /f

shutdown /r /t 0

A server needing Level 2 for one device and Level 3 for another is a conflict that should be escalated to T3 — the legacy device is the real problem and the long-term fix is to retire or update it, not to weaken the server's auth.

Compliance Note

Raising LmCompatibilityLevel from 2 to 3 is a hardening change — it forces NTLMv2 and refuses weaker NTLM/LM authentication. This is the correct direction for NIST 800-171 / CMMC environments (identification & authentication controls). There is no compliance downside to applying it. The only risk is the legacy-device operational conflict described under Rollback.

Why Web UI Access Works But SMB Doesn't

On UniFi UNAS / UniFi Drive devices, the web login is a UniFi Identity / UI.com SSO credential. The SMB mount uses a separate File Services credential assigned to the device's local user (default ubnt). These are different auth backends. Successful web login tells you nothing about whether SMB will authenticate — and in the System error 86 case here, SMB does have the right credential but is blocked by the host's NTLM level, not by the credential itself. See UNAS 2 Provisioning (page 2567) for the File Services credential and .\ prefix details.

Back to top