0XC0000195: Network credential conflict fix for Windows 10/11

Quick answer

Open Credential Manager → Windows Credentials → find and remove any entry with the server name or IP that's giving you the error. Reboot. Then try connecting again.

Why this happens

You're getting 0XC0000195 because Windows has saved two different sets of credentials for the same network resource. This usually happens when you connect to a file server using both its hostname and its IP address at different times, or when you change your domain password but Windows still holds onto the old one in the vault. The SMB client can't decide which set to use, so it throws this STATUS_NETWORK_CREDENTIAL_CONFLICT error instead of trying either.

I've seen this most often on Windows 10 22H2 and Windows 11 23H2 after someone maps a drive to \\server\share and then later tries \\192.168.1.100\share with different login details. The system caches both, and they don't match.

Fix steps: Clear the bad credentials

1. Press Win + R, type control keymgr.dll, hit Enter. That opens Credential Manager directly — faster than going through Control Panel.
2. Click Windows Credentials (not Web or Certificate-based).
3. Look for any entry that matches the server name, IP, or FQDN you're trying to reach. They'll be under “Generic Credentials” or “Windows Credentials” with names like TERMSRV/192.168.1.100 or MicrosoftAccount:user@domain for SMB shares.
4. Click the arrow to expand each suspicious entry, then Remove it. Confirm the delete.
5. Close Credential Manager and restart your computer. Don't skip the reboot — Windows caches these at kernel level, and a restart flushes them entirely.
6. After reboot, try connecting to the network share again. Map the drive using only the hostname (e.g., \\server\share) or only the IP — don't switch between them.

The reason step 3 works is that Credential Manager stores multiple entries per target. When you remove the conflicting ones, Windows has only one credential set to present during the NTLM or Kerberos handshake. No more guessing, no more 0xC0000195.

Alternative fixes if the main one doesn't help

Use net use to clear the mapping from command line

If Credential Manager shows nothing obvious, run this in an admin Command Prompt:

net use \\server\share /delete
net use * /delete

The first line removes the specific mapping. The second wipes all mapped drives — be careful, it removes everything.

Check for saved passwords in older Windows versions

On Windows 10 build 1809 and earlier, there's a quirk where credentials for SMB shares get stored under HKEY_CURRENT_USER\Network in the registry. Open regedit, go to that path, and delete the key named after your server share. Don't touch anything else in there unless you know what you're doing.

Reset the credential cache via command

If you're still stuck, flush the entire Windows credential cache:

cmdkey /list | ForEach-Object{if($_ -match "Target: (?.*)"){cmdkey /delete:$matches['target']}}

Paste that into PowerShell as admin. It deletes every stored credential — web, Windows, everything. You'll need to re-enter passwords for mapped drives, RDP connections, and apps like Outlook later.

Prevention tip

Don't mix hostnames and IPs when connecting to the same server. Pick one method — either always use the FQDN (\\fileserver.company.local\share) or always use the IP. And if you change your domain password, run klist purge in an admin command prompt right after to clear the Kerberos ticket cache. That stops Windows from trying your old password against the server and creating a conflicting entry.

Also, if you map drives through Group Policy, check that the policy sets the “Connect with different credentials” option consistently. I've seen admins enable that checkbox for one drive and disable it for another on the same server — that's a fast track to this error.

When to escalate

If you've removed all credentials, rebooted, and still get 0xC0000195, the conflict might be on the server side. Check the file server's Event Viewer under Applications and Services Logs → Microsoft → Windows → SMBClient. Look for event ID 30804 or 30805 — those log credential negotiation failures. If you see them, the server is rejecting valid credentials because of mismatched SMB protocol versions or signing requirements. That's a different beast — post a new question with those event IDs.