Ich startete also. Nach der eigentlichen Installation begann ich mit der Einrichtung des PCs. Software und eigenes Desktop Theme installieren, Drucker einbinden Enpass einrichten; was man halt alles so braucht. Da unsere Firma, wie viele Andere auch, auf ein Windows System setzen, dürfen natürlich auch die obligatorischen Windows Shares nicht fehlen. Da ich dies unter Debian bereits mit Erfolg nutzte, waren für mich die notwendigen Schritte klar.

Also schnell die notwendigen Packages installiert…

sudo apt install cifs-utils smbclient

… und die notwendigen Konfigurationen in der Datei /etc/fstab vornehmen (kopiert aus dem Debian Image).

//srvIP/Shares/Share1 /media/Share1 cifs defaults,credentials=/home/mein-benutzer/.smb-credentials,uid=1000,gid=100,file_mode=0770,dir_mode=0770
[...]

Zuletzt noch ein kurzer Test, ob auch wirklich alles funktioniert…

sudo mount -a

… und zufrieden nach Hause gehen. Da es gerade Freitag war und ich mir sagte, dass ich es verdient habe, ging ich etwas früher aus dem Büro.

Nach einem ruhigen Wochenende startete ich am darauffolgenden Montag wieder mit meiner Arbeit. Während ich mit einer Bearbeitung eines Dokuments beschäftigt war, verweigerte mir das verwendete Tool auf einmal das Speichern des Dokuments auf einem der Shares. Huh, was ist den jetzt los? Auf dem Weg der Fehlersuche merkte ich dann, dass alle Services den Dienst verweigerten, die Single-Sign-On (SSO) von der Windows Active Directory verwendeten.

Also kurz dem IT Verantworlichen eine E-Mail mit der Annahme eines Fehlers seinerseits geschrieben, dass alles nicht mehr funktioniere und ich so auch nicht arbeiten könne. Dieser meldete dann zurück, dass mein Benutzer gesperrt sei, da MEIN PC zu viele ungültige Anmeldeversuche getätigt hätte. Ungläubig über seine Aussage, prüfte ich nochmals, ob ich wirklich überall das korrekte Passwort hinterlegt habe, was der Fall war. Er entsperrte mich; ich konnte wieder arbeiten.

Doch ca. 20 Minuten später wiederholte sich der Vorfall. Wieder Telefon in die Hand nehmen und analysieren. So ging das ca. zwei Tage lang weiter. Am zweiten Tag hatte ich sogar mal Wireshark angeschmissen, da ich wissen wollte wer die fehlerhaften Anfragen tätigte, allerdings ohne Erfolg. nach ca. 20 E-Mails an den IT-Verantwortlichen gingen wir dazu über, dass er mich immer dann informiert, wenn mein Benutzer wieder gesperrt wurde. Dann habe ich einen Service, ein Tool oder einen Browser Tab mehr geschlossen, um dem Fehler auf die Spur zu kommen.

Denn weder im Netzwerkverkehr noch in den Logs (weder Client- noch Server-seitig) gab es nicht den kleinsten Hinweis für eine Fehlkonfiguration. Meine Mounts funktionierten, sein Server hat dies angenommen. Der Fehler trat ab dem Zeitpunkt nicht mehr auf, an dem ich alle Shares unmountete.

Also nochmals die /etc/fstab anschauen und kontrollieren. Scheint alles in Ordnung zu sein; die Zugangsdaten stimmen, IP und Pfad sind auch korrekt, die UID und GID des zu verwendenden Nutzers … MOMENT!

Kurz die UID und die GID überprüfen, evt. stimmt da ja was nicht…

$ id -a
uid=1000(mein-nutzer) gid=1000(meine-gruppe) groups=1000(meine-gruppe), 4(adm), 24(cdrom), 27(sudo), 30(dip), 46(plugdev), 121(lpadmin), 133(lxd), 134(sambashare), 998(docker)

UID (1000) stimmt; die GID allerdings nicht, da fehlt in der /etc/fstab eine 0. Aber kann das wirklich zu diesem Fehler führen?

Fazit

Ja, genau dies war der Fehler. Meiner Ansicht nach versuchte CIFS (Samba) die Shares mit einem Group-Owner einzubinden, den es nicht gibt. Da jeder Versuch eine Anmeldung bei Windows bedeutet, sperrt die AD nach einiger Zeit den Benutzer. Was ich nicht verstehen kann ist, dass dies in keinem Log aufgetaucht ist. Sogar das Syslog meinte, dass alle Mounts sauber funktionieren. Was lernt man daraus?

KOPIERE KEINE CONFIG FILES AUS EINEM ALTEN SYSTEM!!!

Update 24.08.2021

Ein Kollege von mir hatte heute das gleiche Problem mit anderen Symptomen. Den Windows Benutzer hat es nicht gesperrt, jedoch konnten die Shares beim Systemstart nicht mehr eingebunden werden. Im Kernel Log war dabei folgende Meldung enthalten:

CIFS: No dialect specified on mount. Default has changed to a more secure dialect, SMB2.1 or later (e.g. SMB3.1.1), from CIFS (SMB1). To use the less secure SMB1 dialect to access old servers which do not support SMB3.1.1 (or even SMB3 or SMB2.1) specify vers=1.0 on mount.

Meine Vermutung ist, dass der Windows Server hier noch eine alte Samba Version benutzt und darum bei einem Update auf SMB3.1.1 nicht mehr reagieren kann. Die kurzfristige Lösung für dieses Problem ist, dass in der /etc/fstab der Wert defaults in vers=1.0 umgeschrieben wird. Somit wird die alte SMB1 Version zur Kommunikation genutzt. Leider kann ich nicht sagen, welchen Windows Server wir einsetzen, da die Administration dafür nicht in meiner Macht liegt.

//srvIP/Shares/Share1 /media/Share1 cifs vers=1.0,credentials=/home/mein-benutzer/.smb-credentials,uid=1000,gid=100,file_mode=0770,dir_mode=0770
[...]