Windows drive-letter failures: credential or mount-ownership?
A network drive letter that refuses to open is one symptom produced by two unrelated subsystems. Windows stores who you authenticate as in Credential Manager, keyed by server string, and who owns a mapped letter in the redirector or a third-party network provider, scoped to a logon session. A failure in either one surfaces identically in Explorer. This reference separates them so the fix effort goes to the layer that is actually broken - the ladders themselves live in two task guides:
- Credential desync -> Keeping Windows SMB credentials in sync with a sops-managed NixOS Samba server
- Stuck mount ownership -> Removing a stuck WinFsp or rclone drive letter
Everything below was worked against the same rig: a NixOS 26.05 NAS (Samba 4.23.10, password from sops-nix) and a Windows 10 Pro 22H2 client, August 2026. Both failures were reproduced live, not inferred from documentation.
The one discriminator
Section titled “The one discriminator”Run net use and read the Provider column for the letter in question. That single value routes the whole diagnosis:
Status Local Remote Network-------------------------------------------------------------------------------OK Z: \\10.0.71.2\servarr Microsoft Windows Network Z: \\server\copyparty WinFsp.NpMicrosoft Windows Network-> the SMB redirector owns the mapping. Your problem is authentication - the vault. Go to the credential guide.WinFsp.Np(or any non-SMB provider) -> a third-party provider owns the letter. Your problem is mount ownership, almost always in another session. Go to the WinFsp/rclone guide.
Decision matrix
Section titled “Decision matrix”| Credential desync | Stuck mount ownership | |
|---|---|---|
| Broken layer | Credential Manager vault (who you auth as) | Mount provider / session (who owns the letter) |
| Typical trigger | Server-side password rotated, clients never told | Mount’s owning process or service died, or lives in session 0 |
net use provider | Microsoft Windows Network | WinFsp.Np or another non-SMB provider |
| Explorer behaviour | Credential prompt, pre-filled, “incorrect” loop | Letter refuses to open; no credential question asked |
| Signature error(s) | 1219 on remap (duplicate connection) | 2250 on delete + 85 on remap - the pair |
| Vault entry | Present but holds a stale password | Irrelevant - the letter is held regardless of credentials |
| Fix surface | cmdkey + net use, your own session, reversible | PsExec SYSTEM / fsptool / sc delete, the owning session |
The two error patterns are nearly disjoint. A pre-filled credential dialog that rejects the stored password is the vault replaying a stale entry; Windows only pre-fills when it has a stored credential for that exact server string. A letter that answers delete with 2250 (“could not be found”) while remap answers 85 (“already in use”) is held by a provider or session your net use cannot reach1.
What both failures share
Section titled “What both failures share”- Session scope is the hidden variable. Credentials are per-server-string per-logon; mounts are per-provider per-session. “It works in my admin window but not Explorer” is the same lesson in both layers - a mapping or credential made in an elevated or SYSTEM context is global and invisible to the session that needs it.
- Explorer misreports state. Ghost letters, pre-filled dialogs, a stale Network view - Explorer holds records the underlying layer already dropped. Verify with
net use, never the GUI. - Prove the server before touching the client. In both incidents the NAS authenticated cleanly with the sops-managed password while the client looped. One
smbclient -L <server> -U "user%<password>"on the server eliminates the whole server side before anycmdkeyorfsptoolwork.
Which guide do I pick
Section titled “Which guide do I pick”net use, read the Provider column.Microsoft Windows Networkand a pre-filled credential prompt -> credential guide - fix the vault entry, clear stale connections, remap/persistent:yes.WinFsp.Np, or delete returns 2250 while remap returns 85 -> WinFsp/rclone guide - find the owning session or driver, free the letter, then map from the session that will use it.
References
Section titled “References”References
Section titled “References”-
Microsoft, “Cannot use different credentials for a network share” (KB 938120) - the multiple-connections restriction (error 1219) is by design. https://learn.microsoft.com/en-us/troubleshoot/windows-server/networking/cannot-connect-to-network-share ↩