Fix ERROR_NOT_AUTHENTICATED (0X000004DC) on Windows SMB shares

Quick answer: Open Credential Manager, delete any stored credentials for that server name or IP, then remap the drive with full domain\username.

Why does this error hit?

I pulled up to a small law firm last Tuesday—Sharon in accounting couldn't access the file server. Windows spat back 0X000004DC. She swore she typed the right password. She had. But Windows was trying to auth with an old cached credential from a laptop rejoin to the domain.

This error means the server saw your request, checked your ticket, and said "nope, you're not who you say you are." It's not a network drop or a file permission issue—it's pure authentication rejection. Common triggers: changed domain password without rebooting, switching from workgroup to domain, or a stale Kerberos ticket.

Step-by-step fix — the way I do it

Kill the stale connection first
Open Command Prompt as admin. Run:
```
net use * /delete /y
```
This disconnects all mapped drives. Don't skip it—a hung session will keep feeding the bad credential.
Scrub Credential Manager
Press Win+R, type control keymgr.dll, hit Enter. Look under Windows Credentials for any entry matching your server name or IP address. Delete them all. I've seen entries named TERMSRV/192.168.1.50 or just fileserver01—nuke them.
Flush Kerberos tickets
In that same admin Command Prompt:
```
klist purge
```
This clears any cached Kerberos tickets that might be expired or wrong. If you're not on a domain, skip this step.
Remap the drive cleanly
Use the full UNC path with explicit domain:
```
net use Z: \\fileserver01\shared /user:DOMAIN\sharon * /persistent:yes
```
Windows will prompt for the password. Type it fresh. Don't check "Connect using different credentials" in the GUI—that bypass can sometimes cache wrong info.
Test immediately
Open File Explorer, navigate to the drive. Create a test file. If it works, reboot to lock in the change.

Alternative fixes when the main one fails

I've seen cases where Credential Manager is empty and the fix still fails. Here's what I do next:

Check the SMB session directly. On the server (if you have access), run net session in CMD. Look for stale sessions from the client IP. Delete them with net session \\ClientIP /delete. Had to do this for a dental office where the server held a dead session for 48 hours.
Reset the network adapter. Open Network and Sharing Center, click "Change adapter settings", right-click your Ethernet/WiFi, select Disable, wait 10 seconds, then Enable. This forces Windows to renegotiate the SMB signing and session.
Run SFC and DISM. Corrupted system files can mess with the Security Support Provider Interface. In admin CMD:
```
sfc /scannow
DISM /Online /Cleanup-Image /RestoreHealth
```
Then reboot. I've only needed this once, but it saved a client's whole print server setup.
As a last resort, delete the saved network credentials via registry. Navigate to HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\MountPoints2 and delete the subkeys corresponding to the mapped drive. Backup first—that key is sensitive.

Prevention tip—stop this from coming back

Most people never check Credential Manager until something breaks. Get in the habit of clearing old entries every time you change your domain password. If you use multiple domains (like a vendor network and internal), always specify the domain in the drive map—never let Windows guess. And if you're on a laptop that roams between networks, disable automatic credential caching for network shares in Group Policy: Computer Configuration\Administrative Templates\Network\Lanman Workstation\Enable insecure guest logons—set it to Disabled. That forces every connection to reauthenticate from scratch.

This error is annoying, but it's almost always a credential cache issue. Clean it, remap it, and you're back in business.