Der Nextcloud-CIFS-Mount antwortet mit ACCESS_DENIED. Das Passwort stimmt. smbclient funktioniert nicht. wbinfo -i wirft WBC_ERR_DOMAIN_NOT_FOUND. Und dann wird es seltsam.
Das Symptom
$ wbinfo -i 'DARKSIDE+cifs_mount'
failed to call wbcGetpwnam: WBC_ERR_DOMAIN_NOT_FOUND
$ wbinfo --sid-to-uid S-1-5-21-XXXXXXXXXX-...-1124
failed to call wbcSidToUid: WBC_ERR_DOMAIN_NOT_FOUND
Gleichzeitig funktioniert die Domain-Verbindung einwandfrei:
$ wbinfo -P
checking the NETLOGON for domain[DARKSIDE] ... succeeded
$ wbinfo -u | grep cifs
DARKSIDE+cifs_mount
Die Domain existiert. Der User existiert. Aber Winbind findet die Domain nicht, wenn es um UID-Mapping geht.
TL;DR
net idmap set secret '*' "$(cat /etc/machine.secret)" — fertig. Winbind hat ein separates LDAP-Bind-Passwort für das idmap-Backend, das bei Machine-Account-Rotation nicht mitrotiert wird.
Die Jagd auf die falsche Fährte
Erster Verdacht: Das idmap-Backend stimmt nicht. Auf dem UCS-Memberserver war nss konfiguriert (UCR-Default), plus ein Override in local.conf mit ad Backend.
Also systematisch getestet:
| Backend | Ergebnis |
|---|---|
nss | WBC_ERR_DOMAIN_NOT_FOUND |
ad | WBC_ERR_DOMAIN_NOT_FOUND |
rid | WBC_ERR_DOMAIN_NOT_FOUND |
Drei verschiedene Backends. Exakt der gleiche Fehler. Das ist der Moment, wo du aufhörst, am Backend rumzuschrauben — denn wenn drei komplett verschiedene Implementierungen identisch scheitern, liegt das Problem nicht dort.
Die richtige Log-Datei
Und hier ist der erste Lerneffekt. Wenn du bei Winbind-Problemen in /var/log/samba/log.winbindd schaust, siehst du: nichts Hilfreiches. Start, Stop, Cache-Rebuild. Keine Fehler.
Die eigentliche Goldgrube ist eine andere Datei:
$ cat /var/log/samba/log.winbindd-idmap
failed to bind to server ldap://dc-yoda.<DEINE-DOMAIN>:7389
with dn="cn=srv-r2d2,cn=memberserver,cn=computers,dc=<DOMAIN>,dc=lan"
Error: Invalid credentials
log.winbindd-idmap. Nicht log.winbindd. Das idmap-Backend hat einen eigenen Child-Prozess mit eigenem Log.
Und der sagt: LDAP-Bind schlägt fehl. Falsches Passwort.
Zwei Passwörter, ein Problem
Auf UCS-Memberservern liegt das Machine-Account-Passwort in /etc/machine.secret. Wenn du das manuell testest:
PW=$(cat /etc/machine.secret)
ldapsearch -x -H ldap://<DEIN-DC>:7389 \
-D "cn=<DEIN-MEMBERSERVER>,cn=memberserver,cn=computers,dc=<DOMAIN>,dc=lan" \
-w "$PW" -b "dc=<DOMAIN>,dc=lan" "(uid=testuser)" cn
Funktioniert einwandfrei. Aber Samba nutzt nicht /etc/machine.secret direkt. Es nutzt ein Passwort aus secrets.tdb. Und dort gibt es zwei separate Einträge:
| Key in secrets.tdb | Gesetzt durch | Zweck |
|---|---|---|
SECRETS/LDAP_BIND_PW/... | smbpasswd -w | Allgemeiner LDAP-Bind (smbd) |
SECRETS/GENERIC/IDMAP_LDAP_*/... | net idmap set secret '*' | idmap-Backend LDAP-Bind (winbindd) |
Bei einer Machine-Account-Rotation — sei es durch univention-join, automatische Rotation, oder manuelle Passwortänderung — wird nur /etc/machine.secret aktualisiert. Die secrets.tdb-Einträge bleiben auf dem alten Passwort stehen.
Der Fix
PW=$(cat /etc/machine.secret)
# Das idmap-Secret synchronisieren
net idmap set secret '*' "$PW"
# Das allgemeine LDAP-Bind-Secret synchronisieren
smbpasswd -w "$PW"
# Winbind neu starten
service winbind restart
sleep 3
net cache flush
Danach:
$ wbinfo -i 'DARKSIDE+cifs_mount'
DARKSIDE+cifs_mount:*:2021:5001:cifs_mount:/home/DARKSIDE-cifs_mount:/bin/bash
Warum das Backend egal war
Die Erklärung ist simpel: Auf einem UCS-Memberserver nutzt das * (Default) idmap-Backend ldap mit einer Verbindung zum UCS-LDAP auf Port 7389. Wenn dieses Backend beim Start scheitert (wegen falschem Passwort), bricht die gesamte idmap-Initialisierung ab — inklusive aller domainspezifischen Backends.
Es ist egal ob du nss, ad oder rid für deine Domain konfigurierst. Wenn das *-Backend nicht starten kann, gibt es keinen idmap-Context, und alle Lookups scheitern mit DOMAIN_NOT_FOUND.
Diagnose-Cheat-Sheet
Falls du in die gleiche Situation gerätst:
# 1. Domain-Trust OK?
wbinfo -P
# 2. User bekannt?
wbinfo -u | grep username
# 3. UID-Mapping kaputt?
wbinfo -i 'DOMAIN+user'
# 4. WENN 1+2 OK aber 3 scheitert:
cat /var/log/samba/log.winbindd-idmap
# → "Invalid credentials" = secrets.tdb desynchronisiert
# 5. Fix:
net idmap set secret '*' "$(cat /etc/machine.secret)"
smbpasswd -w "$(cat /etc/machine.secret)"
service winbind restart
Fazit
Samba hat für das idmap-Backend ein separates LDAP-Bind-Passwort in secrets.tdb, das weder durch smbpasswd -w noch durch Machine-Account-Rotation aktualisiert wird. Du musst net idmap set secret explizit aufrufen.
Die Fehlermeldung WBC_ERR_DOMAIN_NOT_FOUND ist dabei maximal irreführend — es ist kein Domain-Problem, sondern ein Authentication-Problem. Und die Antwort steht nicht in log.winbindd, sondern in log.winbindd-idmap.
Wer UCS-Memberserver betreibt und sich wundert, warum CIFS-Shares nach einer Weile plötzlich ACCESS_DENIED zurückgeben: Prüft eure secrets.tdb. Die Uhr tickt bei jeder Machine-Account-Rotation.