HILFE! Plötzlich keine Domänenanmeldung unter Win und Linux möglich

thoschi · 24. August 2020 um 12:38

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

baumhof · 24. August 2020 um 12:38

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

baumhof · 24. August 2020 um 12:59

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

Cosmicos · 24. August 2020 um 14:23

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…

Cosmicos · 24. August 2020 um 14:25

Ja, das habe ich auch irgendwann gemacht. Die Uhrzeit stimmt jetzt unter Linux und unter Windows. DasLoginproblem ist leider ebenfalls unverändert

Cosmicos · 26. August 2020 um 11:52

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.local

Was 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

Cosmicos · 28. August 2020 um 11:10

Ich habe heute noch einmal systematische Tests gemacht.

bionic-cloop mittels servertools heruntergeladen und auf dem Imagemaster (PC12 bei mir) konfiguriert (update, linuxmuster-cloop-turnkey, Fehler beseitigt)
Ein neues Image vom Master aus erstellt und hochgeladen.
Image auf einem anderen Client (PC09) gesynct.
Auf beiden Rechnern bionic gebootet und problemlos als Domänenuser angemeldet. Alle Funktionen getestet. Alles funktioniert bestens (Netzlaufwerke, Internet mit SSO, Drucken auf Netzwerkdrucker etc.)
Auf anderen Clients im selben Raum Windows gestartet und angemeldet.
bionic-clients (PC09 & PC12) heruntergefahren und neu gebootet - Domänenanmeldung funktioniert nach wie vor!
Windows Client wieder heruntergefahren.
bionic-clients neu gestartet und erneut Domänenanmeldung ausprobiert! Funktioniert noch IMMER!
Nun habe ich schließlich auf PC12 Windows gebootet, mich angemeldet und Windows wieder heruntergefahren.
Nun auf PC 12 wieder bionic gebootet - Anmeldeversuch - GESCHEITERT. Keine Domänenanmeldung mehr möglich
Auf PC09, dem anderen neuen bionic-client ist ebenfalls nun keine Domänenanmeldung mehr möglich.
Nun bin ich an PC03 gegangen und habe dort das neue bionic-image gesynct.
Anmeldeversuch auf PC03 - Domänenanmeldung ebenfalls nicht möglich
Anmeldung als linuxadmin auf PC03 und manueller Domänenbeitritt mittels linuxmuster-client-adsso
Neustart auf PC03 - Domänenanmeldung noch immer nicht möglich!

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

Cgsman · 28. August 2020 um 11:44

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.

Blair · 28. August 2020 um 18:13

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

Cosmicos · 28. August 2020 um 18:54

Hi Christian,
danke für den Tipp. Das werde ich nächsten Montag versuchen.
LG
Ralf

Cosmicos · 28. August 2020 um 20:03

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

baumhof · 30. August 2020 um 16:28

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

Cosmicos · 30. August 2020 um 19:10

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

Cosmicos · 31. August 2020 um 09:44

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

Cosmicos · 31. August 2020 um 10:38

So, hier das Ergebnis der neuen Testrunde:

PC12 (Master-Image) Linux gesynct und neu in die Domäne aufgenommen - Login funktioniert!
PC09 & PC10 gesynct und Linux-Domänenanmeldung überprüft - Login funktioniert!
PC09 - smb.conf gemäß Tipp von @Blair angepasst - reboot - Login funktioniert!
PC10 - mittels „linuxmuster-cloop-turnkey“ die /etc/krb5.keytab angepasst - Login funktioniert!
PC12 - Windwos10 gestartet und angemeldet
PC12 & PC09 Linux Login NICHT mehr möglich (@Blair - die neue Option in der smb.conf ändert nichts. Schade!)
PC10 (der mit der neuen keytab) - Login funktioniert!!! (mehrfach getestst mit Win10 Logins zwischendurch)

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?

rettich · 31. August 2020 um 10:50

Hallo Ralf,
das klingt ja schon mal super

Ich sitze hier in der Schule an der lmn7 früher in der lmn6.2 haben sich die Windows-Clients an der Domäne angemeldet und die Linux-Clients habe über LDAP die Anmeldung geprüft. Da ist keiner dem Anderen in die Quere gekommen.

Heute sind beide in der Domäne. Selbst wenn’s funktioniert hat das Nachteile.
Bei einem Laptop, der hauptsächlich im WLAN ist. Wird der Passwort-Hash beim Starten nicht aktualisiert. Die Folge wäre, dass die Anmeldung immer nur auf einem System klappt. Jedenfalls so lange, bis der Client beim Start mit einem Netzwerkkabel am Schulnetz hängt

Gruß,
Mathioas

baumhof · 31. August 2020 um 10:55

Hallo,

Ich will es vorsichtig so ausdrücken: Eine Problemlösung scheint zu sein
auf allen Linux-Clients direkt nach dem Sync einen neuen Domänenbeitritt
mittels linuxmuster-cloop-turnkey durchzuführen.

… ich habe noch eine andere Lösung: man führt den Domänenbeitritt mit
einem virtuellen Linuxclient durch, an dem sich nie jemand an Windows
anmeldet … könnte auch klappen, oder hab ich da was falsch verstanden.

LG

Holger

Cosmicos · 31. August 2020 um 11:00

Ach ja, eines ist mir gerade noch aufgefallen.
Beim Absetzen von „linuxmuster-cloop-turnkey“ auf PC10 (der noch immer brav unter Linux und unter Win10 funktioniert) ist es zu einer Fehlermeldung gekommen:

Joined 'PC10' to dns domain 'linuxmuster.lan'

Installing server certificate ... mount error(2): No such file or directory
Refer to the mount.cifs(8) manual page (e.g. man mount.cifs)
cp: Aufruf von stat für '/var/lib/samba/sysvol/linuxmuster.lan/tls/cacert.pem' nicht möglich: Datei oder Verzeichnis nicht gefunden
umount: /var/lib/samba/sysvol: nicht eingehängt.
Success!

Klappt aber dennoch

Cosmicos · 31. August 2020 um 11:04

Also ein Cloop auf einem Rechner erzeugen, wo kein Dual-Boot Win10 drauf ist und das dann im Netz verteilen??

Das werde ich am Mittwoch testen! Das hätte den Vorteil, dass man die Rechner dennoch automatisch syncen kann und nicht nach jedem Sync wieder Domänenbeitritte machen muss.

Cosmicos · 2. September 2020 um 14:41

So, heute habe ich auf einem Reserve-PC (PC22) Windows entfernt, unter Bionic auf dem selben PC ein neues Image erzeugt und dieses auf alle 16 Rechner im Computerraum hochgeladen.

Ich kann mich jetzt an allen Rechnern unter Linux anmelden.

Ich habe mich dann auf PC12 unter Windows angemeldet und abgemeldet. Bislang hat das die Linux-Anmeldung außer Kraft gesetzt!

Dann nochmal an den Linuxrechnern die Domänenanmeldung getestet und - siehe da - et funzt

@baumhof Dein Workaround scheint zu klappen - JUCHUUUU

So weit war ich noch nie!!!
Morgen werden ich es noch intensiver mit allen Rechnern testet und dann melde ich mich noch einmal.

Viele Grüße
Ralf