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, so the fix depends on telling them apart first. The fix ladders 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 on it.
The one discriminator
Section titled “The one discriminator”Run net use and read the Provider column for the letter in question; its value decides which guide you need.
Status Local Remote Network-------------------------------------------------------------------------------OK Z: \\192.168.22.2\servarr Microsoft Windows Network Z: \\server\copyparty WinFsp.NpMicrosoft Windows Network-> the SMB redirector owns the mapping, so the problem is authentication in the vault. Go to the credential guide.WinFsp.Np(or any non-SMB provider) -> a third-party provider owns the letter, so the 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, together |
| 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”- Both layers are scoped to a session. Credentials are per-server-string per-logon; mounts are per-provider per-session. “It works in my admin window but not Explorer” has the same cause 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”-
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 ↩