October 4, 20241 yr Hallo zusammen, mein Unraid-System läuft nun seit über 4 Jahren, aber ich kämpfe schon seit Längerem mit wiederkehrenden Problemen. Das System dient als NAS sowie für diverse Docker-Container und eine VM, auf der Home Assistant läuft. Ich habe mein Netzwerk in VLANs unterteilt und im Unraid-Server virtuelle Netzwerkschnittstellen eingerichtet, um z.B. Home Assistant und bestimmte Docker-Container in mehrere VLANs zu verbinden. Die Hardware umfasst außerdem einen Coral PCIe, eine alte Nvidia-GPU, PCIe-Netzwerkkarten usw., die alle eigene Treiber benötigen. Zu den wichtigsten Problemen gehören: Diese Themen wurden bereits mehrfach in diesem Forum angesprochen, aber bisher konnte keine der vorgeschlagenen Lösungen meine Probleme beheben. Ich habe sogar den RAM ausgetauscht, aber das hat nichts geändert. SMB- und Netzwerk-Probleme: Die Übertragungen sind extrem langsam, brechen häufig ab, und die Logs sind voll mit Fehlermeldungen. Typische Fehler, die ich sehe, sind: Sep 17 12:03:01 Server samba-dcerpcd[2288]: Failed to fetch domain sid for WORKGROUP Sep 23 16:45:18 Server winbindd[4467]: Returning NT_STATUS_NO_SUCH_USER Die Home Assistant VM stürzt unregelmäßig ab, und in den Logs tauchen häufig Fehler im Zusammenhang mit dem RAM auf: 2024-10-03T18:30:33.352236Z qemu-system-x86_64: ram_block_discard_range: Failed to discard range pc.ram:17a48d000 +1000 (-22) Ich habe ein zweites Unraid-System im gleichen Netzwerk (gleiche VLANs usw.) eingerichtet, jedoch ohne Docker oder VMs. Auf diesem neuen, etwas schwächeren System läuft SMB stabil. Mein ursprüngliches System hat jedoch weiterhin mit Netzwerk- und SMB-Problemen zu kämpfen. Mir ist bewusst, dass eine Neuinstallation von Unraid im klassischen Sinne nicht sinnvoll ist, da das System im RAM läuft. Allerdings habe ich über die Jahre viele Einstellungen vorgenommen, teilweise über das Terminal und in Konfigurationsdateien (nicht nur über die GUI), und viele dieser Änderungen sind mir nicht mehr präsent. Daher überlege ich, ob ein Neustart eventuell doch Sinn machen könnte, auch wenn ich natürlich keinen Datenverlust im Array oder den Aufwand für die Neukonfiguration von Netzwerken, Treibern usw. riskieren möchte. Was würdet ihr mir raten? Neuinstallation, und alles mal wieder mit mehr Erfahrung neu und sauber aufbauen? Welche Best Practices gibt es, um Datenverlust und erneute Konfiguration zu minimieren? Oder soll ich weiter versuchen, das bestehende Setup zu durchleuchten, trotz der vielen früheren Änderungen in Shell und Konfigurationsdateien? Gibt es eine Möglichkeit, das neue System als Zwischenlösung zu nutzen und dann alles wieder auf den Hauptserver zu migrieren? Die Diagnose-Datei ist angehängt. Danke im Voraus für eure Hilfe! server-diagnostics-20241004-1428.zip
October 4, 20241 yr 21 minutes ago, Slarti123 said: Was würdet ihr mir raten? ich würde mir 1/ ein Backup des Ordners /config vom Stick kopieren, da sind alle persistent boot Parameter des OS 2/ schrittweise schauen was genau wo gemacht wurde ... Beispiel, dein go file # ------------------------------------------------- # Optimize write cache # ------------------------------------------------- sysctl vm.dirty_ratio=50 sysctl vm.dirty_expire_centisecs=3000 wenn das immer optimal wäre ... wäre das wohl auch die Standardeinstellung ... mal ohne getestet ? Beispiel, smb extra ... logging = syslog log level = 3 preferred master = yes os level = 255 winbind enum users = no winbind enum groups = no durable handles = no kernel oplocks = no strict locking = no oplocks = yes level2 oplocks = yes überlegen warum hast du das drin, mal ohne probiert ? Beispiel network ... bond0 konfiguriert, aber nur eth0 als Mitglied (in einem verbund), mal Gedanken gemacht und sauber konfiguriert ? Gleiches für bond1, ich weiß jetzt nicht ob das sein muss für vlans ... kann es mir aber nicht vorstellen. dann ist der eine cache auf zfs gestellt (Lexar), single disk ? wo zfs wenig bis gar keinen Sinn ergibt ? und das sicherlich nicht vor Jahren sondern ... ? VM setup (passthrough Thema) pcie_acs_override=downstream kann ein Problemlöser sein, kann auch Probleme verursachen ... warum hast du das aktiviert ? hattest du Probleme mit pcie passthrough von devices ? wenn ich das richtig sehe nutzt du gar kein pcie passthrough ... warum dann das setting ? boot stick ... auch schonmal ausgestiegen und in Windows was geschaut, sicher dass dieser ok ist ? -rw------- 1 root root 16384 Dec 31 1979 FSCK0000.REC -rw------- 1 root root 16384 Dec 31 1979 FSCK0001.REC -rw------- 1 root root 16384 Dec 31 1979 FSCK0002.REC drwx------ 2 root root 16384 Aug 29 2021 System Volume Information dann noch, AMD Ryzen 5 2600X Six-Core Processor ... sind (leider) nicht die beste Wahl ... gerade die etwas ältere gen ... hierfür, BIOS ... mal ein Update gemacht ? Release Date: 08/13/2020 VM Ram Fehler ... du hast ballooning aktiv ? also min / max nicht gleich ... auch bekanntermaßen nicht die beste Wahl ... sofern ich die xml richtig deute <memory unit='KiB'>7864320</memory> <currentMemory unit='KiB'>4194304</currentMemory> mal fix getestet wie empfohlen ? die Flut der Meldungen ... führe ich fast auf deine Änderungen der smb confis retour ... Oct 4 09:47:01 Server winbindd[8564]: [2024/10/04 09:47:01.697202, 1] ../../source3/winbindd/winbindd_getgroups.c:259(winbindd_getgroups_recv) Oct 4 09:47:01 Server winbindd[8564]: Could not convert sid S-1-5-21-1796248137-1714182103-198479257-1000: NT_STATUS_NO_SUCH_USER Oct 4 09:47:01 Server winbindd[8564]: [2024/10/04 09:47:01.697219, 3] ../../source3/winbindd/winbindd.c:563(process_request_done) Oct 4 09:47:01 Server winbindd[8564]: process_request_done: [nss_winbind(10677):GETGROUPS]: NT_STATUS_NO_SUCH_USER Oct 4 09:48:01 Server winbindd[8564]: [2024/10/04 09:48:01.800530, 3] ../../source3/winbindd/winbindd_misc.c:355(winbindd_interface_version) Oct 4 09:48:01 Server winbindd[8564]: winbindd_interface_version: [nss_winbind (12608)]: request interface version (version = 32) Oct 4 09:48:01 Server winbindd[8564]: [2024/10/04 09:48:01.800605, 3] ../../source3/winbindd/winbindd_misc.c:355(winbindd_interface_version) Oct 4 09:48:01 Server winbindd[8564]: winbindd_interface_version: [nss_winbind (12609)]: request interface version (version = 32) Oct 4 09:48:01 Server winbindd[8564]: [2024/10/04 09:48:01.800646, 3] ../../source3/winbindd/winbindd.c:496(process_request_send) Oct 4 09:48:01 Server winbindd[8564]: process_request_send: [nss_winbind (12608)] Handling async request: GETGROUPS Oct 4 09:48:01 Server winbindd[8564]: [2024/10/04 09:48:01.800662, 3] ../../source3/winbindd/winbindd_getgroups.c:63(winbindd_getgroups_send) Oct 4 09:48:01 Server winbindd[8564]: [nss_winbind (12608)] Winbind external command GETGROUPS start. Oct 4 09:48:01 Server winbindd[8564]: Searching groups for username 'root'. in Summe, zum Thema was du im Terminal mal eintippst ... ist ja in der Regel nicht persistent ... nur wo etwas auch auf den persistent storage geschrieben wird, bleibt auch da ... die ganzen oben erwähnten configs wurden ja entweder per terminal oder GUI geändert, liegen auf dem USB, docker create 1234 ... schreibt ins docker image / directory usw usw ... aber ansonsten ist das Meiste nach einem Neustart einfach weg würde ich jetzt mein System neu machen, Nein, ich würde mir die Fehler anschauen, dann versuchen die Ursachen zu finden und retour gehen ... RAM Fehler ... kommt man per google schnell auf ballooning ... die winbind Fehler ... schnell auf sambe ... so, was hab ich da eingestellt, einmal zurück und schauen ob es besser wird ... aber egal, deine Entscheidung Thema neu aufsetzen und Datenverlust, den Stick neu zu machen und bei "0" zu starten ... heißt erstmal nichts, sprich, alle persistent Daten (cache, disks, ...) bleiben erhalten, das nur als Info falls du doch den "harten" Weg gehen willst
October 4, 20241 yr Community Expert Also "gaaanz zürück" bei UNRAID ist schwierig, wie ich unlängst lernen musste. Bei den Versionsupdates wurden auch massig Defaults geändert, so dass ein heutiges "clean" System nicht mehr Deinem alten von vor 4 Jahren entsprechen würde. Damit handelst Du Dir u.U neue Fehler ein, die Du noch gar nicht kennst. Besser ist der Ansatz von @alturismo, sukzessive die manuellen Änderungen entfernen, neu booten und gucken... Bei den smb.extras sehe ich nun nichts, was wirklich "böse" aussieht, aber auch nix, was "hilfreich" sein könnte. Das Meiste ist mehr oder weniger Default (Und da kommen wir auf den einleitenden Satz zurück: "Defaults haben sich geändert") aus irgendeiner Periode. Weg damit und Ruhe sollte sein. Den Write Cache zu "optimieren" hat schon vielen Leuten die letzten Haare gekostet, weil keiner sagen kann, in welche Richtung er denn "optimal" ist. Du knallst erstmal 50% des RAMs voll bevor die Platten dann angeworfen werden und einen massiven Blutstau abzuarbeiten haben. Das sieht beim Windows File Transfer erstmal imposant aus, bricht dann aber abrupt und für lange Zeit auf fast 0 zusammen und blockiert das komplette System (was dann wieder zu Blutstau bei anderen Diensten führt). Der andere Ansatz wäre, den Cache schon bei 1 bis 2% zu begrenzen und somit die zu schreibenden Daten klein zu halten und IO Blockaden zu vermeiden. Sieht dann optisch langsamer aus, aber, wenn Du ne Stoppuhr nimmst, ist es bei großen Dateien meist gleich bis sogar schneller. Und andere Dienste können noch nebenher laufen. Quasi ein Smoothy... Oder eben gleich den aktuellen Default lassen. Ist der immer noch bei 10%? (ich kümmer mich da nicht mehr drum)
October 4, 20241 yr 13 minutes ago, MAM59 said: Oder eben gleich den aktuellen Default lassen. Ist der immer noch bei 10%? (ich kümmer mich da nicht mehr drum) yep ... ist er noch
October 4, 20241 yr Author Alles klar, dann mache ich mich mal ans Aufräumen, ist mir auch lieber so- vielen Dank für Eure Unterstützung. Vorweg: Alle Änderungen oben sind nach und nach auf Hinweise aus dem Forum entstanden, um vor allem dem SMB Thema Herr zu werden. Ich habe daher einiges zurückgedreht, aber bislang kann ich noch immer keinen Transfer per SMB starten. Hier schonmal den Zwischenstand: Go Datei: RAM Write Cache wieder auf Standard SMB Extra wieder komplett leer Network bonds weg Lexar ist lediglich die appdata disk, habe sie aber jetzt auf xfs formatiert pcie_acs_override: deaktiviert Boot Stick: Ersetze ich morgen sicherheitshalber, check hat aber nichts ergeben Bios Update ausgeführt CPU: Identisch im Ersatzgerät, das keine Probleme macht VRAM wieder ohne Ballooning (auch das war relativ neu angepasst als Tipp aus dem Forum, um die Fehler auszumerzen) Ich lasse gerade mal memtest laufen, ob es doch am RAM liegt. Vor dem Memtest war allerdings das SMB Thema unverändert: Winclients auf den Ersatz-Unraid: Sehr schnell (>100Mb/s) iperf3: von allen winclients auf meinen eigentlichen Unraid: 10gbe Winclient zu Winclient per SMB: erwartete, gute Geschwindigkeit Schreibtest auf Cache drive war 1.3GB/s: dd if=/dev/zero of=/mnt/cache_ssd/testfile bs=1G count=5 oflag=direct mover manuell von cache auf array auch normal (>30MB/s) SMB von jedem Winclient zum Unraud: Progress steckt bei 0% und bricht irgendwann ab. Manchmal sehr langsame Schreib- und Lesezeiten Soviel zum Tatus Quo. Memtest läuft und morgen neuen USB Stick einrichten. Aber vermutlich bin ich noch immer nahe null (mit einem etwas saubereren System- immerhin). Schonmal Danke für die moralische und inhaltliche Unterstützung!
October 4, 20241 yr Author Update: 5h Memtest (4 Durchgänge) ohne irgendeinen Fehler Habe temporär FTP enabled: Übertragung von einem Win Client mit 2.5Gbe war sehr schnell, konnte bei einem 1.5Gb file keine Zeit stoppen (<5s) SMB immernoch langsam Edited October 5, 20241 yr by Slarti123
October 5, 20241 yr Community Expert 4 hours ago, Slarti123 said: Übertragung von einem Win Client mit 2.5Gbe war sehr schnell Aaah! Das SMB-Killer-Potential! Bei 2,5G musst Du DRINGEND darauf achten, dass ALLE beteiligten Komponenten "Flow Control" aktiviert haben und auch beherrschen. Sonst reden die Kisten bei der Belegung der Timeslots aneinander vorbei und keiner versteht den anderen (Effekt: kriechender, bis gar kein Transfer). Wenn nur SMB betroffen ist, siehts allerdings mau aus.
October 6, 20241 yr Author Habe jetzt beides probiert: einmal überall an und einmal überall aus- kein Effekt. Habe sogar sicherheitshalber mal die NICs der beiden Unraid Systeme getauscht- auch alles beim Alten. Ich tippe noch immer auf irgendwas bei der SMB Einrichtung. Bekomme ja auch diese zahlreichen winbindd Fehler. Allerdings seltsam, weil ich ja alles wieder vermeintlich zurückgedreht habe...
October 7, 20241 yr @JorgeB may an idea where those errors may be related from ... ? Oct 4 09:47:01 Server winbindd[8564]: [2024/10/04 09:47:01.697202, 1] ../../source3/winbindd/winbindd_getgroups.c:259(winbindd_getgroups_recv) Oct 4 09:47:01 Server winbindd[8564]: Could not convert sid S-1-5-21-1796248137-1714182103-198479257-1000: NT_STATUS_NO_SUCH_USER Oct 4 09:47:01 Server winbindd[8564]: [2024/10/04 09:47:01.697219, 3] ../../source3/winbindd/winbindd.c:563(process_request_done) Oct 4 09:47:01 Server winbindd[8564]: process_request_done: [nss_winbind(10677):GETGROUPS]: NT_STATUS_NO_SUCH_USER Oct 4 09:48:01 Server winbindd[8564]: [2024/10/04 09:48:01.800530, 3] ../../source3/winbindd/winbindd_misc.c:355(winbindd_interface_version) Oct 4 09:48:01 Server winbindd[8564]: winbindd_interface_version: [nss_winbind (12608)]: request interface version (version = 32) Oct 4 09:48:01 Server winbindd[8564]: [2024/10/04 09:48:01.800605, 3] ../../source3/winbindd/winbindd_misc.c:355(winbindd_interface_version) Oct 4 09:48:01 Server winbindd[8564]: winbindd_interface_version: [nss_winbind (12609)]: request interface version (version = 32) Oct 4 09:48:01 Server winbindd[8564]: [2024/10/04 09:48:01.800646, 3] ../../source3/winbindd/winbindd.c:496(process_request_send) Oct 4 09:48:01 Server winbindd[8564]: process_request_send: [nss_winbind (12608)] Handling async request: GETGROUPS Oct 4 09:48:01 Server winbindd[8564]: [2024/10/04 09:48:01.800662, 3] ../../source3/winbindd/winbindd_getgroups.c:63(winbindd_getgroups_send) Oct 4 09:48:01 Server winbindd[8564]: [nss_winbind (12608)] Winbind external command GETGROUPS start. Oct 4 09:48:01 Server winbindd[8564]: Searching groups for username 'root'.
October 7, 20241 yr Community Expert versuchst Du da etwa von windows aus als "root" auf UNRAID zuzugreifen??? "root" ist immer verboten, Du musst schon einen anderen User anlegen und dem die SMB Rechte erteilen.
October 7, 20241 yr Author Nein, ich habe sogar zwei Varianten von diversen Win Clients getestet: Userbasiert: Nutzer "Tobias" mit entsprechenden Rechten Clientbasiert: Nutzer "WZ-PC" mit entsprechenden Rechten Edited October 7, 20241 yr by Slarti123
October 7, 20241 yr Community Expert 4 minutes ago, Slarti123 said: Userbasiert: Nutzer "Tobias" mit entsprechenden Rechten Clientbasiert: Nutzer "WZ-PC" mit entsprechenden Rechten Clientbasiert gibts nicht Und Userbasiert überschreiben die eventuell hinterlegten "Windowsanmeldeinformationen" ggf den aktuellen Windowsbenutzer. Also guck da nochmal rein, lösche, korrigiere oder lege neue an an den entsprechenden Orten. Von alleine taucht "root" nicht auf, den hast Du schon irgendwo eingetragen.
October 7, 20241 yr Author Ich habe mich da evtl. schlecht ausgedrückt. Ich habe in unraid user angelegt: Einmal bezogen auf einzelne Personen ("Tobias") und, als ich den Fehler eingrenzen wollte, nochmal explizit bezogen auf die jeweiligen clients, damit ich weiß, von wo welche Anmeldung kommt (also ein Unraid User mit dem Namen "WZ-PC" für den entsprechenden PC) Root habe ich definitiv nie als SMB Credential an irgendeinem Client genutzt
October 7, 20241 yr Community Expert 10 minutes ago, Slarti123 said: Root habe ich definitiv nie als SMB Credential an irgendeinem Client genutzt Irgendeiner hat aber gemäs Deinen Logdaten 6 hours ago, alturismo said: Oct 4 09:48:01 Server winbindd[8564]: Searching groups for username 'root'. Das kommt ja nicht von ungefähr. 6 hours ago, alturismo said: Oct 4 09:47:01 Server winbindd[8564]: Could not convert sid S-1-5-21-1796248137-1714182103-198479257-1000: NT_STATUS_NO_SUCH_USER und das auch recht häufig. Da versucht es jemand mit falschen Credentials. Wird wohl ne Windowskiste sein steht zu vermuten. Oder versuchst Du von UNRAID einen Share zu mounten???
October 7, 20241 yr Author Ok, ein erneutes Update. 1) Root Thematik: Ich habe jetzt alle Win Clients gestartet und überall alle shares getrennt. Danach im Windows Credential Manager nachgesehen, ob irgendwo Root angelegt ist- war nicht so. Dann sämtliche Windows Clients und den Unraid Server neu gestartet. Trotzdem: root@Server:~# grep root /var/log/syslog Oct 7 18:37:01 Server winbindd[29986]: Searching groups for username 'root'. Oct 7 18:37:51 Server smbd[12377]: string_to_sid: SID root is not in a valid format Oct 7 18:37:51 Server smbd[12377]: Forcing Primary Group to 'Domain Users' for root Was ggf. sein kann: Dass irgendein plugin/docker/Home Assistant VM eines der shares als root ansprechen will. 2) Speed Thematik: Wirklich kurios: Ich habe einen anderen 2.5G/10G SFP+ Switch ausgeliehen. Exakt gleiche Verkabelung => alles läuft auf erwartet hoher Geschwindigkeit auch bei SMB. Habe mich dann gefreut, auf flow control, negotiation oder was auch immer in dem unmanaged switch getippt und dann spaßeshalber mal alles runtergefahren und den bisherigen Switch wieder reingehängt: Auch da läuft jetzt alles in top Geschwindigkeit. (Ich traue dem Braten noch nicht so recht, falls irgendwas im Router schuld gewesen sein sollte und es erin Zufall mit dem anderen Switch war) Also, schonmal danke für die Hilfe bis hierher. Ich würde mich aber trotzdem freuen, wenn wir das Root Thema noch bei der Wirzel packen könnten. Das sol ja ohnehin nicht sein....
October 7, 20241 yr Community Expert 39 minutes ago, Slarti123 said: (Ich traue dem Braten noch nicht so recht, falls irgendwas im Router schuld gewesen sein sollte und es erin Zufall mit dem anderen Switch war) Nun ja, unmanaged Switche haben zwei Arten Flow Control Angebote zu bearbeiten: a) der "gute" Switch weis, dass er blöd ist und leitet den erweiterten Header (also MIT Angebot) einfach braun weiter. b) der "böse" Switch erkennt, dass die Header "nicht so ganz normal" sind und holt seinen internen Messias raus: er löscht das Angebot Welchen davon man hat, weis man nicht und kann es schlecht überprüfen. Hier hilft nur das Prinzip Hoffnung. (oder lieber gleich einen managed Switch kaufen, da kann man es sowohl sehen, als auch einstellen)
October 7, 20241 yr Author Das ist klar, aber, was mich wundert: Nachdem ich wieder alles in den ursprünglichen switch gesteckt habe, läuft es noch immer problemlos. Das kann ich mir nicht wirklich erklären.
October 8, 20241 yr Community Expert Na ja, Slartibartfast hat ja auch nie verstanden, was die Leute so an seinen Fjorden fanden... 🙂 Nimms hin und gräme Dich nicht. Wenns wieder auftaucht weist Du ja, wo Du Dir den heilsamen Switch leihen kannst, bzw. welchen man kaufen sollte.
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.