17
Immer wiederkeherende SMB Abbrüche
Hallo,
seit letzter Woche habe ich hier bei unserer Backup Maschine immer wieder SMB Client Abbrüche. Die Fehler sehen wie folgt aus:
Diese Meldungen treten zu allen möglichen Uhrzeiten auf. Leider findet nirgendswo anders ein disconnect statt. Weder auf der NAS/Windows File Server(beides), noch beim Switch. Auch in der Firewall ist alles freigegeben und zeigt nur "allow".
Das ist im normalen Leerlauf kein wirkliches Problem, da die Verbindung ja wiederhergestellt wird, jedoch führt genau dieser Fehler seit letzter Woche immer wieder zu fehlerhaften Backups, da die Verbindung plötzlich weg ist.
Jetzt bin ich mir nicht sicher, ob da das letzten Windows CU etwas damit zu tun haben könnte?
Komischerweise gibt es diese kurzen Abbrüche auch auf anderen Maschinen, aber da läuft natürlich keine Backup Software drauf und zeigt keinerlei negative Auswirkung.
Meine Recherche im Internet und Kontakt zum Backup Software Hersteller hat bisher nichts Zielführendes ergeben.
Jetzt wollte ich mich mal an euch wenden, ob ihr so ein Verhalten schon mal beobachtet habt.
Angaben zum Setup:
1. Es handelt sich um eine Server 2016 VM auf ESXi. Neustes Windows CU(August). VMware ESXi, 7.0.3, 21686933.
2. Dito beim File Server.
3. Die NAS ist eine Synology. Neustes Update.
4. Das Alles hängt an einem Cisco 250er Switch.
5. Firewall von Securepoint mit einer "Any"-Regel vom Server zur NAS.
6. Die Server sind im selben Subnet.
7. Windows Firewall Regeln für Dateifreigabe sind auf grün.
Gruß
seit letzter Woche habe ich hier bei unserer Backup Maschine immer wieder SMB Client Abbrüche. Die Fehler sehen wie folgt aus:
Eine Netzwerkverbindung wurde getrennt.
Servername: \***
Serveradresse: 192.168.***:445
Verbindungstyp: Wsk
Erläuterung:
Dies weist darauf hin, dass die Verbindung zwischen Client und Server getrennt wurde.
Wenn bei Verwendung eines RoCE (RDMA over Converged Ethernet)-Adapters häufig unerwartete Trennungen auftreten, kann eine falsche Netzwerkkonfiguration vorliegen. RoCE setzt voraus, dass PFC (Priority Flow Control) für jeden Host, Switch und Router im RoCE-Netzwerk konfiguriert wird. Eine nicht ordnungsgemäße PFC-Konfiguration kann zu Paketverlusten, häufig auftretenden Trennungen und schlechter Leistung führen.
Event Id 30805:
Die Sitzung mit dem Server wurde für den Client unterbrochen.
Fehler: Die Übertragungsverbindung ist nun getrennt.
Servername: \***
Sitzungs-ID: 0x1CC0040000049
Erläuterung:
Falls es sich bei dem Server um einen Windows-Failovercluster-Dateiserver handelt, wird diese Meldung ausgegeben, wenn die Dateifreigabe zwischen Clusterknoten verschoben wird. Es sollte auch das Anti-Ereignis 30806 vorhanden sein, das angibt, dass die Sitzung mit dem Server wiederhergestellt wurde. Falls es sich bei dem Server nicht um einen Failovercluster handelt, war der Server zuvor wahrscheinlich online, aber nun ist über das Netzwerk kein Zugriff mehr auf den Server möglich.
Event Id 30806:
Die Verbindung mit der Freigabe wurde unterbrochen.
Fehler: Die Übertragungsverbindung ist nun getrennt.
Freigabename: \***
Sitzungs-ID: 0x1CC0040000049
Struktur-ID: 0x5
Erläuterung:
Falls es sich bei dem Server um einen Windows-Failovercluster-Dateiserver handelt, wird diese Meldung ausgegeben, wenn die Dateifreigabe zwischen Clusterknoten verschoben wird. Es sollte auch das Anti-Ereignis 30808 vorhanden sein, das angibt, dass die Sitzung mit dem Server wiederhergestellt wurde. Falls es sich bei dem Server nicht um einen Failovercluster handelt, war der Server zuvor wahrscheinlich online, aber nun ist über das Netzwerk kein Zugriff mehr auf den Server möglich.
Event id 30807:
Der Client hat die Sitzung mit dem Server wiederhergestellt.
Servername: \***
Serveradresse: 192.168.***:445
Sitzungs-ID: 0x1CC004C000041
Erläuterung:
Dieses Ereignis tritt auf, wenn zuvor das Ereignis 30805 vorhanden war, aber der Client die zwischengespeicherte Verbindung erfolgreich wiederhergestellt hat, bevor die Zeitüberschreitung eintrat.Diese Meldungen treten zu allen möglichen Uhrzeiten auf. Leider findet nirgendswo anders ein disconnect statt. Weder auf der NAS/Windows File Server(beides), noch beim Switch. Auch in der Firewall ist alles freigegeben und zeigt nur "allow".
Das ist im normalen Leerlauf kein wirkliches Problem, da die Verbindung ja wiederhergestellt wird, jedoch führt genau dieser Fehler seit letzter Woche immer wieder zu fehlerhaften Backups, da die Verbindung plötzlich weg ist.
Jetzt bin ich mir nicht sicher, ob da das letzten Windows CU etwas damit zu tun haben könnte?
Komischerweise gibt es diese kurzen Abbrüche auch auf anderen Maschinen, aber da läuft natürlich keine Backup Software drauf und zeigt keinerlei negative Auswirkung.
Meine Recherche im Internet und Kontakt zum Backup Software Hersteller hat bisher nichts Zielführendes ergeben.
Jetzt wollte ich mich mal an euch wenden, ob ihr so ein Verhalten schon mal beobachtet habt.
Angaben zum Setup:
1. Es handelt sich um eine Server 2016 VM auf ESXi. Neustes Windows CU(August). VMware ESXi, 7.0.3, 21686933.
2. Dito beim File Server.
3. Die NAS ist eine Synology. Neustes Update.
4. Das Alles hängt an einem Cisco 250er Switch.
5. Firewall von Securepoint mit einer "Any"-Regel vom Server zur NAS.
6. Die Server sind im selben Subnet.
7. Windows Firewall Regeln für Dateifreigabe sind auf grün.
Gruß
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: 8179653067
Url: https://administrator.de/contentid/8179653067
Printed on: April 27, 2024 at 12:04 o'clock
17 Comments
Latest comment
Moin @preysa,
ich Tippe auf die Securepoint FireWall.
FW's sind bekannt dafür, dass sie jegliche Art von Sessions auch mal "grundlos" mittendrin killen können. 🙃
Stelle mal Testweise dein NAS ins gleiche Netz wie die Server und schau ob das Problem danach immer noch auftritt.
Gruss Alex
ich Tippe auf die Securepoint FireWall.
FW's sind bekannt dafür, dass sie jegliche Art von Sessions auch mal "grundlos" mittendrin killen können. 🙃
Stelle mal Testweise dein NAS ins gleiche Netz wie die Server und schau ob das Problem danach immer noch auftritt.
Gruss Alex
1
Hi,
Viele Augen sehen mehr als eines! In diesem Artikel wird von einer GPO geschrieben die einen RegKey falsch setzt und deshalb SMB droppt:
https://community.spiceworks.com/topic/2358502-unc-connections-not-worki ...
Vielleicht hilft es...
Edit:
Weil ich Synology lese: SMB 3.x oder höher ist aktiviert nehme ich an. Mein Nas DS920+ hat sich immer angemacht, wenn ich Bonjour Services abgedreht habe. Alles 100% Windows. Seit die Dienste laufen keine Probleme. 113mb/s konstant bei großen Files. Also das Maximum
Viele Augen sehen mehr als eines! In diesem Artikel wird von einer GPO geschrieben die einen RegKey falsch setzt und deshalb SMB droppt:
https://community.spiceworks.com/topic/2358502-unc-connections-not-worki ...
Vielleicht hilft es...
Edit:
Weil ich Synology lese: SMB 3.x oder höher ist aktiviert nehme ich an. Mein Nas DS920+ hat sich immer angemacht, wenn ich Bonjour Services abgedreht habe. Alles 100% Windows. Seit die Dienste laufen keine Probleme. 113mb/s konstant bei großen Files. Also das Maximum
2
Synology hat die letzten Wochen ein Update für SMB herausgebracht. Vielleicht hat das was damit zu tun.
Die Lösung ware wohl eine Mischung aus mehreren Dingen.
Zum einen waren die Fehlerbehebungen, welche mir von den Technikern der Backup Software vorgeschlagen wurden, problematisch und haben die Timeouts nur noch schlimmer gemacht. Nachdem ich alle Änderungen rückgängig gemacht hatte, lief es schon wieder etwas zuverlässiger. Das zweite Problem war wirklich das von mayho33 verlinkte Thema, bei denen ich die NTMLv2 Einstellungen zu streng gesetzt hatte. Level 3 reicht bei Clients anscheinend vollkommen, level 5 sollte man nur bei DCs fahren. Damit waren die ganzen Error Meldungen - wie oben gepostet - alle verschwunden. Ich hoffe das bleibt auch so.
Vielen Dank euch!
Zum einen waren die Fehlerbehebungen, welche mir von den Technikern der Backup Software vorgeschlagen wurden, problematisch und haben die Timeouts nur noch schlimmer gemacht. Nachdem ich alle Änderungen rückgängig gemacht hatte, lief es schon wieder etwas zuverlässiger. Das zweite Problem war wirklich das von mayho33 verlinkte Thema, bei denen ich die NTMLv2 Einstellungen zu streng gesetzt hatte. Level 3 reicht bei Clients anscheinend vollkommen, level 5 sollte man nur bei DCs fahren. Damit waren die ganzen Error Meldungen - wie oben gepostet - alle verschwunden. Ich hoffe das bleibt auch so.
Vielen Dank euch!
👍👍👍
Ach Mist, zu früh gefreut... Es sah erst so gut aus und jetzt kommen die Fehler wieder...
Das Problem scheint jetzt gelöst zu sein.
Abgesehen von den anderen zwei Probleme, schien hier die mehrfache Verbindung zur NAS, von der selben Maschine ein Problem zu machen. Komischweise war dies seit über einem Jahr nie ein Problem. Ich kann nur vermuten, dass das letzte Windows Update irgendwas an der Art und Weise geändert hat, wie Windows damit umgeht.
Bisher war es kein Problem einmal direkt per IP und einmal per FQDN auf die NAS zuzugreifen. Nach dem letzten Update kam es hier aber immer wieder zu Fehlern. Es hatte mich nämlich stuztig gemacht, warum die plötzlichen Verbindungsabbrüche immer beim Verbindungsaufbau(im NAS Log) auftraten.
Ich habe jetzt testweise die zweite Verbindung zur NAS getrennt und bisher läuft alles wieder mit max. Geschwindigkeit und ohne Ausfälle.
Abgesehen von den anderen zwei Probleme, schien hier die mehrfache Verbindung zur NAS, von der selben Maschine ein Problem zu machen. Komischweise war dies seit über einem Jahr nie ein Problem. Ich kann nur vermuten, dass das letzte Windows Update irgendwas an der Art und Weise geändert hat, wie Windows damit umgeht.
Bisher war es kein Problem einmal direkt per IP und einmal per FQDN auf die NAS zuzugreifen. Nach dem letzten Update kam es hier aber immer wieder zu Fehlern. Es hatte mich nämlich stuztig gemacht, warum die plötzlichen Verbindungsabbrüche immer beim Verbindungsaufbau(im NAS Log) auftraten.
Ich habe jetzt testweise die zweite Verbindung zur NAS getrennt und bisher läuft alles wieder mit max. Geschwindigkeit und ohne Ausfälle.
Habe das bei mir gerade getestet. Erkenne keine negativen Effekte.
Das das alles aber Prozessor kostet und ja auf einer VM läuft, könnte das das Problem sein.
Ms hat schon mal was geändert bzgl SMB, aber das ist sicher schon 2 Jahre her.
Weoche SMB-Version läuft auf deinem Client hast du schon geprüft?
Eventuell mal das Netzwerk am Client zurücksetzen:
https://answers.microsoft.com/en-us/windows/forum/all/reset-network-adap ...
Das das alles aber Prozessor kostet und ja auf einer VM läuft, könnte das das Problem sein.
Ms hat schon mal was geändert bzgl SMB, aber das ist sicher schon 2 Jahre her.
Weoche SMB-Version läuft auf deinem Client hast du schon geprüft?
Eventuell mal das Netzwerk am Client zurücksetzen:
https://answers.microsoft.com/en-us/windows/forum/all/reset-network-adap ...
SMB 3.1.1
Den Reset hatte ich schon einmal gemacht und dann kurz gedacht es hätte das Problem gelöst, leider trat es dann kurzen Zeit später wieder auf.
Das andere Program, welches die zweite SMB Anbindung benutzte war übrigens Mailstore. Hier aber nur für regelmäßige Backups. Beide Verbindungen brachen zu unterschiedlichen Zeiten ab. Wahrscheinleich immer dieses, welches gerade mehr Bandbreite/Ressoucren beanspruchte.
Da mir die VM Backups wichtiger sind und ich Mailstore auch aus der virtuellen Festplatte wiederherstellen kann, ist das erst mal zweite Prio.
Den Reset hatte ich schon einmal gemacht und dann kurz gedacht es hätte das Problem gelöst, leider trat es dann kurzen Zeit später wieder auf.
Das andere Program, welches die zweite SMB Anbindung benutzte war übrigens Mailstore. Hier aber nur für regelmäßige Backups. Beide Verbindungen brachen zu unterschiedlichen Zeiten ab. Wahrscheinleich immer dieses, welches gerade mehr Bandbreite/Ressoucren beanspruchte.
Da mir die VM Backups wichtiger sind und ich Mailstore auch aus der virtuellen Festplatte wiederherstellen kann, ist das erst mal zweite Prio.
Moin @preysa,
hast du auf der vNIC, innerhalb der VM RSC eigeschaltet?
Ist auf dem 2016er Server der Defender noch aktiv?
Hast du schon mal versucht, das SMB Protokoll seitens Synology auf nur SMB2 einzuschränken?
Mit welcher Geschwindigkeit ist die VM bis an die NAS angebunden 1G oder 10G?
Eventuell spuckt dir auch SMB-Multichannel in die Suppe, das solltest du Testweise auch mal deaktivieren.
https://kb.synology.com/de-de/DSM/tutorial/smb3_multichannel_link_aggreg ...
Gruss Alex
hast du auf der vNIC, innerhalb der VM RSC eigeschaltet?
Get-NetAdapterRscIst auf dem 2016er Server der Defender noch aktiv?
Hast du schon mal versucht, das SMB Protokoll seitens Synology auf nur SMB2 einzuschränken?
Mit welcher Geschwindigkeit ist die VM bis an die NAS angebunden 1G oder 10G?
Eventuell spuckt dir auch SMB-Multichannel in die Suppe, das solltest du Testweise auch mal deaktivieren.
https://kb.synology.com/de-de/DSM/tutorial/smb3_multichannel_link_aggreg ...
Gruss Alex
Hi Alex,
Ja, RSC zeigt mir alles auf "True".
Defender ist aktiv aber ohne Echtzeitüberwachung und alle Ausnahmen sowohl für die Backup Software, als auch für Mailstore wurden gesetzt. SMB Connections kann man leider nicht ausschließen, wenn sie nicht als Network Share direkt im explorer vebunden sind.
Multichannel ist nicht aktiv. Die NAS ist zwar mit zwei der 4 Ethernet Port anschlossen, die laufen aber als BOND.
Leider haben wir nur 1Gbit.
Gruß
Ja, RSC zeigt mir alles auf "True".
Defender ist aktiv aber ohne Echtzeitüberwachung und alle Ausnahmen sowohl für die Backup Software, als auch für Mailstore wurden gesetzt. SMB Connections kann man leider nicht ausschließen, wenn sie nicht als Network Share direkt im explorer vebunden sind.
Multichannel ist nicht aktiv. Die NAS ist zwar mit zwei der 4 Ethernet Port anschlossen, die laufen aber als BOND.
Leider haben wir nur 1Gbit.
Gruß
Moin @preysa,
nix gut, das solltest du auf jeden Fall deaktivieren.
Beim Defender muss man immer mehr aufpassen, da Microsoft diesen immer weiter aufbläht.
Versuch mal testweise SMB auf V2 einzuschränken.
Gruss Alex
Ja, RSC zeigt mir alles auf "True".
nix gut, das solltest du auf jeden Fall deaktivieren.
Defender ist aktiv aber ohne Echtzeitüberwachung und alle Ausnahmen sowohl für die Backup Software, als auch für Mailstore wurden gesetzt. SMB Connections kann man leider nicht ausschließen, wenn sie nicht als Network Share direkt im explorer vebunden sind.
Beim Defender muss man immer mehr aufpassen, da Microsoft diesen immer weiter aufbläht.
Versuch mal testweise SMB auf V2 einzuschränken.
Gruss Alex
1
Also ich stehe hier echt auf den Schlauch...
Was ich bisher ausprobiert habe:
NAS wieder ins selbe VLAN genommen, wie der Backup Server.
In der Backup Software die SMB Verbindung von FQDN auf IP gewechselt.
Defender auf dem Server komplett deaktiviert.
SMB2 war leider nicht möglich. Mag der Server nicht. Ich habe aber mal die SMB3 Signierung deaktiviert. Hier ist anzumerken, dass die NAS nicht in die AD angebunden ist. Zugriff geschieht ausschließlich durch lokal angelegte Accounts.
Weiteres Suchen ergab:
Diese Disconnects gab es anscheinend schon jahrelang, haben aber nie Probleme verursacht.
Die Errors traten erst nach der letzten Datenbereinigung der NAS auf. Merkwürdigerweise würde ich hier, wenn irgendwas passiert sein sollte, vielleicht korrupte Dateien erwarten, aber ein Netzwerkausfall??? Es sein denn die Bereinigung hätte das DSM selber beschädigt. In den Logs, welche ich per SSH ziehen konnte, konnte ich keine errors finden.
Also ich bin da echt mit meinem Latein am Ende.
Was ich bisher ausprobiert habe:
NAS wieder ins selbe VLAN genommen, wie der Backup Server.
In der Backup Software die SMB Verbindung von FQDN auf IP gewechselt.
Defender auf dem Server komplett deaktiviert.
SMB2 war leider nicht möglich. Mag der Server nicht. Ich habe aber mal die SMB3 Signierung deaktiviert. Hier ist anzumerken, dass die NAS nicht in die AD angebunden ist. Zugriff geschieht ausschließlich durch lokal angelegte Accounts.
Weiteres Suchen ergab:
Diese Disconnects gab es anscheinend schon jahrelang, haben aber nie Probleme verursacht.
Die Errors traten erst nach der letzten Datenbereinigung der NAS auf. Merkwürdigerweise würde ich hier, wenn irgendwas passiert sein sollte, vielleicht korrupte Dateien erwarten, aber ein Netzwerkausfall??? Es sein denn die Bereinigung hätte das DSM selber beschädigt. In den Logs, welche ich per SSH ziehen konnte, konnte ich keine errors finden.
Also ich bin da echt mit meinem Latein am Ende.
Moin @preysa,
Na ja, Netzwerkausfälle hast du ja nicht wirklich, sondern genau genommen "nur" SMB Verbindungsabbrüche.
Und die können natürlich auch bei einem defekten Dateisystem auftreten.
Mach mal als nächstes bitte mal das folgende.
https://kb.synology.com/de-de/DSM/tutorial/What_should_I_do_if_a_file_sy ...
Gruss Alex
Diese Disconnects gab es anscheinend schon jahrelang, haben aber nie Probleme verursacht.
Die Errors traten erst nach der letzten Datenbereinigung der NAS auf. Merkwürdigerweise würde ich hier, wenn irgendwas passiert sein sollte, vielleicht korrupte Dateien erwarten, aber ein Netzwerkausfall???
Die Errors traten erst nach der letzten Datenbereinigung der NAS auf. Merkwürdigerweise würde ich hier, wenn irgendwas passiert sein sollte, vielleicht korrupte Dateien erwarten, aber ein Netzwerkausfall???
Na ja, Netzwerkausfälle hast du ja nicht wirklich, sondern genau genommen "nur" SMB Verbindungsabbrüche.
Und die können natürlich auch bei einem defekten Dateisystem auftreten.
Also ich bin da echt mit meinem Latein am Ende.
Mach mal als nächstes bitte mal das folgende.
https://kb.synology.com/de-de/DSM/tutorial/What_should_I_do_if_a_file_sy ...
Gruss Alex
Das betrifft aber nur ext4-volumes wenn ich das richtig verstehe. Bei uns läuft alles auf Btrfs und da gibt es so wie es verstehe nur die Dateibereinigung. Das Protokollcenter gibt mir keine Fehler aus, wie im weiterführenden KB-Artikel.
Moin @preysa,
OK, schau mal hier ...
https://gist.github.com/bruvv/d9edd4ad6d5548b724d44896abfd9f3f
Gruss Alex
Das betrifft aber nur ext4-volumes wenn ich das richtig verstehe. Bei uns läuft alles auf Btrfs und da gibt es so wie es verstehe nur die Dateibereinigung. Das Protokollcenter gibt mir keine Fehler aus, wie im weiterführenden KB-Artikel.
OK, schau mal hier ...
https://gist.github.com/bruvv/d9edd4ad6d5548b724d44896abfd9f3f
Gruss Alex
1
Ich denke, ich kann eine Fortschritt verzeichnen. Ich bin noch vorsichtig optimistisch, aber heute sind tatsächlich zum ersten mal alle Backups ohne jeglichen Mucks durchgelaufen.
Ich kann nur vermuten, dass diese Datenbereinigung das Dateisystem/Datenbank der Backup Software zerschoßen hat und es darum zu diesen Timeouts kam, welche wie von @MysticFoxDE richtig vermutet, nur auf korrupte Daten zurückzuführen wären. Das Windows diese als SMB Disconnects interpretiert, hilft bei der Fehlersuche leider wenig, da es zu falschen Schlüssen führen kann...
Ich habe jetzt einen neuen lokalen Shared Folder auf der NAS angelegt und dort die Backups von Null gestartet. Bisher sieht es sehr gut aus.
Von dieser Datenbereinigung lasse ich in Zukunft die Finger :D
Ich kann nur vermuten, dass diese Datenbereinigung das Dateisystem/Datenbank der Backup Software zerschoßen hat und es darum zu diesen Timeouts kam, welche wie von @MysticFoxDE richtig vermutet, nur auf korrupte Daten zurückzuführen wären. Das Windows diese als SMB Disconnects interpretiert, hilft bei der Fehlersuche leider wenig, da es zu falschen Schlüssen führen kann...
Ich habe jetzt einen neuen lokalen Shared Folder auf der NAS angelegt und dort die Backups von Null gestartet. Bisher sieht es sehr gut aus.
Von dieser Datenbereinigung lasse ich in Zukunft die Finger :D
1