STATUS_NULL_LM_PASSWORD (0X4000000D) – LAN Manager fix

You're trying to map a drive to an old NAS or a Windows 7 box, and instead of a connection you get STATUS_NULL_LM_PASSWORD (0X4000000D). I've seen this at least a dozen times—most recently with a client who had a Buffalo LinkStation from 2012 that refused to talk to their Windows 10 Pro machine.

This error comes down to one thing: Windows 10/11 and modern Server editions (2016+) block null LM hashes by default for security. The device on the other end—usually something old—is sending a blank or null LAN Manager password hash. Microsoft decided that's a no-go. The fix is to relax that security setting, but only where it's safe to do so.

Cause #1: LAN Manager authentication level is set too high

The most common cause is the LAN Manager Authentication Level security policy set to Send NTLMv2 response only. Refuse LM & NTLM. This setting is common in hardened environments (think PCI compliance) but it breaks connections to older devices that only speak raw LM.

The fix: Change it to Send LM & NTLM – use NTLMv2 session security if negotiated. That's the second-least restrictive option, and it keeps NTLMv2 negotiation while still allowing LM fallback for old shares.

How to change it (Group Policy)

1. Press Win + R, type gpedit.msc, hit Enter.
2. Navigate to: Computer Configuration → Windows Settings → Security Settings → Local Policies → Security Options.
3. Find Network security: LAN Manager authentication level.
4. Set it to Send LM & NTLM – use NTLMv2 session security if negotiated.
5. Click OK, then reboot or run gpupdate /force.

If you don't have Group Policy (Windows Home), you can do this via registry:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa
Value: LmCompatibilityLevel
Type: DWORD
Data: 1

LmCompatibilityLevel values: 0 (send LM), 1 (send LM & NTLM), 2 (send NTLM), 3 (send NTLMv2 only), 4 (refuse LM), 5 (refuse LM & NTLM). The default on modern Windows is 3. Setting it to 1 usually kills the 0X4000000D error.

Real-world note: Had a dental office last week where their practice management software backed up to a 2008-era LaCie NAS. After a security update, the backup job started failing with this exact error. Setting LmCompatibilityLevel to 1 fixed it instantly. No data exposed—the NAS was on a locked subnet anyway.

Cause #2: Client-side SMB signing or encryption mismatch

Less common, but I've seen it. Some older devices (like early Netgear ReadyNAS units) don't support SMB signing. When Windows 10 1809+ tries to enforce signing, the device sends a null LM hash as part of the negotiation failure, and boom—0X4000000D.

The fix: Disable SMB signing on the client for that connection. You can do this per share or globally. I prefer per-share via registry to avoid weakening security everywhere.

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanWorkstation\Parameters
Value: EnableSecuritySignature
Type: DWORD
Data: 0

Also check RequireSecuritySignature—set that to 0 as well. Reboot the workstation, then try the connection again.

Alternative: Use an SMB 1.0 fallback (not recommended)

If the above doesn't work and the device is ancient (pre-2009), you might need to enable SMB 1.0/CIFS. Go to Control Panel → Programs → Turn Windows features on or off, check SMB 1.0/CIFS File Sharing Support. But only do this as a last resort—SMBv1 is a security hole. I tell clients to replace the hardware instead.

Cause #3: Third-party security software blocking LM hashes

I ran into this one with a customer using an old version of McAfee Endpoint Security. The software was actively stripping LM hashes from the network stack, even though Windows was set to allow them. Took me an hour to figure out. The error log showed 0X4000000D, but the root cause wasn't Windows—it was the security suite.

The fix: Temporarily disable the security software to test. If the error goes away, check the software's settings for something like "Block LAN Manager authentication" or "Secure connection enforcement." Update the software if possible—newer versions usually have an allowlist for legacy protocols.

For McAfee specifically, look under Firewall → IPS Policies → Custom Signature for a rule dropping NetBIOS or SMB packets with null LM hashes. Disable or delete that rule.

Troubleshooting checklist

1. Check the device's firmware. Some old NAS devices got updates that enable NTLMv2. If yours did, you won't need to change anything on the client.
2. Use a network trace. Run Wireshark and filter for smb2 or smb. Look for Status: STATUS_NULL_LM_PASSWORD in the SMB packet details. It'll tell you which side is sending the null hash.
3. Test with a different user account. Domain accounts sometimes bypass this issue due to different credential handling.

Quick-reference summary table

Bottom line: 0X4000000D is almost always a security policy mismatch. Find the device that's sending the null hash, and either update it or relax the client. The registry and Group Policy changes above are safe for isolated or legacy networks—just don't leave them on a public-facing machine.