Fix STATUS_WRONG_PASSWORD_CORE (0XC0000149) on SMB Connections

What's Actually Happening Here

The error 0XC0000149 — STATUS_WRONG_PASSWORD_CORE — means Windows sent a password to a LAN Manager 2 server, and the server rejected it. But here's the kicker: your password might be fine. What's actually happening is a version mismatch in the authentication protocol. Modern Windows (10, 11, Server 2016+) defaults to NTLMv2, but the server only speaks older LM or NTLMv1. Or worse, you've got a stale cached credential that's corrupted or expired.

I've seen this most often when someone maps a network drive to a legacy NAS (think Synology DSM 5.x or an old Buffalo Terastation) and the password changed on the server side but Windows never updated its cache. Also happens connecting to Windows Server 2003 shares from Windows 10 — that's a classic.

Here's the fix tree. Start at the top. Stop when the share mounts.

Fix 1: Clear Stored Credentials (30 seconds)

This is the simplest fix and it works about 40% of the time. Windows caches your network passwords in the Credential Manager. If the password on the server changed, or the cached hash got corrupted, you'll get this exact error even when typing the right password fresh.

1. Open Control Panel → Credential Manager (or search "credential manager" from Start).
2. Click Windows Credentials.
3. Look for entries related to the server you're connecting to — they'll be named like TERMSRV/servername or just the server's IP/hostname.
4. Click the arrow to expand, then Remove.
5. Restart File Explorer (or just reboot — faster).
6. Try connecting again from \server\share.

Why this works: Old credentials are stored as CRED_TYPE_DOMAIN_PASSWORD and include the password hash. If the stored hash uses a different LM hash format than the server expects, you get the mismatch. Deleting the entry forces a fresh NTLM handshake.

If that didn't fix it, move on.

Fix 2: Force NTLMv2 in Registry (5 minutes)

Windows 10 version 1803 and later, plus Windows 11, ship with NTLMv2 only by default. But some older LAN Manager 2 servers — especially Samba-based ones pre-4.0 — don't negotiate NTLMv2 properly. They see the NTLMv2 response and just reject it as a bad password. What we need to do is tell Windows to also try NTLMv1, which those servers understand.

Important: This reduces security. NTLMv1 is vulnerable to relay attacks. Only do this on a machine that's on a trusted network or behind a firewall. If this is a production server, push for an SMB upgrade instead.

Open Registry Editor (regedit) as Administrator. Navigate to:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa

Look for a DWORD called LMCompatibilityLevel. If it's not there, create it. Set the value to 1 (send NTLMv1 if server requests it, but use NTLMv2 by default).

If you already see a value of 3 or higher — that means NTLMv2 only. Drop it to 1.

Reboot. Try the connection again.

The reason this works: LMCompatibilityLevel controls the negotiation. At level 1, Windows still offers NTLMv2 first, but if the server responds with "I don't understand that, send LM" it falls back to NTLMv1. Without this fallback, the server just aborts with 0XC0000149.

Still broken? We go deeper.

Fix 3: Disable SMB Signing & Enable LM Hash Fallback (15+ minutes)

This is for the stubborn cases where the server is ancient — maybe Windows NT 4.0 or a very old Samba 2.x box. These servers require LM authentication, which Windows stopped sending by default in 2015. The fix involves two registry changes.

First, let's check if SMB signing is causing problems. The server might require signed packets but your client isn't offering, and the negotiation fails before authentication even completes. Open Group Policy Editor (gpedit.msc) or regedit:

Navigate to:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanWorkstation\Parameters

Set RequireSecuritySignature to 0 (disable required signing — we'll still use it if the server offers). Set EnableSecuritySignature to 1 (offer to sign, but don't require).

Second, enable LM hash storage. This is controversial — Microsoft disabled it by default for good reason. But if the server demands LM, you need it. Open Command Prompt as Administrator and run:

reg add HKLM\SYSTEM\CurrentControlSet\Control\Lsa /v NoLMHash /t REG_DWORD /d 0 /f

Then set LMCompatibilityLevel to 0 (send LM & NTLM — never use NTLMv2). Yes, this is as insecure as it sounds. Only do this on a machine that's isolated on a VLAN.

Reboot. Test.

Why this fix works for the hard cases: Older LAN Manager 2 servers don't even know what NTLMv2 is. They send a challenge, expect an LM response back, and if they get anything else they return STATUS_WRONG_PASSWORD_CORE as a catch-all. By disabling LM hash blocking and dropping the compatibility level to 0, you're literally speaking the server's language. The reason step 3 works when step 2 didn't is that some servers don't even understand NTLMv1 negotiation — they want raw LM.

When to Give Up and Use a Different Protocol

If none of these work, the server likely has a dead NTLM implementation. Maybe its time sync is off by minutes (Kerberos-adjacent fail), or its SMB stack is completely busted. I've seen this on old QNAP NAS firmware from 2012.

Your options:

• Use FTP — if the NAS supports it. Simple, no auth drama.
• Use SSHFS — if you're on Linux or use WinFsp on Windows. Authenticates via SSH keys, no LM nonsense.
• Upgrade the server — if it's a Windows box, install at least Server 2008 R2. If it's a NAS, update the firmware.

But honestly, if you got this far and it still doesn't work, the problem is almost certainly the server refusing to authenticate on principle. No registry hack on the client can fix a broken server SMB implementation.