Neues Image mit Xubuntu 26.04 linuxmuster-linuxclient7 setup schlägt fehl

tha · 18. Mai 2026 um 22:11

Hallo zusammen,

auch wenn dieses Thema schon sehr oft vorkommt, mache ich es trotzdem nochmal auf.

Folgendes, wir haben seit langem ein Mate 22.04 auf sämtlichen PCs und Laptops ohne Probleme laufen. Allerdings ist das mittlerweile etwas abgehangen und ich wollte ein neues Image machen.

Gesagt getan, Xubuntu26.04 gewählt (da kein Mate 26.04) , nach Doku erstellt an einem echten PC. Der PC existiert schon immer und ist jetzt nur in dem anderen Image.

Die Datei xubu26.qcow2.macct existiert auf dem Server, alles sieht normal aus wie im alten Image

Alles ok , die Nutzer können sich an diesem PC anmelden.

Jetzt - Image auf anderem PC - keine Anmeldung möglich linuxadmin mit Fehlermeldung:

Wenn ich linuxmuster-linuxclient7 setup aufrufe kommt folgendes

linuxmuster-linuxclient7 status

[INFO] (setup) #### linuxmuster-linuxclient7 status ####
[INFO] (setup) Linuxmuster-linuxclient7 is setup!
[INFO] (setup) Checking sssd krb5_child capabilities...
[ERROR] (setup) Missing capability: cap_dac_read_search

====================================================================
sssd krb5_child does not have the correct capabilities set. The login WILL NOT WORK!
Please reinstall sssd-krb5-common to fix this issue.
On Debian-based systems you can do this by running:
  sudo apt reinstall sssd-krb5-common
====================================================================

Wenn ich apt reinstall sssd-krb5-common mache und dann nochmal das Setup aufrufe, geht es.

Wenn ich dann ein Image schreibe geht es an diesem PC, aber nicht an weiteren anderen.

Wenn ich apt reinstall sssd-krb5-common an einem x-beliebigen anderen PC mache, dann kann ich mich immer wieder an diesem PC anmelden, ohne ein Image zu schreiben (PC mit altem Image drüber synchronisiert)

Offensichtlich muss ja etwas auf Serverseite verändert worden sein, so dass es funktioniert

Im Apache Studio Directory kann ich sehen, dass bei so einem PC dies steht:

pwdLastSet 18.05.2026, 23:10:37 MESZ (134236122378933320)

Bei fast allen PCs, die noch im alten Image hängen, steht dort eine 0.

Nun meine eigentliche Fragen:

Ich habe immer noch nicht den eigentlichen Ablauf der Anmeldung eines Computers an der AD verstanden. In der Macct steht ja wohl der Schlüssel des PCs, der beim Image-Erstellen dran war.

An welcher Stelle beim Synchronisationsprozess kommt der Schlüssel eines PCs dann rein?

Wo kommt diese Datei auf dem Server her?

Ist das eine Datei, wo ich nachschauen kann, ob die Rechte stimmen? (So was sagt ja die obige Fehlermeldung)

Wo kann ich auf dem Server sehen, ob der PC ordnungsgemäß angemeldet ist? Oder sehe ich das nur in Apache Directory Studio? Dort allerdings sind die PCs immer drin.

Ist es ein Problem, wenn PCs vorher in einem anderen Image waren?

Allerdings habe ich da mal getestet, wenn ich die PCs vollständig entferne und die Geräte importiere und sie dann neu reinmache, dann kommt der gleiche Fehler.

Viele Grüße
Johannes Thäter

tha · 1. Juni 2026 um 23:29

Einen kleinen Fortschritt habe ich (mit Hilfe der Google Suche KI)
Auf dem PC , wo das Image erstellt wurde, ist folgendes

-rw-r----- 1 root sssd 639 Jun 1 20:31 /etc/sssd/sssd.conf

Auf den anderen ist dies nicht so:

-rw------- 1 root root

Nachdem ich die Rechte auch so setze (Skript in onBOOT), kann man sich anmelden.

Das wirkt nur sehr unschön.

In unserem alten mate 22.04 Image ist alles mit

-rw------- 1 root root

gesetzt und geht.

Das paket linuxmuster ist ja wohl das selbe, aber irgendwelche Rechte werden anders verwendet.

Hat jemand eine Idee?

Viele Grüße

Johannes

andreas72 · 5. Juni 2026 um 16:38

Ich habe bei meiner Debian-Installation wertvolle Hinweise bekommen, als ich mich mal auf der Kommandozeile mit einem Domänennutzer versucht habe einzuloggen.

Ferner könntest du mal schauen, ob die Paketquelle für linuxmuster in deinem Client zur Version des Servers passt, die in der Anleitung genannte Quelle war (als ich das letzte mal einen Client neu aufgesetzt habe) veraltet.

tha · 12. Juni 2026 um 10:07

Also mittlerweile kann ich mich an jedem PC anmelden, in linbo-log ist auch zu sehen, dass etwas mit dem Maschinenpasswort passiert

[StdOut] Write reboot informations to /cache/boot/grub/grubenv.
[StdOut] receiving incremental file list
[StdOut] receiving incremental file list
[StdOut] Initiating machine password update on server 10.0.0.1 …
[StdOut] receiving incremental file list
[StdOut] Uploading linbo.log …

Bei neuen PCs, die ich in das Image nehme kommen dann folgende Fehlermeldungen (und die Netzlaufwerke sind dann nicht da)

INFO] (__main__) ====== onLogin started ======
[INFO] (user) Cleaning linuxadmin gtk bookmarks
[ERROR] (ldapHelper) Cloud not bind to ldap!
[ERROR] (ldapHelper) === An exception occurred ===
[ERROR] (ldapHelper) {'result': -2, 'desc': 'Local error', 'ctrls': [], 'info': 'SASL(-1): generic failure: GSSAPI Error: No credentials were supplied, or the credentials were unavailable or inaccessible (No Kerberos credentials available (default cache: FILE:/tmp/krb5cc_1631602829))'}
[ERROR] (ldapHelper) === end exception ===
[ERROR] (ldapHelper) Cannot talk to LDAP
[ERROR] (ldapHelper) Cloud not bind to ldap!
[ERROR] (ldapHelper) === An exception occurred ===
[ERROR] (ldapHelper) {'result': -2, 'desc': 'Local error', 'ctrls': [], 'info': 'SASL(-1): generic failure: GSSAPI Error: No credentials were supplied, or the credentials were unavailable or inaccessible (No Kerberos credentials available (default cache: FILE:/tmp/krb5cc_1631602829))'}
[ERROR] (ldapHelper) === end exception ===
[ERROR] (ldapHelper) Cannot talk to LDAP
[DEBUG] (shares) Calculating mountpoint of //server.lmn.lender.schule/sysvol
[DEBUG] (shares) Calculating mountpoint of //server.lmn.lender.schule/sysvol
[DEBUG] (shares) Trying to mount '//server.lmn.lender.schule/sysvol' to '/srv/samba/tha/sysvol'
[DEBUG] (shares) * Creating directory...
[DEBUG] (shares) * Executing '/usr/sbin/mount.cifs -o file_mode=0700,dir_mode=0700,sec=krb5,nodev,nosuid,mfsymlinks,nobrl,vers=3.0,user=tha,domain=LMN.LENDER.SCHULE,gid=1631600513,uid=1631602829,cruid=1631602829 //server.lmn.lender.schule/sysvol /srv/samba/tha/sysvol' 
[DEBUG] (shares) * Trying to mount...
* Error mounting share //server.lmn.lender.schule/sysvol to /srv/samba/tha/sysvol!
[FATAL] (shares) * Error mounting share //server.lmn.lender.schule/sysvol to /srv/samba/tha/sysvol!

[DEBUG] (shares) Calculating mountpoint of //server.lmn.lender.schule/sysvol
[DEBUG] (environment) Saving export 'SYSVOL=/srv/samba/tha/sysvol' to tmp file
[ERROR] (ldapHelper) Cloud not bind to ldap!
[ERROR] (ldapHelper) === An exception occurred ===
[ERROR] (ldapHelper) {'result': -2, 'desc': 'Local error', 'ctrls': [], 'info': 'SASL(-1): generic failure: GSSAPI Error: No credentials were supplied, or the credentials were unavailable or inaccessible (No Kerberos credentials available (default cache: FILE:/tmp/krb5cc_1631602829))'}
[ERROR] (ldapHelper) === end exception ===
[ERROR] (ldapHelper) Cannot talk to LDAP
[FATAL] (gpo) * Error when loading applicable GPOs! Shares and printers will not work.
[INFO] (hooks) === Running local hook onLogin in /etc/linuxmuster-linuxclient7/onLogin.d ===
[ERROR] (ldapHelper) Cloud not bind to ldap!
[ERROR] (ldapHelper) === An exception occurred ===
[ERROR] (ldapHelper) {'result': -2, 'desc': 'Local error', 'ctrls': [], 'info': 'SASL(-1): generic failure: GSSAPI Error: No credentials were supplied, or the credentials were unavailable or inaccessible (No Kerberos credentials available (default cache: FILE:/tmp/krb5cc_1631602829))'}
[ERROR] (ldapHelper) === end exception ===
[ERROR] (ldapHelper) Cannot talk to LDAP
[ERROR] (ldapHelper) Cloud not bind to ldap!
[ERROR] (ldapHelper) === An exception occurred ===
[ERROR] (ldapHelper) {'result': -2, 'desc': 'Local error', 'ctrls': [], 'info': 'SASL(-1): generic failure: GSSAPI Error: No credentials were supplied, or the credentials were unavailable or inaccessible (No Kerberos credentials available (default cache: FILE:/tmp/krb5cc_1631602829))'}
[ERROR] (ldapHelper) === end exception ===
[ERROR] (ldapHelper) Cannot talk to LDAP
[INFO] (hooks) == Executing script /etc/linuxmuster-linuxclient7/onLogin.d/00_example.sh ==
onLogin.d Hook called with env:
Server home: 
Sysvol: /srv/samba/tha/sysvol
Domain: lmn.lender.schule
Server hostname: server.lmn.lender.schule
School: 
Username: 
Room: 
Hardware group: 
[INFO] (hooks) ==> Script /etc/linuxmuster-linuxclient7/onLogin.d/00_example.sh finished with exit code 0 ==
[INFO] (hooks) == Executing script /etc/linuxmuster-linuxclient7/onLogin.d/01_sodiesundas.sh ==
[INFO] (hooks) ==> Script /etc/linuxmuster-linuxclient7/onLogin.d/01_sodiesundas.sh finished with exit code 0 ==
[INFO] (hooks) ===> Finished running local hook onLogin ===
[INFO] (hooks) === Running remote hook onLogin ===
[ERROR] (ldapHelper) Cloud not bind to ldap!
[ERROR] (ldapHelper) === An exception occurred ===
[ERROR] (ldapHelper) {'result': -2, 'desc': 'Local error', 'ctrls': [], 'info': 'SASL(-1): generic failure: GSSAPI Error: No credentials were supplied, or the credentials were unavailable or inaccessible (No Kerberos credentials available (default cache: FILE:/tmp/krb5cc_1631602829))'}
[ERROR] (ldapHelper) === end exception ===
[ERROR] (ldapHelper) Cannot talk to LDAP
[ERROR] (hooks) Could not execute server hooks because the user config could not be read
[INFO] (hooks) ===> Finished running remote hook onLogin ===
[INFO] (__main__) ======> onLogin end ======
* Error when loading applicable GPOs! Shares and printers will not work.

Komisch ist, das
systemctl status linuxmuster-linuxclient7.service

zeigt, das sysvol des Rechners PHVB-06$ verbunden ist (da geht auch ein ls )

Jun 11 22:28:52 phvb-06 onBoot[1446]: [INFO] (hooks) == Executing script /srv/samba/PHVB-06$/sysvol/lmn.lender.schule/scripts/default-school/lmn/linux/sysstart.sh ==
Jun 11 22:28:52 phvb-06 onBoot[1446]: [INFO] (hooks) ==> Script /srv/samba/PHVB-06$/sysvol/lmn.lender.schule/scripts/default-school/lmn/linux/sysstart.sh finished with exit code 0 ==
Jun 11 22:28:52 phvb-06 onBoot[1446]: [INFO] (hooks) == Executing script /srv/samba/PHVB-06$/sysvol/lmn.lender.schule/scripts/default-school/custom/linux/sysstart.sh ==
Jun 11 22:28:52 phvb-06 onBoot[1446]: [INFO] (hooks) ==> Script /srv/samba/PHVB-06$/sysvol/lmn.lender.schule/scripts/default-school/custom/linux/sysstart.sh finished with exit code 0 ==
Jun 11 22:28:52 phvb-06 onBoot[1446]: [INFO] (hooks) ===> Finished running remote hook onBoot ===
Jun 11 22:28:52 phvb-06 onBoot[1446]: [INFO] (__main__) ======> onBoot end ======

Hat jemand eine Idee, das ist doch irgendwas mit dem KRB5 Cache, die Datei

tmp/krb5cc_1631602829

existiert gar nicht. Es gibt dort nur /tmp/krb5cc_0

Viele Grüße

Johannes

tha · 12. Juni 2026 um 12:05

Bei der Gelegenheit konnte ich auch die Drucker einbinden, in der Fehlermeldung sieht man ja, dass es schief geht. Ich habe die Datei :

/usr/lib/python3/dist-packages/linuxmusterLinuxclient7/printers.py

in der Funktion def _installPrinterf _installPrinter (Zeile 74) von everywhere auf raw umgestellt

installCommand = ["timeout", "10", "lpadmin", "-p", name, "-E", "-v", networkPath, "-m", "raw", "-u", f"allow:{username}"]

Und siehe da, alle Drucker werden wie im alten Image Mate 22.04 ordentlich nach GPO eingebunden.

Der händische Aufruf gibt dies:

lpadmin -p PR-BIB-BUERO -E -v ipp://SERVER/printers/PR-BIB-BUERO -m everywhere -u allow:tha

lpadmin: Printer returned invalid data: "media-type-supported": Falscher Schlüsselwortwert "thick-1(-2nd)" - ungültiges Zeichen (RFC 8011 Abschnitt 5.1.4).

Mit -m raw geht es. Das scheint aber auch am Drucker zu liegen, mit einem anderen Drucker geht es auch mit everywhere.

Das ist ja fest im Skript vom linuxmuster-Paket. Wie kann ich so was festhalten (bei Updates von linumuster-client)?

Viele Grüße

Johannes

tha · 19. Juni 2026 um 09:43

Hallo zusammen,

also die Datei
/tmp/krb5cc_0

ist auf allen PCs nach dem Start vorhanden, in der Datei ist der Name der PCs sichtbar:
SYSPHVB$@@@A@@@A@@@QLMN.LENDER.SCHULE

INF4-19$@@@A@@@A@@@QLMN.LENDER.SCHULE

Der Vorgang im Linbo scheint da ja zu funktionieren. Beim ersteren PC geht die Anmeldung, dann existiert eine Datei

/tmp/krb5cc_1631602829

die dem angemeldeten Nutzer gehört.

Beim zweiten PC wir diese Datei nicht erzeugt. Es kommt dann

[INFO] (user) Cleaning linuxadmin gtk bookmarks
[ERROR] (ldapHelper) Cloud not bind to ldap!
[ERROR] (ldapHelper) === An exception occurred ===
[ERROR] (ldapHelper) {‚result‘: -2, ‚desc‘: ‚Local error‘, ‚ctrls‘: , ‚info‘: ‚SASL(-1): generic failure: GSSAPI Error: No credentials were supplied, or the credentials were unavailable or inaccessible (No Kerberos credentials available (default cache: FILE:/tmp/krb5cc_1631602829))‘}
[ERROR] (ldapHelper) === end exception ===

Das ist wohl das eigentliche Problem. Welches Skript erzeugt denn diese Datei?

tha · 30. Juni 2026 um 16:48

Hallo zusammen,
ich antworte mir mal selber, vielleicht hilft das ja anderen, die ein Client mit Ubuntu 24 und aufwärts haben.
Die Problem ist folgendes oder zumindest erkläre ich mal meine Erkenntnisse:

Ab Ubuntu 26 (oder 24) bzw. sssd Version 2.9.5 ( das findet sich in Zeile 396 in der Datei:

/usr/lib/python3/dist-packages/linuxmusterLinuxclient7/setup.py

prüft er diese expectedCaps = [„cap_dac_read_search“, „cap_setgid“, „cap_setuid=p“

Bei einigen PCs sitzt das auch richtig. Das wird aber wohl nicht per linbo aufs neue Image übertragen, d.h. die Cap sitzen gar nicht.

Jetzt habe ich in

/srv/linbo/linuxmuster-client/xubu26/common/postsync.d

ein Skript 10-sssd-caps.sh mit folgendem Inhalt:

#!/bin/sh
# -------------------------------------------------------------------------
# LINBO-Postsync-Hook: SSSD Capability Fix für xubuntu 26.04 / lmn7.2
# -------------------------------------------------------------------------

echo " -> Starte SSSD Capability Fix im Postsync..."

# Da LINBO das Client-System unter /mnt einbindet, nutzen wir chroot.
# Wir prüfen beide möglichen Systempfade von SSSD ab.

if [ -f "/mnt/usr/libexec/sssd/krb5_child" ]; then
    echo "    Setze Rechte in /usr/libexec/sssd/..."
    chroot /mnt setcap 'cap_setuid,cap_setgid,cap_dac_read_search=ep' /usr/libexec/sssd/krb5_child
    chroot /mnt setcap 'cap_setuid,cap_setgid,cap_dac_read_search=ep' /usr/libexec/sssd/ldap_child
    echo "    Capabilities erfolgreich geschrieben."

elif [ -f "/mnt/usr/lib/x86_64-linux-gnu/sssd/krb5_child" ]; then
    echo "    Setze Rechte in /usr/lib/x86_64-linux-gnu/sssd/..."
    chroot /mnt setcap 'cap_setuid,cap_setgid,cap_dac_read_search=ep' /usr/lib/x86_64-linux-gnu/sssd/krb5_child
    chroot /mnt setcap 'cap_setuid,cap_setgid,cap_dac_read_search=ep' /usr/lib/x86_64-linux-gnu/sssd/ldap_child
    echo "    Capabilities erfolgreich geschrieben."

else
    echo "    FEHLER: krb5_child wurde im Client-Image nicht gefunden!"
fi

Das wird auch brav ausgeführt und mit

getcap /usr/libexec/sssd/krb5_child /usr/libexec/sssd/ldap_child
/usr/libexec/sssd/krb5_child cap_dac_read_search,cap_setgid,cap_setuid=ep
/usr/libexec/sssd/ldap_child cap_dac_read_search,cap_setgid,cap_setuid=ep
Kommt dieses Ergebnis. Mit nur =p hat es dann irgendwie nicht funktioniert.
Das passt jetzt nur nicht zum Test in

/usr/lib/python3/dist-packages/linuxmusterLinuxclient7/setup.py (Zeile 396)

Das habe ich dann kurzerhand geändert auf

expectedCaps = [„cap_dac_read_search“, „cap_setgid“, „cap_setuid“]

Jedenfalls kann man sich nun am neuen Xubuntu 26.04 anmelden.

Das scheint mir zwar eine etwas hemdsärmelige Lösung zu sein, aber vielleicht hat jemand eine Idee, es schöner zu machen.
Ich nehme mal an, in anderen neueren Ubuntus geht das auch so.

Wieso überträgt eigentlich linbo nicht diese Attribute?
Viele Grüße

Johannes