11
Profile Roaming - Fehlermeldung nur beim ersten Login
Hallo zusammen,
ich habe zu Testzwecken einen Samba4 AD DC (192.168.3.16) eingerichtet mit einem Samba4 Fileserver (192.168.5.1) als Domainmember.
Soweit so gut und es funktioniert soweit auch alles, inklusive GPOs, Basis Ordner, der per GPO gemountet wird etc.
Jetzt habe ich mit Hilfe des AD Benutzer und Computer Tools in den User Einstellungen den Profilpfad zu "\\192.168.5.1\profiles\username" geändert, sodass ich Profile Roaming über mehrere Computer nutzen kann.
Jetzt gibt es aber das Problem, dass beim ersten Login, wenn noch kein Profile Ordner existiert, die im Anhang gezeigte Fehlermeldung aufpopt. Windows nutzt dann ein "TEMP" Profile und erstellt lediglich den
leeren username.v6 Ordner in dem Profile Share. Aufgrund des TEMP Profiles Wird folglich beim Logout auch nichts in den entsprechenden Ordner zurückkopiert.
Sobald ich mich im Anschluss, wie in der Fehlermeldung aufgefordert, neu anmelde, gibt es diesen Fehler nicht erneut und das Profile Roaming funktioniert wie gedacht.
Wenn ich mich nun auf einem neuen Domänen Computer anmelde, so wird der User auch ohne Probleme eingeloggt, und diese Fehlermeldung popt nicht erneut auf, da der Profilordner auf dem Server ja bereits existiert. So soll es ja auch eigentlich sein.
Im Eventviewer tritt die Fehlermeldung "1521" mit einem "Zugriff verweigert" auf. Da die Windows Fehlermeldungen ja immer so super spezifisch sind, ist jetzt die Frage, auf was denn genau der Zugriff verweigert würde? Die Daten sollten ja eigentlich erst beim Logout geschrieben werden, weshalb mir ein "Zugriff verweigert" aufgrund des Samba4 Shares eher unwahrscheinlich vorkommt.
Zu Testzwecken, habe ich dem share 777 permissions gegeben, aber auch hier keine Änderung.
Zum erstellen des Shares have ich diese Anleitung genutzt https://wiki.samba.org/index.php/Roaming_Windows_User_Profiles ("Using POSIX ACLs").
Jetzt ist die Frage wie man das ganze weiter debuggen könnte? Hättet ihr weitere Ideen, oder ggf. sogar eine Lösung, sofern ihr dieses Problem auch schon hattet?
System:
Client: Windows 10 HyperVM Build 1709
Server: Samba4 4.7.3
Disclaimer:
Ich habe den Thread unter
"Windows Server" erstellt, da ich davon ausgehe, dass es sich nicht um einen Samba4 Fehler handelt, da das Profile Roaming ja außer beim ersten Login einwandfrei funktioniert. Außerdem denke ich, dass Leute die von Profile Roaming Ahnung haben, eher diese Threads lesen als unter der Kategorie "Linux"
ich habe zu Testzwecken einen Samba4 AD DC (192.168.3.16) eingerichtet mit einem Samba4 Fileserver (192.168.5.1) als Domainmember.
Soweit so gut und es funktioniert soweit auch alles, inklusive GPOs, Basis Ordner, der per GPO gemountet wird etc.
Jetzt habe ich mit Hilfe des AD Benutzer und Computer Tools in den User Einstellungen den Profilpfad zu "\\192.168.5.1\profiles\username" geändert, sodass ich Profile Roaming über mehrere Computer nutzen kann.
Jetzt gibt es aber das Problem, dass beim ersten Login, wenn noch kein Profile Ordner existiert, die im Anhang gezeigte Fehlermeldung aufpopt. Windows nutzt dann ein "TEMP" Profile und erstellt lediglich den
leeren username.v6 Ordner in dem Profile Share. Aufgrund des TEMP Profiles Wird folglich beim Logout auch nichts in den entsprechenden Ordner zurückkopiert.
Sobald ich mich im Anschluss, wie in der Fehlermeldung aufgefordert, neu anmelde, gibt es diesen Fehler nicht erneut und das Profile Roaming funktioniert wie gedacht.
Wenn ich mich nun auf einem neuen Domänen Computer anmelde, so wird der User auch ohne Probleme eingeloggt, und diese Fehlermeldung popt nicht erneut auf, da der Profilordner auf dem Server ja bereits existiert. So soll es ja auch eigentlich sein.
Im Eventviewer tritt die Fehlermeldung "1521" mit einem "Zugriff verweigert" auf. Da die Windows Fehlermeldungen ja immer so super spezifisch sind, ist jetzt die Frage, auf was denn genau der Zugriff verweigert würde? Die Daten sollten ja eigentlich erst beim Logout geschrieben werden, weshalb mir ein "Zugriff verweigert" aufgrund des Samba4 Shares eher unwahrscheinlich vorkommt.
Zu Testzwecken, habe ich dem share 777 permissions gegeben, aber auch hier keine Änderung.
Zum erstellen des Shares have ich diese Anleitung genutzt https://wiki.samba.org/index.php/Roaming_Windows_User_Profiles ("Using POSIX ACLs").
Jetzt ist die Frage wie man das ganze weiter debuggen könnte? Hättet ihr weitere Ideen, oder ggf. sogar eine Lösung, sofern ihr dieses Problem auch schon hattet?
System:
Client: Windows 10 HyperVM Build 1709
Server: Samba4 4.7.3
Disclaimer:
Ich habe den Thread unter
"Windows Server" erstellt, da ich davon ausgehe, dass es sich nicht um einen Samba4 Fehler handelt, da das Profile Roaming ja außer beim ersten Login einwandfrei funktioniert. Außerdem denke ich, dass Leute die von Profile Roaming Ahnung haben, eher diese Threads lesen als unter der Kategorie "Linux"
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 359252
Url: https://administrator.de/contentid/359252
Printed on: April 24, 2024 at 15:04 o'clock
11 Comments
Latest comment
Hallo,
ohne das jetzt auseinander zu pflücken(01:15Uhr), warum denkst du das bei so einem komplex gestalteten Domain Controller der Fehler auf Windows Seite liegt? In der Regel sollte das nämlich wie in deinem Anhang gezeigt funktionieren. Greifen die GPO's diesbezüglich? Warum PosiX und nicht Windwos ACL? Wird der Temp Ordner vom nicht zugreifenden User geschrieben? Vielleicht dochmal im Linux-Bereich posten?
BG N8
ohne das jetzt auseinander zu pflücken(01:15Uhr), warum denkst du das bei so einem komplex gestalteten Domain Controller der Fehler auf Windows Seite liegt? In der Regel sollte das nämlich wie in deinem Anhang gezeigt funktionieren. Greifen die GPO's diesbezüglich? Warum PosiX und nicht Windwos ACL? Wird der Temp Ordner vom nicht zugreifenden User geschrieben? Vielleicht dochmal im Linux-Bereich posten?
BG N8
- Für das Profile Roaming habe ich gar keine GPOs angelegt. Das habe ich einfach händisch in das User-Objekt hinterlegt.
- POSIX ACLs, ganz einfach: Damit ich die Rechte von einer Linux Server Anwendung mit Hilfe der ACL Library verwalten kann. Ich werde aber einmal versuchen den Profile Share direkt auf dem DC zu machen mit Windows ACLs.
- Nein die Änderungen vom TEMP User werden am Ende nicht auf das Share geschrieben.
Das es an Samba4 liegt will ich nicht ausschließen. Soweit ich das beurteilen kann, hostet Samba4 in diesem Fall aber nur einen Share. Der Client schaut sich dann den Pfad in der AD des User Objektes an und sollte dann alles einfach auf das Share kopieren
. Da sollten eigentlich keine größeren DC Aktivitäten im Spiel sein (korrigiert mich, wenn das falsch ist :D)
Was mich stutzig macht, ist, dass es scheinbar nur beim ersten mal auftritt. Würde es Rechteprobleme geben, dann würde das ja nie funktionieren.
- POSIX ACLs, ganz einfach: Damit ich die Rechte von einer Linux Server Anwendung mit Hilfe der ACL Library verwalten kann. Ich werde aber einmal versuchen den Profile Share direkt auf dem DC zu machen mit Windows ACLs.
- Nein die Änderungen vom TEMP User werden am Ende nicht auf das Share geschrieben.
Das es an Samba4 liegt will ich nicht ausschließen. Soweit ich das beurteilen kann, hostet Samba4 in diesem Fall aber nur einen Share. Der Client schaut sich dann den Pfad in der AD des User Objektes an und sollte dann alles einfach auf das Share kopieren
. Da sollten eigentlich keine größeren DC Aktivitäten im Spiel sein (korrigiert mich, wenn das falsch ist :D)Was mich stutzig macht, ist, dass es scheinbar nur beim ersten mal auftritt. Würde es Rechteprobleme geben, dann würde das ja nie funktionieren.
Hallo,
Pruefe mal die Logfiles des Fileservers und natuerlich auch die des DC.
Deine verwendeten IP fuer DC und FS liegen in unterschiedlichen Subnetzen. Eventuelle Zeitverzoegerungen in dieser Richtung pruefen.
Meine Vermutung:
Wenn zum allerersten mal ein Benutzer aufschlaegt und der Fileserver soll gemaess Richtlinie den Profilpfad erstellen fragt der FS den DC ob der Benutzer existent ist. Das dauert u.U. etwas zu lange und/oder Windows wartet nicht lange genug.
Hast Du als Richtlinie festgelegt, dass immer auf das Netzwerk gewartet werden soll?
BFF
Pruefe mal die Logfiles des Fileservers und natuerlich auch die des DC.
Deine verwendeten IP fuer DC und FS liegen in unterschiedlichen Subnetzen. Eventuelle Zeitverzoegerungen in dieser Richtung pruefen.
Meine Vermutung:
Wenn zum allerersten mal ein Benutzer aufschlaegt und der Fileserver soll gemaess Richtlinie den Profilpfad erstellen fragt der FS den DC ob der Benutzer existent ist. Das dauert u.U. etwas zu lange und/oder Windows wartet nicht lange genug.
Hast Du als Richtlinie festgelegt, dass immer auf das Netzwerk gewartet werden soll?
BFF
Zitat von @BassFishFox:
Hallo,
Pruefe mal die Logfiles des Fileservers und natuerlich auch die des DC.
Ja die werde ich mir einmal genauer anschauen. Am besten mit einem tail -f, um das in Realtime zu sehen.Hallo,
Pruefe mal die Logfiles des Fileservers und natuerlich auch die des DC.
Evtl. wäre es auch einmal sinnvoll sich in Linux die Dateizugriffe anzeigen zu lassen, bzw ob die ggf. von den ACLs abgelehnt werden.
Deine verwendeten IP fuer DC und FS liegen in unterschiedlichen Subnetzen. Eventuelle Zeitverzoegerungen in dieser Richtung pruefen.
Ist ein 192.168.0.0/21 Subnetz, also eher nicht.Meine Vermutung:
Wenn zum allerersten mal ein Benutzer aufschlaegt und der Fileserver soll gemaess Richtlinie den Profilpfad erstellen fragt der FS den DC ob der Benutzer existent ist. Das dauert u.U. etwas zu lange und/oder Windows wartet nicht lange genug.
Das könnte tatsächlich sein, den Gedanken hatte ich auch schon. Das könnte ich prüfen.Wenn zum allerersten mal ein Benutzer aufschlaegt und der Fileserver soll gemaess Richtlinie den Profilpfad erstellen fragt der FS den DC ob der Benutzer existent ist. Das dauert u.U. etwas zu lange und/oder Windows wartet nicht lange genug.
Laut Microsoft Doc ist der Fehler 1521 wohl überwiegend ein Netzwerkproblem. Sobald ich in diesem "Fehlerzustand" des TEMP Benutzers nämlich den Share im Explorer öffne und Versuche Ordner zu erstellen, geht es nämlich.
Hast Du als Richtlinie festgelegt, dass immer auf das Netzwerk gewartet werden soll?
Die habe ich nicht drin. Ich kenne diese wohl, aber bis gerade war mir gar nicht bewusst, dass diese auch für den Login gilt. Dann ist das natürlich ein Versuch wert!Ich werde das morgen mal ausprobieren.
Hallo,
Ziemlich gross fuer Testzwecke.
Die IP der PC ist wo angesiedelt und haben den DC (192.168.3.16) alleinig als DNS?
BFF
Ist ein 192.168.0.0/21 Subnetz, also eher nicht.
Ziemlich gross fuer Testzwecke.
Die IP der PC ist wo angesiedelt und haben den DC (192.168.3.16) alleinig als DNS?BFF
Naja das ist halt auch mein Netzwerk für alle physikalischen PCs . Nicht virtuell.
Die VMs bekommen alle im Bereich 192.168.3.1-254 ihre IPs.
Glaube aber nicht, dass das da das Problem liegt. Aber ich kann das auch nochmal gerne debuggen.
Edit:// (Bin zu schnell im Antworten :P): Ja die Test VMs haben IPv6 deaktiviert und dann alleinig den DC als DNS. Komischerweise funktioniert es ja nur beim aller ersten Login nicht.
. Nicht virtuell.Die VMs bekommen alle im Bereich 192.168.3.1-254 ihre IPs.
Glaube aber nicht, dass das da das Problem liegt
. Aber ich kann das auch nochmal gerne debuggen.Edit:// (Bin zu schnell im Antworten :P): Ja die Test VMs haben IPv6 deaktiviert und dann alleinig den DC als DNS. Komischerweise funktioniert es ja nur beim aller ersten Login nicht.
Hallo,
Warum eigentlich?
Es ist nicht nur das Login, es ist auch das Anlegen des Ordners auf dem FS. Und u.U. halt eine Zeitueberschreitung bei Pruefen der Benutzercredentials. Das kannst Du sicherlich nachvollziehen, wenn Du auf einer W10 das Benutzerprofil sauber entfernst und auf den FS nach Neustart des entsprechenden W10 den Profilordner loeschst.
Genug zum Suchen gegeben.
BFF
Ja die Test VMs haben IPv6 deaktiviert
Warum eigentlich?
Komischerweise funktioniert es ja nur beim aller ersten Login nicht.
Es ist nicht nur das Login, es ist auch das Anlegen des Ordners auf dem FS. Und u.U. halt eine Zeitueberschreitung bei Pruefen der Benutzercredentials. Das kannst Du sicherlich nachvollziehen, wenn Du auf einer W10 das Benutzerprofil sauber entfernst und auf den FS nach Neustart des entsprechenden W10 den Profilordner loeschst.
Genug zum Suchen gegeben.
BFF
Ne, er legt ja einen leeren Benutzerordner an wie auch im Eingangsthread erwähnt:
Kann aber natürlich sein, dass das zu spät ist und Windows das nicht mehr mitbekommt, das lässt sich aber bestimmt morgen feststellen
erstellt lediglich den
leeren username.v6 Ordner in dem Profile Share.Kann aber natürlich sein, dass das zu spät ist und Windows das nicht mehr mitbekommt, das lässt sich aber bestimmt morgen feststellen
Hi,
wenn der Computer, an welchem sich der Benutzer anmeldet, beim Login den Benutzerordner im Profil-Stamm auf dem Server anlegt, dann ist das schon mal ein gutes Zeichen. Es zeigt, dass er kapiert hat, dass der Benutzer ein Roaming Profile haben soll, dieses aber noch nicht existiert. Es zeigt auch, dass der Computer das Recht hat, dort einen Ordner zu erstellen. Der Computer benötigt dort aber zusätzlich noch das Recht, die Berechtigungen des Ordners zu bearbeiten. Also würde ich mal überprüfen, ob in der ACL des Benutzerordners das Benutzerobjekt mit "Vollzugriff" enthalten ist. Wenn nicht und die Anmeldung beim 2. Mal dann trotzdem funktioniert, dann liegt das wohl daran, dass stattdessen "Jeder" oder eine andere Gruppe mit Änder- oder Vollzugriff-Recht enthalten ist.
Interessant wäre auch noch zu wissen, ob dieses Verhalten beim 1. Anmelden ohne vorhandenem Roaming Profile auch noch eintritt:
E.
wenn der Computer, an welchem sich der Benutzer anmeldet, beim Login den Benutzerordner im Profil-Stamm auf dem Server anlegt, dann ist das schon mal ein gutes Zeichen. Es zeigt, dass er kapiert hat, dass der Benutzer ein Roaming Profile haben soll, dieses aber noch nicht existiert. Es zeigt auch, dass der Computer das Recht hat, dort einen Ordner zu erstellen. Der Computer benötigt dort aber zusätzlich noch das Recht, die Berechtigungen des Ordners zu bearbeiten. Also würde ich mal überprüfen, ob in der ACL des Benutzerordners das Benutzerobjekt mit "Vollzugriff" enthalten ist. Wenn nicht und die Anmeldung beim 2. Mal dann trotzdem funktioniert, dann liegt das wohl daran, dass stattdessen "Jeder" oder eine andere Gruppe mit Änder- oder Vollzugriff-Recht enthalten ist.
Interessant wäre auch noch zu wissen, ob dieses Verhalten beim 1. Anmelden ohne vorhandenem Roaming Profile auch noch eintritt:
- an anderen Computern
- für andere Benutzer
- wenn der Benutzer bereits ein lokales Profil hat (welches dann zum Roaming Profile kopiert wird)
- wenn der Benutzer noch kein lokales Profil hat (er das Default Profile bekommt)
E.
Zitat von @BassFishFox:
Die IP der PC ist wo angesiedelt und haben den DC (192.168.3.16) alleinig als DNS?
Das Netzwerk ist hier doch für die konkrete Frage vollkommen irrelevant.Ist ein 192.168.0.0/21 Subnetz, also eher nicht.
Ziemlich gross fuer Testzwecke. Die IP der PC ist wo angesiedelt und haben den DC (192.168.3.16) alleinig als DNS?- Benutzer kann sich anmelden
- Client kann Benutzerordner auf Server erstellen
- 2. Anmeldung funktioniert ohne Probleme
So,
ich habe jetzt die smb.conf angepasst und dadurch verschwindet die Fehlermeldung beim ersten Login:
Quelle: https://keipke.de/wiki/display/HOWTO/Konfiguration+Samba+Roaming+Profile ...
ABER:
Das funktioniert soweit alles gut, bis man den Computer neustartet. Ich melde den Benutzer also das erste mal an, der Ordner wird auf dem Server erstellt. Beim Logout werden die Benutzerdaten auf den Server geschrieben. Melde ich dann erneut an auf dem gleichen oder auf einem anderen Computer (ohne neustart) an, so funktioniert immer noch alles super. Dieses Abmelden auf dem einen Computer und das Anmelden auf einem anderen kann ich auch beliebig oft wiederholen. So sollte Profile Roaming funktionien
Sobald ich nun aber, einen beliebigen Rechner herunterfahre, auf dem dieser Benutzer angemeldet war, (nichtmal neustarte), so kann ich mich auf keinen anderen Rechner wieder mit diesem Profil anmelden. Egal ob ich versuche dieses Profil wieder manuell von den Rechnern zu löschen etc.
Sobald ich dann auf dem Server das Profil wieder lösche und mich wieder anmelde, funktioniert wieder alles super.
Das kommt mir doch irgendwie sehr strange vor.
Scheinbar "zerstört" Windows das Profil beim Herunterfahren, was mir aber irgendwie sehr komisch vorkommt. Ich vermute mal, dass das nicht an Windows 1709 liegt, oder? Seit dem 1607 Build ist ja irgendwie sowieso der Wurm drin in Roaming Profiles.
Das spannende ist jetzt, was macht Windows beim Herunterfahren mit den Roaming Profiles? Fummelt der da noch irgendwie dran rum?
Schaue ich dann in den Ereignislog, auf den anderen Computer der noch läuft, bei dem Windows bei der Anmeldung meckert, dass er keine Verbindung zum Roaming Profile herstellen kann, so gibt es die Fehlermeldung, dass er auf die Datei nicht zugreifen kann, weil die angeblich verwendet wird. (Super Fehlermeldung Windows :P).
Jetzt ist die Frage, woran das liegen könnte, habt ihr eine Idee?
Edit:
TL:DR;
Windows scheint beim Herunterfahren das Handle auf die NTUSER.DAT nicht zu schließen, folglich meckert er beim Starten, dass diese noch in Verwendung ist.
Lange Version:
Ich habe noch etwas sehr interessantes herausgefunden:
Ich habe mich mit Hilfe des Linux Kernel Tools "inotify" an den Benutzerordner dran gehangen und alle Zugriffe aufgezeichnet.
Sobald man auf den "Herunterfahren" Button klickt, öffnet Windows die ntuser.ini und die NTUSER.DAT File:
Jetzt passiert es manchmal beim Herunterfahren, dass diese Datei auch wieder geschlossen wird:
So sollte es auch eigentlich aussehen. Im Anschluss funktionierte das Anmelden mit Hilfe des Roaming Profiles.
Jetzt kommt es aber des Öfteren vor, dass Windows dies aber eben nicht tut, dann ist die letzte File Operation, bevor der Computer aus ist:
Folglich ist noch ein Handle auf die NTUSER.DAT vorhanden, weshalb Windows beim erneuten einloggen meckert, dass die Datei angeblich von einem Prozess verwendet wird.
Beim Login, der fehlschlägt, weil Windows merkt, dass die Registry Datei ja noch geöffnet ist, endet mich folgenden Dateioperationen:
Windows gibt im Anschluss wohl auf.
Jetzt ist die Große Frage: Woran liegt das? Hier scheint Windows ja eindeutig das Handle nicht zu schließen beim Herunterfahren, jetzt ist die Frage ob Samba4 die Ursache ist, oder Windows einen Bug in der aktuellen Version hat?
Edit3:
Ich habe noch etwas tiefer gegraben. Das Handle auf die NTUser.DAT im Login Screen wird nach ca. 10 Sekunden geschlossen.
Fährt man den Computer erst dannach herunter, funktioniert das Roaming Profile auch wieder.
Interessanterweise wartet das "Herunterfahren", wenn ein Benutzer auf Herunterfahren klickt, nicht darauf, dass die NTUSER.DAT geschlossen wird. Folglich haben wir dort auch ein offenenes Handle und der Fehler bleibt vorhanden.
Wenn ich die NTUSER.DAT dann von Linux aus lösche (Windows lässt mich ja nicht, weil ist in Benutzung), geht das Profil wieder.
LÖSUNG:
Es ist wohl ein sehr bekannter Bug in Samba4. Das Problem ist, dass Windows zu schnell ist (habe das auf einer Samsung 850 EVO mit einem i7 3700 laufen) und somit nicht mehr den File Lock beendet bzw. die Server Verbindung nicht sauber trennt. Ein Windows Server kennt diese Problematik wohl und schließt das Handle, wenn sich ein User einloggt, sodass es dort funktioniert.
Es gibt aber Lösungen, die zwar eher Workarounds sind, aber bei mir funktionieren:
1. oplocks = no (Dies verhindert wohl das erstellen von File Locks, was das für andere Konsequenzen hat bzw. Nachteile werde ich noch ausprobieren und dann mitteilen.)
2. Ein Shutdown Skript mit einem Sleep 10 per GPO deployen (sehr ugly).
Credits: https://www.spinics.net/lists/samba/msg143168.html
Weitere Infos: https://social.technet.microsoft.com/Forums/de-DE/ba54df5f-4356-4cee-b72 ...
Dennoch bin ich auf eure Meinungen zu diesem Thema interessiert und vielleicht hat ja bereits jemand mit diesem Thema gekämpft und kennt eine schönere Lösung
ich habe jetzt die smb.conf angepasst und dadurch verschwindet die Fehlermeldung beim ersten Login:
[profiles]
comment = User profiles
path = /srv/profiles
read only = no
store dos attributes = Yes
guest ok = no
browseable = Yes
create mask = 0600
directory mask = 0700
profile acls = yes
csc policy = disable
valid users = @"DOMAIN\Domain Users" ABER:
Das funktioniert soweit alles gut, bis man den Computer neustartet. Ich melde den Benutzer also das erste mal an, der Ordner wird auf dem Server erstellt. Beim Logout werden die Benutzerdaten auf den Server geschrieben. Melde ich dann erneut an auf dem gleichen oder auf einem anderen Computer (ohne neustart) an, so funktioniert immer noch alles super. Dieses Abmelden auf dem einen Computer und das Anmelden auf einem anderen kann ich auch beliebig oft wiederholen. So sollte Profile Roaming funktionien
Sobald ich nun aber, einen beliebigen Rechner herunterfahre, auf dem dieser Benutzer angemeldet war, (nichtmal neustarte), so kann ich mich auf keinen anderen Rechner wieder mit diesem Profil anmelden. Egal ob ich versuche dieses Profil wieder manuell von den Rechnern zu löschen etc.
Sobald ich dann auf dem Server das Profil wieder lösche und mich wieder anmelde, funktioniert wieder alles super.
Das kommt mir doch irgendwie sehr strange vor.
Scheinbar "zerstört" Windows das Profil beim Herunterfahren, was mir aber irgendwie sehr komisch vorkommt. Ich vermute mal, dass das nicht an Windows 1709 liegt, oder? Seit dem 1607 Build ist ja irgendwie sowieso der Wurm drin in Roaming Profiles.
Das spannende ist jetzt, was macht Windows beim Herunterfahren mit den Roaming Profiles? Fummelt der da noch irgendwie dran rum?
Schaue ich dann in den Ereignislog, auf den anderen Computer der noch läuft, bei dem Windows bei der Anmeldung meckert, dass er keine Verbindung zum Roaming Profile herstellen kann, so gibt es die Fehlermeldung, dass er auf die Datei nicht zugreifen kann, weil die angeblich verwendet wird. (Super Fehlermeldung Windows :P).
Jetzt ist die Frage, woran das liegen könnte, habt ihr eine Idee?
Edit:
TL:DR;
Windows scheint beim Herunterfahren das Handle auf die NTUSER.DAT nicht zu schließen, folglich meckert er beim Starten, dass diese noch in Verwendung ist.
Lange Version:
Ich habe noch etwas sehr interessantes herausgefunden:
Ich habe mich mit Hilfe des Linux Kernel Tools "inotify" an den Benutzerordner dran gehangen und alle Zugriffe aufgezeichnet.
Sobald man auf den "Herunterfahren" Button klickt, öffnet Windows die ntuser.ini und die NTUSER.DAT File:
blabla.V6/ OPEN ntuser.ini
blabla.V6/ ATTRIB ntuser.ini
blabla.V6/ OPEN NTUSER.DATblabla.V6/ OPEN ntuser.ini
blabla.V6/ ATTRIB ntuser.ini
blabla.V6/ OPEN NTUSER.DATJetzt kommt es aber des Öfteren vor, dass Windows dies aber eben nicht tut, dann ist die letzte File Operation, bevor der Computer aus ist:
blabla.V6/ OPEN NTUSER.DATBeim Login, der fehlschlägt, weil Windows merkt, dass die Registry Datei ja noch geöffnet ist, endet mich folgenden Dateioperationen:
blabla.V6/ OPEN,ISDIR
blabla.V6/ ACCESS,ISDIR
blabla.V6/ CLOSE_NOWRITE,CLOSE,ISDIR
blabla.V6/ CREATE 6A6DCA49-668C-4DD1-8A7F-9D5B61E8EE92.tmp
blabla.V6/ OPEN 6A6DCA49-668C-4DD1-8A7F-9D5B61E8EE92.tmp
blabla.V6/ ATTRIB 6A6DCA49-668C-4DD1-8A7F-9D5B61E8EE92.tmp
blabla.V6/ MODIFY 6A6DCA49-668C-4DD1-8A7F-9D5B61E8EE92.tmp
blabla.V6/ MODIFY 6A6DCA49-668C-4DD1-8A7F-9D5B61E8EE92.tmp
blabla.V6/ OPEN,ISDIR
blabla.V6/ CLOSE_NOWRITE,CLOSE,ISDIR
blabla.V6/ DELETE 6A6DCA49-668C-4DD1-8A7F-9D5B61E8EE92.tmp
blabla.V6/ CLOSE_WRITE,CLOSE 6A6DCA49-668C-4DD1-8A7F-9D5B61E8EE92.tmp
blabla.V6/ OPEN,ISDIR
blabla.V6/ ACCESS,ISDIR
blabla.V6/ ACCESS,ISDIR
blabla.V6/ CLOSE_NOWRITE,CLOSE,ISDIR
blabla.V6/ OPEN,ISDIR
blabla.V6/ ACCESS,ISDIR
blabla.V6/ CLOSE_NOWRITE,CLOSE,ISDIR
blabla.V6/ OPEN NTUSER.DAT
blabla.V6/ CLOSE_NOWRITE,CLOSE NTUSER.DAT
blabla.V6/ OPEN NTUSER.DAT
blabla.V6/ CLOSE_NOWRITE,CLOSE NTUSER.DAT
blabla.V6/ OPEN NTUSER.DAT
blabla.V6/ CLOSE_NOWRITE,CLOSE NTUSER.DATWindows gibt im Anschluss wohl auf.
Jetzt ist die Große Frage: Woran liegt das? Hier scheint Windows ja eindeutig das Handle nicht zu schließen beim Herunterfahren, jetzt ist die Frage ob Samba4 die Ursache ist, oder Windows einen Bug in der aktuellen Version hat?
Edit3:
Ich habe noch etwas tiefer gegraben. Das Handle auf die NTUser.DAT im Login Screen wird nach ca. 10 Sekunden geschlossen.
Fährt man den Computer erst dannach herunter, funktioniert das Roaming Profile auch wieder.
Interessanterweise wartet das "Herunterfahren", wenn ein Benutzer auf Herunterfahren klickt, nicht darauf, dass die NTUSER.DAT geschlossen wird. Folglich haben wir dort auch ein offenenes Handle und der Fehler bleibt vorhanden.
Wenn ich die NTUSER.DAT dann von Linux aus lösche (Windows lässt mich ja nicht, weil ist in Benutzung), geht das Profil wieder.
LÖSUNG:
Es ist wohl ein sehr bekannter Bug in Samba4. Das Problem ist, dass Windows zu schnell ist (habe das auf einer Samsung 850 EVO mit einem i7 3700 laufen) und somit nicht mehr den File Lock beendet bzw. die Server Verbindung nicht sauber trennt. Ein Windows Server kennt diese Problematik wohl und schließt das Handle, wenn sich ein User einloggt, sodass es dort funktioniert.
Es gibt aber Lösungen, die zwar eher Workarounds sind, aber bei mir funktionieren:
1. oplocks = no (Dies verhindert wohl das erstellen von File Locks, was das für andere Konsequenzen hat bzw. Nachteile werde ich noch ausprobieren und dann mitteilen.)
2. Ein Shutdown Skript mit einem Sleep 10 per GPO deployen
(sehr ugly).Credits: https://www.spinics.net/lists/samba/msg143168.html
Weitere Infos: https://social.technet.microsoft.com/Forums/de-DE/ba54df5f-4356-4cee-b72 ...
Dennoch bin ich auf eure Meinungen zu diesem Thema interessiert und vielleicht hat ja bereits jemand mit diesem Thema gekämpft und kennt eine schönere Lösung
