Hallo, ich Nutze Unraid schon eine ganze Weile und hatte eigentlich nie Probleme. Aber seit ca. dem Update auf 7.0.0 stürzt mein Unraid immer mal wieder ab. Erst hatte ich den USB Stick im verdacht, also habe ich diesen getauscht, aber weiterhin abstürze. Hab auch schon Google AI befragt und rumgegooglt, aber da kommt nur Müll bei raus. Ich bin kein Unraid Profi und weiß einfach nicht weiter. Hab das Forum hier auch noch nie für fragen genutzt und hoffe jetzt auf eure Hilfe. Falls ich das hier an einer falschen Stelle poste Sorry aber kenne mich hier leider Null aus. Hab die Diagnosticcs mal angehangen. Falls Ihr fragen oder mehr Input braucht ich stehe zur Verfügung. Der Server lief Monate lang früher ohne Probleme und jetzt nervt es langsam.... Hoffe auf eure Hilfe.... LG

Zum System:

Processor

12th Gen Intel® Core™ i7-12700 @ 2079 MHz

Motherboard Temperature: 16.8 °C

Gigabyte Technology Co., Ltd. Z790 D , Version x.x American Megatrends International, LLC., Version F6 BIOS dated: Monday, 01-12-2025

Ram: 2x DDR5-A2: Micron Technology CT32G48C40U5.M16A1, 32 GiB DDR5 @ 4800 MT/s

Gehäuse : ein HL15 von 45Homelab

auf dem Mainboard auf ersten PCIE Platz ich eine LSI HBA Karte im IT Mode

auf dem letzten PCIE Platz ich eine Adapterkarte wo man 4 M2 SSD reinpacken kann ( ist aber nur eine drin) dazwischen eine extra 2,5G netzwerkkarte eine M2 SSD OnBoard und eine Google Coral M2 auch Onboard.

Aktuell sind 7 HDD´s und 2 Sata SSD verbaut.

tower-diagnostics-20260411-2256.zip

7 hours ago, MarMue said:

Aber seit ca. dem Update auf 7.0.0 stürzt mein Unraid immer mal wieder ab.

beschreib mal was du meinst bitte.

Server nicht mehr erreichbar ?

Dienste nicht mehr erreichbar ? (Dockers, smb, ...)

Harte Neustarts aus dem Nichts ?

in den logs ist jetzt nicht wirklich was drin wo ganz klar wäre was ... diverses

was macht der Client da

Apr 4 21:37:54 Tower nginx: 2026/04/04 21:37:54 [error] 15382#15382: *60054 limiting requests, excess: 20.462 by zone "authlimit", client: 192.168.178.144, server: , request: "PROPFIND /login HTTP/1.1", host: "192.168.178.40"

Apr 4 21:37:54 Tower nginx: 2026/04/04 21:37:54 [error] 15382#15382: *60056 limiting requests, excess: 20.421 by zone "authlimit", client: 192.168.178.144, server: , request: "PROPFIND /login HTTP/1.1", host: "192.168.178.40"

Apr 4 21:37:54 Tower nginx: 2026/04/04 21:37:54 [error] 15382#15382: *60058 limiting requests, excess: 20.381 by zone "authlimit", client: 192.168.178.144, server: , request: "PROPFIND /login HTTP/1.1", host: "192.168.178.40"

...

..

.

wieso diese Einträge

BOOT_IMAGE=/bzimage vfio_iommu_type1.allow_unsafe_interrupts=1 initrd=/bzroot modprobe.blacklist=r8169 i915.enable_dc=0 pcie_aspm=off

als Fritz User und ipvlan, wenn da eine andere IP noch läuft ist ipvlan bei Fritz kritisch

Apr 11 22:34:18 Tower rc.docker: created network ipvlan br1 with subnets: 192.168.178.0/24;

usw usw, aber sag mal bitte an was genau du meinst mit "crash"

Der Server ist nicht mehr erreichbar dann. Weder er SSH noch per GUI also übers Web Frontend.

Er läuft aber noch... Nach einen Hard Reset, also neu starten per Knopft halten läuft er wieder ganz normal für nen paar Tage und stürzt den wieder ja. Hab im BIOS schon Asmp und C-States deaktiviert soweit es halt geht da. Hab irgendwo gelesen gehabt der die CPU vllt zu hart in den Idel geht.

Wenn ich den Server am Bildschirm habe ist das Bild auch eingefroren und nicht lesbar.

RAM Test auch schon gemacht über Nacht ohne Fehler.

Bin kein Fritz User. Nutze OpnSense nur der IP Bereich ist der alte...

Edited April 13Apr 13 by MarMue

Was steht in deiner Syslog zu der Zeit, in der du aufm Server nicht mehr zugreifen konntest?
Hat der Bildschirm dir was ausgegeben?

Ich Versuche mal ob ich morgen eine Log von einem Absturztag finde. Die Log dicht einfach weg. Komisch ist halt der der Server läuft die Platten alle wohl drehen, weil er den von der Lautstärke so ist als würde der Parity Check laufen. Er aber nicht erreichbar ist. Auch kein Docker und keine VM. Ich hab's einmal direkt mitbekommen und den Monitor dran gehabt , die Ausgabe war eingefroren und total verschwommen/zerrissen... Versuche auch mal das Bild davon zu finden.

Edited April 13Apr 13 by MarMue

8 minutes ago, MarMue said:

hab's einmal direkt mitbekommen und den Monitor dran gehabt , die Ausgabe war eingefroren und total verschwommen/zerrissen... Versuche auch mal das Bild davon zu finden.

Dem Video nach zu urteilen: Die Grafikfunktion ist defekt.

Kannst Du zu Testzwecken mal eine andere GPU einbauen und damit testen. Die Alte GPU dabei soweit möglich abschalten.

Hab keine externe GPU sondern eine im Prozessor selbst (APU nennt man das glaube ich dann). Hab aber auch keinerlei Transkoding oder so momentan aktiv.

3 hours ago, MarMue said:

Hab keine externe GPU sondern eine im Prozessor selbst (APU nennt man das glaube ich dann). Hab aber auch keinerlei Transkoding oder so momentan aktiv.

Ich schrieb mit Absicht im Zusammenhang der vorhandenen GPU auch nicht von einer dGPU.

Und transcoding ist auch nicht erforderlich, wenn es um die simple Bildschirmausgabe geht.

Mir sieht das Bild im Video nach einem Problem in der GPU (egal ob i oder d) aus.

Sowas (damit meine ich die strichartigen Bereiche zwischen den Textzeilen) sehe ich meist bei Ram Problemen der GPU (und auch wenn Software im Rambereich rumpfusht, welcher der GPU eigentlich exklusiv zugeordnet sein sollte).

Um das herauszufinden würde ich (wie erwähnt) die vorhandene GPU deaktivieren (im UEFI BIOS kann man das in einigen Boards einstellen - oder zumindest welche die 1. GPU ist) und eine extra dGPU einsetzen um zu testen ob es damit wieder auftritt.

Wenn es mit extra dGPU nicht passiert kann es eben an der ursprünglichen GPU liegen.

Da eine iGPU sich aus dem PC Standard Ram (steckbare Module von CPU Cache gepuffert) bedient (der ja vom normalen steckbaren RAM 'abgeknabbert' wird und somit bei Tests von Memtest86 oder so nicht angetastet wird (weil sonst die Videoausgabe futsch wäre) kann es dann also entweder doch im steckbaren PC Ram, der iGPU selbst oder dem Cache der CPU zwischen CPU und gestecktem Ram (der ja auch Ramzugriffe der Videofunktionen beschleunigt) liegen.

Solltest Du mehrere RAM Module verwenden kannst Du die mal in der Steckfassung gegeneinander austauschen: da die Videofunktion meist einen festgelegten Bereich im gesamten Speicherplatz zugeordnet bekommt würde beim nächsten Booten der Bereich eines anderen Riegels verwendet und ein neuer Speichertest würde dann den ursprünglich verwendeten Rambereich mittesten können, weil er ja jetzt physikalisch wo anders sitzt und somit auch logisch anders adressiert wird. Das dann (sofern möglich) mindestens 24h testen lassen.

Um die GPU generell zu testen würde mir die Idee kommen die mit (windows) Furmark 2 mal wirklich auf Last zu bringen und so 2 Tage oder so maximal durchlaufen zu lassen. Wenn die das ohne Ausfälle übersteht sollten die in Silikon gegossenen Schaltkreise okay sein.

Aber das erfordert eben eine Win Installation (oder gibt es Furmark auch für Linux?) auf dem System.

Mehr fällt mir dazu auch nicht ein.

Danke, ich werde das mal ausprobieren. Falls der Server demnächst wieder abschmiert werde ich die Log hier hochladen.

so... heute morgen ist er mal wieder abgeschmiert. Anbei mal die Log. PS sie hört einfach auf.

syslog18.04.26.txt

Also ich finde Deinen Aufbau etwas mystisch...

Du hast das Nextcloud AIO am Laufen (was ich per se schon mal "gefährlich" nenne), aber das dann auch noch über ein Cache Drive ?!?!?.

Das ist SEEEHR mutig und ich weiß nicht, was passiert, wenn der Mover zuschlägt und Aufräumen will.

Der Absturz erfolgte ja wohl einwandfrei nach diversen Updates von Nextcloud und Wiedererstellung des Cache Verzeichnisses. Aber da läuft Nextcloud ja schon wieder, das kann dann einen Konflikt geben...

Ich nutze das offizielle Addon aus dem AppStore und hab es laut Anleitung von space Invader One installiert. Und Docker laufen doch allgemein im Cache.? Die Daten in Nextcloud werden per Mover dann aufs Array geschoben. Was ist da mystisch? Ich lerne gerne neues wenn es verbesserungs Vorschläge gibt immer her damit !

48 minutes ago, MarMue said:

Ich nutze das offizielle Addon aus dem AppStore und hab es laut Anleitung von space Invader One installiert

Ja, genau DAS hatte ich befürchtet 😁

Sagen wir mal so: sowohl Addon als auch Anleitung sind nicht ganz konfliktfrei und stabil.

Es funktioniert irgendwie bei schönem Wetter, 20-25° und ganz leichtem Ostwind...

Du findest hier einige Threads zu dem Thema, ich war auch mal ein Opfer und schlafe erst ruhiger, seit der Kram, gegen "was Richtiges" ausgetauscht wurde.

50 minutes ago, MarMue said:

Und Docker laufen doch allgemein im Cache.?

Ja, aber da er das Verzeichnis erst NACH den Updates anlegt, komme ich auf die Idee, dass auch "mehr als der Docker" im Cache läuft. Kein Problem, solange da nicht so was wie "primary: cache, secondary:array" hinterlegt ist (der Mover also zuschlagen könnte).

Und er scheint ja direkt nach dem Anlegen des Verzeichnisses den Weg in die ewigen Jagdgründe genommen zu haben.

Edited April 18Apr 18 by MAM59

Das komische ist ja das der Server eine bis zwei Wochen läuft und den auf einmal ist er abgeschmiert. Und wieso ist der Aufbau von Nextcloud AIO verkehrt? Hab mich da eigentlich drauf verlassen weil es sogar ein Tutorial von einem Unraid Urgestein gibt.

2 hours ago, MarMue said:

Das komische ist ja das der Server eine bis zwei Wochen läuft und den auf einmal ist er abgeschmiert.

ja, könnte das mit den Nextcloud Updates zusammenhängen???

Und wieso ist der Aufbau von Nextcloud AIO verkehrt?

Da findest Du hier im Forum reichlich Infos zu, such einfach nach "Nextcloud AIO"...

Hab mich da eigentlich drauf verlassen weil es sogar ein Tutorial von einem Unraid Urgestein gibt.

Nun ja, er hat es ja gut gemeint, aber grobe Fehler ignoriert. So haben schon einige Probleme bekommen um an ihre Daten zu kommen.

Das Hauptproblem besteht mit Dateiberechtigungen / Eigentumsrechten. Mach auf KEINEN FALL "Docker Safe Permissions" in für Deine Nextcloud Platte!

Danach hast Du echt Stress und AIO startet nicht mehr...

???

37 minutes ago, MarMue said:

???

kurz, die AIO Lösung ist auch meiner Meinung nach "Kernschrott" ;) aber ich verstehe den Hintergrund, gern gelesen dass das die beste Lösung wäre, dann noch von einem gern genommenen Unraider, absolut verständlich.

du hast keine Kontrolle und da werden intern dockers angelegt (wie du auch bei Updates in deinem log siehst), Daten mit allen möglichen Rechten vergeben, usw usw

Beispiel, du willst "reset" machen, dazu muss man da dann intern images manuell löschen oder am Besten Docker komplett löschen und alles neu machen, wenn da einmal der Wurm drin ist ... ist es halt kritisch.

Ich tippe hier langsam eher auf ein Hardware Problem in irgendeiner Form, sowie da Activity kommt usw crasht dein System leider anscheinend "lautlos".

Du hast ne Menge Komponenten verbaut an Controller und co, da nirgends ein echter Fehler kommt ist es leider schwer zu benennen.

Gibt es den eine Saubere Lösung Nextcloud zu betreiben? Und wenn ja wie? Ja hätte vorher zwei HBA Karten, den eine HBA Karte mit Expander Karte und jetzt nur noch eine HBA Karte die aber moderner und alle Platten schafft. Ich glaube langsam es liegt echt an den PCI Lanes. Also zu wenigen oder so. Komischerweise hätte ich vor Unraid 7.0.0 keinen Ärger erst danach fing es an. Aber wann genau weiß ich leider auch nicht mehr. Und in der Zwischenzeit kam und ging auch Hardware.

Fehlende Lanes würden sich anders und schneller auswirken.

Z.B. mit fehlenden Festplatten oder fehlenden Geräten (z.B. NVMe SSDs)

Es ist deshalb unwahrscheinlich, dass es an der Hardware liegt (außer es gibt sporadische Probleme wie Überhitzung oder so was).

Nextcloud sauber? Ich kenne nur die Lösung "auf einer separaten Kiste" (oder in einer VM). Also irgendein Linux (oder besser FreeBSD) und darauf die Komponenten Apache / PHP / Mysql und Nextcloud schön von Hand einzeln installieren. Vorher einen ausreichend großen Datenbereich anlegen (ZFS-Raid oder so).

Docker mit Nextcloud sind mir noch keine "guten" untergekommen, das liegt vor allen Dingen eben an den Dateiberechtigungen. Nextcloud will auch die Dateien der (lokalen) Benutzer gegeneinander absichern, das passt nicht zu UNRAIDs Ansatz "alles gehört Nobody und die Rechte regeln wir beim LAN Zugriff".

Da findest Du keine gemeinsamen Nenner.

Das was es gibt "geht" halt irgendwie, aber nie "richtig"

Hmmm... Den bin ich weiterhin auf Fehlersuche...