Skip to content
Erfi's Lexicanum

Keeping Windows SMB credentials in sync with a sops-managed NixOS Samba server

A Samba share that worked yesterday and today loops on “The user name or password is incorrect” - with the username field helpfully pre-filled - is almost never a server problem. It is Windows Credential Manager holding a stale password and offering no way to see that. This guide covers the full interaction with a declaratively-managed Samba server (NixOS + sops-nix re-seeding smbpasswd on every switch): how to prove which side is wrong, the client fix sequence, and the rotation runbook that stops the desync from recurring. It is the credential-side companion to Removing a stuck WinFsp or rclone drive letter (the drive-letter side) and sits downstream of the NAS migration that introduced the Samba setup. If you have not yet worked out which failure you have - credential or mount-ownership - start at the routing reference: Windows drive-letter failures.

Prerequisites: administrator or root SSH access to the Samba host, and a normal (non-elevated) prompt on the Windows client. Everything below was executed on 2026-08-28 against a NixOS 26.05 NAS (Samba 4.23.10, password from sops-nix; versions read off the box with nixos-version / smbd --version) and a Windows 10 Pro 22H2 client; no step is asserted from documentation alone.

Constants (read this first)

Section titled “Constants (read this first)”
FactConsequence
The Windows credential vault keys entries by the exact server string (10.0.71.2 and servarr.manticore-diatonic.ts.net are two different entries)A credential stored under one name does nothing for a mapping to the other; connecting by IP and by hostname needs two entries
Windows allows one credential context per server string per logon session; the restriction is by design, not a bug1Error 1219 fires on any second connection that carries explicit credentials - even the same username (proven below)
“Remember my credentials” only writes to the vault after a successful authenticationA failed attempt with the box ticked saves nothing; the dialog will be back next time
cmdkey /list shows that an entry exists, never what it contains”The credential is saved” and “the credential is correct” are independent facts
smbpasswd state lives in passdb.tdb under /var/lib/samba/private/ - outside the NixOS closureWithout a re-seed mechanism, any rebuild or rollback silently wipes Samba auth
On this NAS a oneshot unit re-runs smbpasswd -a -s erfi from the sops secret on every boot and every switch (idempotent)The server-side password is always exactly the sops secret; if auth fails, the drift is client-side by construction

Error translation table

Section titled “Error translation table”
SymptomWhat it actually means
Dialog pre-filled with servarr\erfi, “user name or password is incorrect”A vault entry exists for this server string and the server rejected it - the stored password is stale
System error 1219 on net useA connection to that server string already exists in this logon session; the new attempt supplied credentials explicitly1
net use /delete -> 2250, remap works anywayThe stale record was a half-dead session, not a held letter (the held-letter variant is the WinFsp guide)
NAS missing from Explorer’s Network view but reachable by \\10.0.71.2Discovery (WS-Discovery) is down; file sharing over 445 is unaffected

Step 1 - Prove the server is healthy before touching the client

Section titled “Step 1 - Prove the server is healthy before touching the client”

The single highest-value check: authenticate against the server with the password the server thinks it has. On the NAS (as root, so the sops secret is readable):

Terminal window
smbclient -L 10.0.71.2 -U "servarr\erfi%$(cat /run/secrets/samba-erfi-password)"
        Sharename       Type      Comment
        ---------       ----      -------
        anugrah         Disk
        host            Disk
        servarr         Disk
        tank            Disk
        IPC$            IPC       IPC Service (servarr)

A share listing proves three things at once: smbd is up, the account exists, and the password in the sops secret is the password Samba accepts - including the servarr\erfi username form Windows sends. Also confirm the account record itself:

Terminal window
pdbedit -L
# erfi:1000:

If step 1 fails, the problem is server-side and no amount of cmdkey will help. On this setup that means the re-seed unit; check it with systemctl status samba-set-password (it must run after the sops secret lands - on this system sops-install-secrets is an activation script, so the unit orders against run-secrets.d.mount, not against a secrets service - and before samba-smbd.service). The unit is restartable and idempotent:

Terminal window
systemctl restart samba-set-password
# ExecMainStatus=0, and the smbclient auth above still succeeds - rerun measured harmless

Step 2 - Inspect the vault, knowing its limits

Section titled “Step 2 - Inspect the vault, knowing its limits”
Terminal window
cmdkey /list
    Target: Domain:target=10.0.71.2
    Type: Domain Password
    User: servarr\erfi

An entry under the server string you connect to explains the pre-filled dialog: Windows is replaying this stored credential and the server is rejecting it. The vault cannot show you the stored password, so a wrong entry is indistinguishable from a right one until the server answers. That is why step 1 comes first - once the server is proven healthy, an existing entry plus a rejection means the stored password is wrong, full stop.

The working fix is to replace the entry. The password belongs to the user, so the /add line is typed by a person, not scripted:

Terminal window
cmdkey /delete:10.0.71.2
cmdkey /add:10.0.71.2 /user:servarr\erfi /pass:<the samba password>

If you would rather not have the password in shell history, skip cmdkey entirely and use Explorer: delete any existing entry, open \\10.0.71.2\servarr, enter servarr\erfi and the password, tick “Remember my credentials”. A successful auth writes the vault entry itself (this is the only path where ticking the box does anything).

Step 3 - Clear stale connections, then map

Section titled “Step 3 - Clear stale connections, then map”

A second failure mode layers on top: Windows keeps one credential context per server string per session, so a remap attempt while any connection to \\10.0.71.2 exists - mapped or not, healthy or half-dead - fails with system error 12191:

System error 1219 has occurred.


Multiple connections to a server or shared resource by the same user, using
more than one user name, are not allowed. Disconnect all previous connections
to the server or shared resource and try again.

“More than one user name” is misleading. Run live on the client box: with Z: already mapped to \\10.0.71.2\servarr, adding a second share without credentials succeeds (it reuses the session), while net use \\10.0.71.2\anugrah /user:servarr\erfi - the same username, no password argument - returns 1219. Supplying explicit credentials on a second connection is itself the trigger.

The fix sequence, run in order:

Terminal window
net use \\10.0.71.2\servarr /delete /y
net use Z: /delete /y
net use Z: \\10.0.71.2\servarr /persistent:yes

A /delete that answers “The network connection could not be found” (2250) is fine - it means that particular record was already gone. After cleanup, net use should list nothing for that server. The remap then completes silently using the vault credential, and /persistent:yes reattaches at every logon without prompting.

Step 4 - Rotate without desyncing the clients

Section titled “Step 4 - Rotate without desyncing the clients”

The server-side half is one edit. The sops file holds the plaintext password:

Terminal window
sops secrets/samba-password.sops.yaml   # erfi-password: <new password>
make deploy                             # switch: secret lands, unit re-seeds smbpasswd

Re-run step 1’s smbclient line to prove the new password is live. Then every Windows client must replace its vault entry (step 2) and remap (step 3) - the vault has no invalidation channel, so a server-side rotation presents on every client as the step-2 symptom: pre-filled dialog, “incorrect” password, no visible cause. Doing the client half immediately after the deploy is what keeps rotation boring.

Verification

Section titled “Verification”
Terminal window
net use
::   Z:        \\10.0.71.2\servarr     Microsoft Windows Network
dir Z:\
::   lists the share hub (media, anugrah, data, backups, appdata, scratch)
cmdkey /list | findstr 10.0.71.2
::   Target: Domain:target=10.0.71.2

Then sign out and back in (or reboot): Z: must reattach without any credential prompt. A prompt after a clean remap means the vault entry was never written - go through the Explorer path in step 2 and confirm the box was ticked on a successful auth.

Gotchas and lessons learned

Section titled “Gotchas and lessons learned”
  • Two connections, one net use line each, both to the same share. The observed state before cleanup was Z: -> \\10.0.71.2\servarr (Unavailable) plus a second letterless connection to the same UNC - the second one is what 1219 was actually complaining about. Delete by UNC, not just by letter.
  • The server string is the vault key. Mapping via the tailnet name (\\servarr.manticore-diatonic.ts.net\servarr) needs its own cmdkey entry; the IP entry is not consulted. Same server, two credential contexts - which is also the supported workaround when you genuinely need two usernames on one server: connect by IP as one and by hostname as the other1.
  • smbpasswd -a -s on every switch is load-bearing, not hygiene. passdb.tdb is not in the NixOS store; the first rebuild after a manual smbpasswd reverts auth to whatever the last declarative run set. The unit also runs at boot, so a rollback of the whole system still re-seeds the password from the sops secret that generation carries.
  • Explorer’s Network view is WS-Discovery now, not NetBIOS. The Computer Browser service depended on SMBv1 and was removed with it; Microsoft replaced workgroup browsing with WS-Discovery (Function Discovery Provider Host / Resource Publication services client-side)2. The NAS side of that is samba-wsdd - confirmed live on this box listening on UDP 3702 (multicast 239.255.255.250) across every interface. If the NAS vanishes from Network view but \\10.0.71.2 still works, the discovery path is down, not file sharing.
  • The pre-filled dialog is the tell. Windows only pre-fills the username when it has a stored credential for that server string. “Pre-filled plus rejected” is a one-line diagnosis: the vault copy is stale; arguing with the server config first is backwards.
  • The ordering against sops is the part that bites. An activation script runs before secrets land, so setting the password there read an empty file; the working unit is a systemd oneshot ordered after = [ "run-secrets.d.mount" ], before = [ "samba-smbd.service" ] (module: modules/smb.nix in the servarr-nixos repo).
Section titled “Related docs”

References

Section titled “References”

  1. Microsoft, “Cannot use different credentials for a network share” (KB 938120) - the multiple-connections restriction is by design; IP/DNS-alias workarounds. https://learn.microsoft.com/en-us/troubleshoot/windows-server/networking/cannot-connect-to-network-share ↩ ↩2 ↩3 ↩4

  2. Microsoft, “SMBv1 not installed by default in Windows” - the Computer Browser service is removed with SMBv1; Explorer Network browsing moves to WS-Discovery via the Function Discovery services. https://learn.microsoft.com/en-us/windows-server/storage/file-server/troubleshoot/smbv1-not-installed-by-default-in-windows ↩