Ich habe mich mal drangemacht ein Linux Mint 21 (Vanessa) from Scratch zu erstellen. Nach Installation habe ich die linuxmuster-linuxclient7 apt-Quelle eingebunden und anschliessend linuxmuster-linuxclient7 setup (DomainJoin hat hier funktioniert) und linuxmuster-linuxclient7 prepare durchgeführt und sofort im Anschluss das Image gezogen. Dann das Image auf einem neuen Rechner ausgerollt und gebootet, hier funktioniert dann die Anmeldung als Domänenbenutzer nicht. Hierbei ist mir aufgefallen dass gar keine .macct-Datei erstellt wurde während des erstellen und hochladen des Images. Wo und wann wird denn die .macct-Datei überhaupt erstellt? Wird bei LMN 7.1 bei Linux-Images diese überhaupt benötigt? Mir ist nämich aufgefallen dass vom letzten Windows-Image (kein from-Scratch!) dass ich erstellt habe (nach Umstellung auf LMN 7.1, direkt im qcow2-Format) eine .macct erstellt und auch auf den Server hochgeladen wurde, bei meinem vorigen Linux-Image (Ubuntu 18.04, auch kein from-Scratch) jedoch nicht. Die Domain-Anmeldung am Ubuntu-Image funktioniert aber. Wo kann ich hier genau schauen bzw. mich im LINBO-Prozess einklinken?
So, irgendwie hat es jetzt geklappt. Was hab ich gemacht:
Ich hab das Mint-Image nochmal auf einem anderen Rechner ausgerollt, dann nochmal linuxmuster-linuxclient7 setup und prepare durchgeführt. Dann den Rechner neu ins LINBO gebootet, das Image erstellt und hochgeladen. Und hier war dann auf einmal die Datei mint21.qcow2.macct im /srv/linbo/images/mint21/-Verzeichnis.
Offenbar ist für das .macct-Dateien hochladen die /usr/share/linuxmuster/linbo/rsync-post-upload.sh verantwortlich, welches nach dem Image-Upload ausgeführt wird.
Jetzt funktioniert auch im Mint die Anmeldung an der Domain sowie auch im Windows am gleichen Rechner.
Ich glaub ich hab herausgefunden warum die .macct nicht angelegt wird.
Neues Image erstellt mit Namen:
ubuntu-1804-3.5-1.qcow (man beachte die Punkte im Namen)
Ausgabe der /srv/linbo/log/rsync-post-upload.log:
/usr/share/linuxmuster/linbo/rsync-post-upload.sh: Zeile 114: /srv/linbo/images/ubuntu-1804-3/ubuntu-1804-3.5-1.qcow2.macct: Datei oder Verzeichnis nicht gefunden
chmod: Zugriff auf '/srv/linbo/images/ubuntu-1804-3/ubuntu-1804-3.5-1.qcow2.macct' nicht möglich: Datei oder Verzeichnis nicht gefunden
Nochmal neues Image erstellt:
ubuntu-1804-3-5-1.qcow2 (keine Punkte im Namen, nur vor der Extension)
Keine Meldungen in rsync-post-download.log wegen nicht gefundenen Dateien.
Ich hatte diesbezüglich schonmal was geposted: LMN7.1: Punkte im Imagenamen - #5 von createc-solution aber da gings direkt um das .qcow2-File. Es scheint wohl dass die Anpassung die in linbo-4.0.33 (Fix download error with imagefilename containing dots. · linuxmuster/linuxmuster-linbo7@7f15ee4 · GitHub) gemacht wurde auch noch in der Datei /usr/share/linuxmuster/linbo/rsync-post-upload.sh vorgenommen werden muss.
Gruß
Chris
Hi Chris,
Wäre super, wenn du dafür ein Issue auf GithHub aufmachen würdest, damit es nicht in Vergessenheit gerät 
VG,
Dorian
Ok, Danke für die schnelle Bearbeitung, aber:
seit linbo-4.0.35 auf den Clientrechnern läuft ist plötzlich die Domänenanmeldung an Windowsrechnern nicht mehr möglich. Ich hatte zwischendurch einen Rechnernamen geändert (bin mir nicht mehr sicher ob vor oder nach Update auf Linbo 4.0.35), dann das Windowsimage neu ausgerollt (Neu+Start) damit Windows auch mitbekommt dass der Rechnername geändert wurde, und trotzdem bekam ich die Meldung „Die Vertrauensstellung zur Domäne konnte nicht hergestellt werden“. In den Logs hab ich dann gesehen dass die .macct-Datei nicht gefunden werden konnte:
Sep 08 23:05:02 server.bbs.lan rsyncd[9281]: rsync on linbo/win10base25-noscript.qcow2.macct from c110-r07.bbs.lan (10.3.110.7)
Sep 08 23:05:02 server.bbs.lan rsyncd[9281]: rsync: link_stat "win10base25-noscript.qcow2.macct" (in linbo) failed: No such file or directory (2)
Warum sucht er die eigentlich im linbo/ Verzeichnis? Die liegt doch unter dem linbo/images/win10base25-noscript/ Verzeichnis?
Ok, dachte ich. Als quick’n’dirty Workaround hab ich die Datei dann nach linbo/win10base25-noscript.qcow2.macct versymlinkt, musste allerdings auf die Datei noch chmod a+r machen weil er erst meinte ‚permission denied‘. Dann hab ich nochmal Windows neu gestartet und in den Logs stand dann dass er die .macct gefunden hat. Trotzdem kam immer noch die Meldung mit der Vertrauensstellung. Ich wusste dann nicht weiter und hab dann auf linbo-4.0.34 gedowngraded. Dann nochmal in Linbo rebootet und Windows gestartet (kein Sync, nur Start), dann ging die Domänenanmeldung wieder. Komischerweise hat er immer noch die .macct im linbo/ Verzeichnis gesucht. Hab dann den erstellten Link (s.o.) gelöscht, nochmal reboot und Windows Start durchgeführt. Die Datei konnte er dann wieder nicht finden (klar hab ja den Link gelöscht), aber die Domänenanmeldung funktionierte trotzdem! Den Grund kann ich nicht nachvollziehen.
Auf jeden Fall bleib ich erstmal bei LINBO-4.0.34 weil damit die Domänenanmeldung wieder funktioniert.
Ich habe das ganze auf 2 komplett unabhängigen Linuxmuster-7.1-Systemen durchgeführt und bei beiden brachte das Downgrade auf linbo-4.0.34 die Abhilfe.
danke für die Info. Nachgebessert: Neue Pakete für lmn 7.1 - #238 von thomas
Der Urspungscode stammte noch von Knopper aus einer Zeit, in der 8punkt3-Dateinamen üblich waren. 
VG, Thomas
Danke, funktioniert hiermit wieder.
Gerade noch die Frage, wegen der Meldung:
Sep 08 23:05:02 server.bbs.lan rsyncd[9281]: rsync on linbo/win10base25-noscript.qcow2.macct from c110-r07.bbs.lan (10.3.110.7)
Sep 08 23:05:02 server.bbs.lan rsyncd[9281]: rsync: link_stat "win10base25-noscript.qcow2.macct" (in linbo) failed: No such file or directory (2)
ich hab mir mal die /usr/share/linuxmuster/linbo/rsync-pre-download.sh angeschaut, und ich glaube die o.g. Meldung wird von der macct)-Funktion ausgelöst die nach dem .macct-File direkt unter /srv/linbo sucht falls es sich bei dem Image um ein altes .cloop-File handelt. Stimmt das so? Mir gehts nur um das verstehen.
Die .macct wird trotzdem auf den Server gepatcht, nur die Meldung ist verwirrend.
Die macct-Datei wird ja nicht wirklich heruntergeladen. Der Downloadrequest des Clients ist nur der Trigger, der den Server veranlasst den Computeraccountpassworthash in das AD zu pushen. Wo er die Datei findet, weiß der Server eh.
VG, Thomas