Ach ja… ich weiß nicht ob das etwas mit unserem Problem zu tun hat aber ich kann kein einziges Windows10 Image auf den Clients syncen.
Folgender Fehler:
Das Problem hatte ich von Anfang an.
Linux lässt sich problemlos syncen allerdings nicht mehr über Torrent. Das hat lange problemlos funktioniert und plötzlich nicht mehr. Aktuell geht nur noch rsync 
Hallo,
Ich glaube, das ist ein grundsätzlicheres Problem beim synchronisierten Start von Windows 10 (bei uns seit dem Anniversary Update).
Ich habe gestern dazu ein Ticket erstellt: https://github.com/linuxmuster/linuxmuster-linbo/issues/138
Bei uns ist der Sync-Knopf ausgeschaltet - es funktioniert nicht. Neu+Start geht allerdings.
Viele Grüße
Thomas
Ahhh, super. Danke für den Tipp!
Ich habe den Neu+Start Button wegen der klickwütigen SuS ausgeblendet und mache es dann über die Linbo-Console. Partition formatieren und dann syncen…
Das wird hier im Forum schon seit längerem kommuniziert dass sync mit NTFS nicht mehr funktioniert und stattdessen neu+start angewandt werden soll.
Gruß
Alois
Hat leider nicht viel gebracht. Wenn ich mal eine Vermutung aussprechen darf:
Eventuell arbeiten die Linux- und die Windows-Clients nicht in der gleichen Zeit (UTC oder UTC + 2). Nur Windows scheint dem AD oder Kerberos auf seine Zeit zu schalten. Das würde erklären, dass bei den Linux-Clients, sobald sich jemand an irgendeinem Windows-Client anmeldet, das Proxy-Anmeldefenster aufploppt.
Andererseits widerspricht das der Beobachtung, dass es bei mir eine Zeit lang funktioniert hat.
Ich habe bei den Windows-Clients RTC auf UTC gesetzt. Seitdem stimmt dann auch die Zeit auf den Windows-Clients. Das Problem mit den Linux-Clients hat es leider nicht gelöst?!?
Gruß,
Mathias
Hallo Alois,
bis gestern war ja auch mein Stand: das „geht einfach nicht“ (mehr).
Aber im im Ticket verlinkten Bugreport wird erklärt, was dort das Problem ist - und wenn eine neue Version von ntfs-3g das Sync-Problem in Win 10 beheben könnte - wer weiß, bei wie vielen das irgendein „Windows geht nicht mehr richtig“ auslöst, obwohl es normal zu starten scheint - wäre das doch gut. Wie ich es insgesamt nett fände, wenn die Zahl der Dinge, die mit linuxmuster.net „nun einfach nicht mehr gehen“ beschränkt bleibt…
Viele Grüße
Thomas
Hallo,
Bei uns ist der Sync-Knopf ausgeschaltet - es funktioniert nicht. Neu+Start geht allerdings.Das wird hier im Forum schon seit längerem kommuniziert dass sync mit
NTFS nicht mehr funktioniert und stattdessen neu+start angewandt werden
soll.
ja, das liegt wohl daran, dass der NTFS Treiber den linbo verwendet
nicht alle Spezialfähigkeiten von nts kann (woher auch: ist ja „geheim“).
Deswegen bei Windows immer „NEU+Start“.
Das mache ich seit Jahren so: dauert auch nicht länger als nur sync
LG
Holger
Hallo Thomas,
bis gestern war ja auch mein Stand: das „geht einfach nicht“ (mehr).
Aber im im Ticket verlinkten Bugreport wird erklärt, was dort das
Problem ist - und wenn eine neue Version von ntfs-3g das Sync-Problem in
Win 10 beheben könnte - wer weiß, bei wie vielen das irgendein „Windows
geht nicht mehr richtig“ auslöst, obwohl es normal zu starten scheint -
wäre das doch gut.
möglicherweise kann man das reparieren, indem man die Rechte im
Dateisystem von Windows ändert, wie es hier beschrieben ist:
https://wiki.linuxmuster.net/community/anwenderwiki:windowsclient:windows10:win10-dateirechte
(also der takedown Befehl).
Wie ich es insgesamt nett fände, wenn die Zahl der
Dinge, die mit linuxmuster.net http://linuxmuster.net „nun einfach
nicht mehr gehen“ beschränkt bleibt…
… nun ja: dass die neue Version nicht alle Funktionalitäten der alten
„aus dem Stand heraus“ haben würde, war mir schon klar.
Dass mit dem Sync ist ein Problem, das wir schlicht nicht im Griff
haben: da muss ein neuerer ntfs-3G Treiber her, der dass kann.
An den anderen „fehlenden“ Funktionalitäten wird gearbeitet 
Bei ntfs-3g wird gehofft …
LG
Holger
Sorry, das ich das mit dem Win-sync hier eingeworfen habe. Ich hatte das im Forum tatsächlich nicht gesucht, da es für mich kein dringendes Problem darstellt.
Da ich wegen des eigentlichen Problems nicht so recht weiter weiß, hatte ich es nur der Vollständigkeit halber erwähnt.
Das Dual-Boot-Domänenanmeldungsproblem ist hingegen bei mir und wohl auch bei Mathias dringend. Daher würde ich mich über weitere Tipps und Ideen sehr freuen 
Welche Loglevel muss ich wo hochsetzen um aussagekräftige Logs bei der Domänenanmeldung unter Linux zu bekommen? Das wäre schon gut…
Ja, das habe ich auch irgendwann gemacht. Die Uhrzeit stimmt jetzt unter Linux und unter Windows. DasLoginproblem ist leider ebenfalls unverändert 
Hallo zusammen,
ich habe heute wieder Zeit gehabt im System nach Fehlern zu suchen und mir ist etwas aufgefallen 
Ich habe auf zwei bionic-client-pcs, bei denen der Domänen-Login nicht mehr möglich ist, die Dateien verglichen, die im Thread bereits durchleuchtet wurden.
Bei der /etc/krb5.keytab habe ich einen Ungereimtheit, IMHO einen Fehler gefunden.
Mein Image-Master, auf dem ich meine Images erstelle und hochlade ist PC12. Die krb5.keytab auf PC 12 sieht wie folgt aus:
[linuxadmin@PC12 ~]$ sudo klist -k -K /etc/krb5.keytab
[sudo] Passwort für linuxadmin:
(pam_mount.c:365): pam_mount 2.16: entering auth stage
Keytab name: FILE:/etc/krb5.keytab
KVNO Principal
---- --------------------------------------------------------------------------
23 host/pc12.linuxmuster.lan@LINUXMUSTER.LAN (0xf12619a7d3027a64)
23 host/PC12@LINUXMUSTER.LAN (0xf12619a7d3027a64)
23 host/pc12.linuxmuster.lan@LINUXMUSTER.LAN (0xf12619a7d3027a64)
23 host/PC12@LINUXMUSTER.LAN (0xf12619a7d3027a64)
23 host/pc12.linuxmuster.lan@LINUXMUSTER.LAN (0x3df2148f8117e456bb38a3da16b5d6a5)
23 host/PC12@LINUXMUSTER.LAN (0x3df2148f8117e456bb38a3da16b5d6a5)
23 host/pc12.linuxmuster.lan@LINUXMUSTER.LAN (0xe35d15354ed186b445b36f6dabc7efc79f48d7b74afac017837b3017b922d759)
23 host/PC12@LINUXMUSTER.LAN (0xe35d15354ed186b445b36f6dabc7efc79f48d7b74afac017837b3017b922d759)
23 host/pc12.linuxmuster.lan@LINUXMUSTER.LAN (0x7fc2046adf276c5e41c2ea403ecf8f4a)
23 host/PC12@LINUXMUSTER.LAN (0x7fc2046adf276c5e41c2ea403ecf8f4a)
23 restrictedkrbhost/pc12.linuxmuster.lan@LINUXMUSTER.LAN (0xf12619a7d3027a64)
23 restrictedkrbhost/PC12@LINUXMUSTER.LAN (0xf12619a7d3027a64)
23 restrictedkrbhost/pc12.linuxmuster.lan@LINUXMUSTER.LAN (0xf12619a7d3027a64)
23 restrictedkrbhost/PC12@LINUXMUSTER.LAN (0xf12619a7d3027a64)
23 restrictedkrbhost/pc12.linuxmuster.lan@LINUXMUSTER.LAN (0x3df2148f8117e456bb38a3da16b5d6a5)
23 restrictedkrbhost/PC12@LINUXMUSTER.LAN (0x3df2148f8117e456bb38a3da16b5d6a5)
23 restrictedkrbhost/pc12.linuxmuster.lan@LINUXMUSTER.LAN (0xe35d15354ed186b445b36f6dabc7efc79f48d7b74afac017837b3017b922d759)
23 restrictedkrbhost/PC12@LINUXMUSTER.LAN (0xe35d15354ed186b445b36f6dabc7efc79f48d7b74afac017837b3017b922d759)
23 restrictedkrbhost/pc12.linuxmuster.lan@LINUXMUSTER.LAN (0x7fc2046adf276c5e41c2ea403ecf8f4a)
23 restrictedkrbhost/PC12@LINUXMUSTER.LAN (0x7fc2046adf276c5e41c2ea403ecf8f4a)
23 PC12$@LINUXMUSTER.LAN (0xf12619a7d3027a64)
23 PC12$@LINUXMUSTER.LAN (0xf12619a7d3027a64)
23 PC12$@LINUXMUSTER.LAN (0x3df2148f8117e456bb38a3da16b5d6a5)
23 PC12$@LINUXMUSTER.LAN (0xe35d15354ed186b445b36f6dabc7efc79f48d7b74afac017837b3017b922d759)
23 PC12$@LINUXMUSTER.LAN (0x7fc2046adf276c5e41c2ea403ecf8f4a)
(pam_mount.c:133): clean system authtok=0x5612e7814b00 (1073741824)Dann habe ich die Datei auf PC09, einem anderen Client, getestet:
[linuxadmin@PC09 ~]$ sudo klist -k -K /etc/krb5.keytab
[sudo] Passwort für linuxadmin:
(pam_mount.c:365): pam_mount 2.16: entering auth stage
Keytab name: FILE:/etc/krb5.keytab
KVNO Principal
---- --------------------------------------------------------------------------
23 host/pc12.linuxmuster.lan@LINUXMUSTER.LAN (0xf12619a7d3027a64)
23 host/PC12@LINUXMUSTER.LAN (0xf12619a7d3027a64)
23 host/pc12.linuxmuster.lan@LINUXMUSTER.LAN (0xf12619a7d3027a64)
23 host/PC12@LINUXMUSTER.LAN (0xf12619a7d3027a64)
23 host/pc12.linuxmuster.lan@LINUXMUSTER.LAN (0x3df2148f8117e456bb38a3da16b5d6a5)
23 host/PC12@LINUXMUSTER.LAN (0x3df2148f8117e456bb38a3da16b5d6a5)
23 host/pc12.linuxmuster.lan@LINUXMUSTER.LAN (0xe35d15354ed186b445b36f6dabc7efc79f48d7b74afac017837b3017b922d759)
23 host/PC12@LINUXMUSTER.LAN (0xe35d15354ed186b445b36f6dabc7efc79f48d7b74afac017837b3017b922d759)
23 host/pc12.linuxmuster.lan@LINUXMUSTER.LAN (0x7fc2046adf276c5e41c2ea403ecf8f4a)
23 host/PC12@LINUXMUSTER.LAN (0x7fc2046adf276c5e41c2ea403ecf8f4a)
23 restrictedkrbhost/pc12.linuxmuster.lan@LINUXMUSTER.LAN (0xf12619a7d3027a64)
23 restrictedkrbhost/PC12@LINUXMUSTER.LAN (0xf12619a7d3027a64)
23 restrictedkrbhost/pc12.linuxmuster.lan@LINUXMUSTER.LAN (0xf12619a7d3027a64)
23 restrictedkrbhost/PC12@LINUXMUSTER.LAN (0xf12619a7d3027a64)
23 restrictedkrbhost/pc12.linuxmuster.lan@LINUXMUSTER.LAN (0x3df2148f8117e456bb38a3da16b5d6a5)
23 restrictedkrbhost/PC12@LINUXMUSTER.LAN (0x3df2148f8117e456bb38a3da16b5d6a5)
23 restrictedkrbhost/pc12.linuxmuster.lan@LINUXMUSTER.LAN (0xe35d15354ed186b445b36f6dabc7efc79f48d7b74afac017837b3017b922d759)
23 restrictedkrbhost/PC12@LINUXMUSTER.LAN (0xe35d15354ed186b445b36f6dabc7efc79f48d7b74afac017837b3017b922d759)
23 restrictedkrbhost/pc12.linuxmuster.lan@LINUXMUSTER.LAN (0x7fc2046adf276c5e41c2ea403ecf8f4a)
23 restrictedkrbhost/PC12@LINUXMUSTER.LAN (0x7fc2046adf276c5e41c2ea403ecf8f4a)
23 PC12$@LINUXMUSTER.LAN (0xf12619a7d3027a64)
23 PC12$@LINUXMUSTER.LAN (0xf12619a7d3027a64)
23 PC12$@LINUXMUSTER.LAN (0x3df2148f8117e456bb38a3da16b5d6a5)
23 PC12$@LINUXMUSTER.LAN (0xe35d15354ed186b445b36f6dabc7efc79f48d7b74afac017837b3017b922d759)
23 PC12$@LINUXMUSTER.LAN (0x7fc2046adf276c5e41c2ea403ecf8f4a)
(pam_mount.c:133): clean system authtok=0x5612e7814b00 (1073741824)… und musste feststellen, dass die Dateien identisch sind. Das kann ja wohl nicht sein wegen der Hostnamen, die sich unterscheiden müssen.
Hostname auf PC12
[linuxadmin@PC12 ~]$ cat /etc/hosts
# Diese Datei wird per postsync gepatcht. Zu bearbeiten ist sie auf dem Server."
# Pfad: ${linbodir}/${universalpostsyncdir}/${patchclass}/${HOSTS}
# PC12 wird im Postsyncskript mit dem echten Namen gepatcht
127.0.0.1 localhost
127.0.0.1 PC12.linuxmuster.lan PC12
#Die nächste Zeile enthält die Hostnamen so, wie sie auf dem Server eingetragen sind...
172.16.1.1 server.linuxmuster.lan server
# damit CUPS zufrieden ist, muss noch diese Zeile hier dazu:
172.16.1.1 server.lokal server.local…und PC09:
[linuxadmin@PC09 ~]$ cat /etc/hosts
# Diese Datei wird per postsync gepatcht. Zu bearbeiten ist sie auf dem Server."
# Pfad: ${linbodir}/${universalpostsyncdir}/${patchclass}/${HOSTS}
# PC09 wird im Postsyncskript mit dem echten Namen gepatcht
127.0.0.1 localhost
127.0.0.1 PC09.linuxmuster.lan PC09
#Die nächste Zeile enthält die Hostnamen so, wie sie auf dem Server eingetragen sind...
172.16.1.1 server.linuxmuster.lan server
# damit CUPS zufrieden ist, muss noch diese Zeile hier dazu:
172.16.1.1 server.lokal server.localWas ist da beim Verteilen der Images schief gelaufen? Warum wurde der Hostname in der /etc/krb5.keytab nicht korrekt gesetzt? Durch welchen Mechanismus wird der überhaupt gesetzt? Postsync?
Ich denke, dass das in meinem Setup der Fehler ist 
Ich habe heute noch einmal systematische Tests gemacht.
Fazit:
Das Problem ist absolut reproduzierbar. Trotz frischem Image, das perfekt funktionierte, versagt die Domänenanmeldung sobald eine Windowsanmeldung auf PC12 erfolgte.
In /etc/krb5.keytab steht ja auf allen Linuxclients nur PC12 (also auch auf PC09 oder PC03).
Ein erneuter Domänenbeitritt von PC03 hat dann zwar die keytab verändert, dort steht nun logischerweise PC03 bei allen Keys, aber das Problem des nicht funktionierenden Domänenlogins bleibt unverändert.
Mittlerweile halte ich es für recht unwahrscheinlich, dass Mathias und ich den gleichen blöden Fehler immer und immer wieder machen.
Meiner Meinung nach habe wir es hier mit einem schwerwiegendem BUG zu tun, der in Dual-Boot-Konfigurationen reproduzierbar auftritt.
Ich bitte daher nochmals um Hilfe seitens der Entwickler. Ich weiß nicht mehr weiter, kann aber alles was ihr zur Fehleranalyse benötigt zur Verfügung stellen.
Viele Grüße
Ralf
Lieber Ralf,
Ich kann mich Eurem Wunsch nur anschließen und hoffe, dass diese Art von Kinderkrankheit bald beseitigt ist, denn ich warte mit meiner Installation der linuxmuster.net Version 7, bis solche Probleme beseitigt sind. Und es scheint mir, dass dieses Dualbootproblem sozusagen der letzte große Stolperstein sein könnte. Mit freundlichen Grüßen Christoph G.
Hallo Ralf,
da du nichts zu verlieren hast, probier mal Folgendes:
Füge am Linux-Client in der smb.conf im Abschnitt global diese Zeile ein.
machine password timeout = 0
Dann den Client neu aufnehmen und so weiter.
Viele Grüße,
Christian
Hi Christian,
danke für den Tipp. Das werde ich nächsten Montag versuchen.
LG
Ralf
Dem stimme ich zu. Die anderen kleinen Fehler sind relativ gut zu finden und leicht zu beseitigen.
Wenn das Dual-Boot-Domänenanmeldungsproblem nicht wäre, wäre die Welt in Ordnung 
Hallo Ralf,
Bei der /etc/krb5.keytab habe ich einen Ungereimtheit, IMHO einen Fehler
gefunden.
gute Analyse.
Kannst du mal an PC09 (an dem der falsche Rechnernamen in der keytab
steht) den richtigen eintragen (suchen&ersetzen), neu booten und schauen
ob dann das Anmelden wieder geht?
Wäre ja echt fein, wenn das das Problem behebn würde: dann müßten wir
nur den postsync erweitern.
… ich glaub es aber nicht
LG
Holger
Hallo Holger!
Das werde ich morgen versuchen.
Wäre ja zu schön wenn das klappen würde.
Das Postsync-Skript würde ich direkt selber anpassen und zur Verfügung stellen - spannend!
LG
Ralf
Kleiner Denkfehler. Die keytab ist ja keine Textdatei, sondern eine binäre bzw. verschlüsselte Datei. Suchen/Ersetzen/Austauschen geht da natürlich nicht.
Ich habe gerade den Master (PC12) neu gesynct und neu in die Domäne aufgenommen. Aktuell syncen PC09 und PC10. Auf einem von beiden werde ich per linuxmuster-cloop-turnkey eine passende keytab erzeugen und dann schauen, ob der Login noch möglich ist bzw. ob der Login dann „standhält“.
Auf dem anderen Rechner teste ich den Tipp von @Blair
Drückt mir die Daumen 
So, hier das Ergebnis der neuen Testrunde:
So weit so gut. Damit haben wir den eindeutigen Zusammenhang zwischen einer Windows-Domänenanmeldung auf PC12 und dem Ausfall der Domänenanmeldung auf allen Rechneren, die PC12 in der /etc/krb5.keytab stehen haben!!!
Nun der kritische Test: Kann ich mich auf PC10, wo die Domänenanmeldung noch immer funktioniert (und wo nun korrekterweise auch PC10 in der keytab steht), auch dann noch unter Linux anmelden wenn ich DORT einen Domänenlogin unter Windows mache?
Die Antwort lautet JA. 
Ich will es vorsichtig so ausdrücken: Eine Problemlösung (besser ein Workaround) scheint zu sein auf allen Linux-Clients direkt nach dem Sync einen neuen Domänenbeitritt mittels linuxmuster-cloop-turnkey durchzuführen.
Dieser neue Beitritt sorgt dafür, dass die keytab mit dem korrekten Rechnernamen neu erzeugt wird. In dieser Konfiguration scheint es dann resilient gegenüber Windows-Domänenanmeldungen zu sein.
Ich formuliere das mit Vorsicht, da es erst an einem Rechner getestet ist. Ich muss das am Mittwoch noch mit allen Rechnern im Computerraum testen, bin aber guter Hoffnung.
@rettich
Es bleibt allerdings noch die Frage warum bei dir Mathias auf LMN6.2 die keytabs alle identisch sind und es dennoch funktioniert! Ist der Fehler vielleicht schon alt, wirkt sich aber erst in der neuen LMN7 oder auf aktuellen Win10-Clients negativ aus?