ERROR_CONNECTED_OTHER_PASSWORD 0X0000083C Fix

You mapped a network drive and Windows keeps saying the password is wrong even though it isn't. The fix is usually clearing stale credentials, not resetting your password.

You mapped a drive to \\fileserver\shared last week and it worked fine. This morning Windows pops up a login box. You type the same password you always use. Windows comes back with ERROR_CONNECTED_OTHER_PASSWORD (0X0000083C). You type it again. Same thing. You try your email password. Nope. Meanwhile a coworker sitting three desks away opens the same share with zero problems.

That's the classic trigger. The credentials already sitting in Windows don't match what the server wants right now — usually because you changed your domain password, the server was rebuilt, or you previously connected to that same host with a different username. Windows is handing over an old username/password combo, the server rejects it, and Windows reports it as a password problem even though the password you're typing is fine.

What the error actually means

ERROR_CONNECTED_OTHER_PASSWORD translates to: "You're already connected to this resource with a different set of credentials, and I can't swap them." It's a state error, not an authentication failure. The SMB client on your machine already has an authenticated session to that server or share, tied to some cached identity. When you try to authenticate as somebody else, Windows refuses to reuse the connection and hands you this code.

Three things almost always cause it:

You have a persistent mapped drive or a saved credential in Credential Manager pointing at the server with the old login.
Your domain password changed but Windows still has the old hash cached against the share.
Somebody remapped the drive under a service account or a different user profile on the same machine.

Notice what isn't on that list: a wrong password. Stop retyping it. It won't help.

The fix, step by step

Do these in order. Don't skip steps even if you think they're obvious — the stale credential is usually hiding in a place you didn't look.

Close everything that has a handle on the share. That means File Explorer windows showing the mapped drive, open Word docs saved there, and any app with a file open from that path. If a process holds the SMB session, the next steps won't fully clear it.
Open a Command Prompt as your normal user. Not admin — you want the same context that owns the drive mapping. In Windows 11 you can right-click Start and pick Terminal, then type cmd.
List the current connections. Type this and hit Enter:
```
net use
```
You'll see every mapped drive and any IPC$ or UNC session. Look for the server name in the "Remote" column. Note the drive letter if there is one.
Delete the connection to that server. If your share is on \\fileserver mapped to Z:, run:
```
net use Z: /delete /y
```
If it was a UNC-only session with no drive letter, use:
```
net use \\fileserver\shared /delete /y
```
Expected result: The network connection could not be found. That's fine — it just means it was already gone. If it says the connection was deleted successfully, even better.
Clear the saved credential in Credential Manager. Press Win + R, type control /name Microsoft.CredentialManager, hit Enter. Click Windows Credentials. Look for entries with the server's hostname or IP in them. Click each one and choose Remove. Don't just edit it — remove it. Editing leaves a stale hash behind more often than people admit.
Kill any lingering SMB sessions at the OS level. This is the step people skip and then wonder why nothing changed. In an admin Command Prompt or PowerShell:
```
net use * /delete /y
```
Or in PowerShell:
```
Get-SmbMapping | Remove-SmbMapping -Force
```
Expected outcome: no output, or a list of mappings being removed. If you get access denied, you skipped the "admin" part.
Reboot. Yes, really. The SMB client caches session state in kernel memory and a few registry keys under HKCU\Network. A clean restart is faster than trying to prod every cache.
Remap the drive and enter credentials fresh. When the credential prompt appears, check "Remember my credentials" only if this is your own machine. Type the username as DOMAIN\yourname — not just yourname — if the server is on a domain. For a NAS box, it's often NASNAME\username or just the local user on the NAS. The prefix matters.

If it still fails after that

Then the problem isn't on your side. Walk through this checklist:

Check	What to look for
Server time skew	If the file server's clock is more than 5 minutes off from your PC, Kerberos rejects everything. Run `w32tm /stripchart /computer:fileserver`.
Account lockout	Your AD account may have locked from the failed attempts. Ask IT to check Active Directory Users and Computers.
SMB version mismatch	If the server dropped SMB1 and your NAS is ancient, connections silently fail. Confirm the share is SMB2/3.
Antivirus interference	Some endpoint tools intercept SMB traffic. Temporarily disable the network shield on the target machine, not the server.
DNS	Ping the server by hostname. If it resolves to the wrong IP, you're authenticating against a machine that doesn't know you.

One more thing. If this error shows up right after you joined a VPN, the tunnel's DNS is probably overriding your local one, and you're hitting an old file server that still has your pre-VPN credentials cached. Disconnect the VPN, clear the mappings, then reconnect. That scenario bites people constantly and almost never gets diagnosed because the timing feels unrelated.

The real fix here is almost never the password. It's the ghost of an old login still attached to a share. Clear the ghost and the share opens.