Hallo zusammen,

ich nutze unraid nun schon ein paar Jahre und hatte vor ca. 1 Monat auf Version 7.2.2. geupdatet.

Davor war ich noch auf 6.5 oder sowas.

Seitdem habe ich extreme Probleme, dass der Server ausfällt, sprich Web Oberfläche nicht mehr erreichbar und docker services auch nicht. Ich mache dann einen Stromreset damit es wieder geht.

Anfangs war das Problem noch 1x die Woche und nun bin ich schon bei 2x täglich 😭

Ich weiß nicht, wie ich herausfinden kann, wo genau das Problem liegt, denn ich kann ja nicht mehr den Server erreichen.

Unter logs, web ich dort zb im sylog mach warnings Suche finde ich lediglich:

Dec 15 16:22:37 Tower rc.docker: Pihole-DoT-DoH: Error response from daemon: Address already in use
Dec 15 16:22:37 Tower rc.docker: Error: failed to start containers: Pihole-DoT-DoH
Dec 15 16:22:37 Tower rc.docker: Pihole-DoT-DoH: Error response from daemon: Address already in use
Dec 15 16:22:37 Tower rc.docker: Error: failed to start containers: 

Gibt es irgendwo noch logs oder anderes was ich durchsuchen kann? Weiß sonst nicht weiter 😕

10 hours ago, postboy99 said:

Davor war ich noch auf 6.5 oder sowas.

Man muß das System alt sein. Ich bin vor rund 3-4 Jahren bei 6.9 in unraid eingestiegen...

Bei dem Alter sind auch schleichende Hardwarefehler nicht unwahrscheinlich. Vielleicht mal 'nen Tag lang Memtest oder so laufen lassen wäre eine Idee.

10 hours ago, postboy99 said:

Seitdem habe ich extreme Probleme, dass der Server ausfällt, sprich Web Oberfläche nicht mehr erreichbar und docker services auch nicht.

Sowas klingt meist nach Netzwerk Konfigfehlern.

Unraid der letzten 6.xx versionen hatte da Probleme mit Zuordnungen nach MAC oder so bei Fritzboxen oder auch den Unifi Dingern. Vielleicht ebschreibst Du Deine Netzwerkhardware mal etwas (zusätzlich zu der unten erwähnten diagnostics).

Ist lokaler Zugang per Tastatur/Bildschirm möglich?

10 hours ago, postboy99 said:

Ich mache dann einen Stromreset damit es wieder geht.

Sowas ist gefährlich für btrfs und Raminhalt.

10 hours ago, postboy99 said:

Anfangs war das Problem noch 1x die Woche und nun bin ich schon bei 2x täglich 😭

ich befürchte bei einem der Hardreset ist ein btrfs System angeschlagen worden, was sich nun weiter fortsetzt.

10 hours ago, postboy99 said:

Ich weiß nicht, wie ich herausfinden kann, wo genau das Problem liegt, denn ich kann ja nicht mehr den Server erreichen.

Bitte aktiviere (wenn Zugriff besteht) die Speicherung des Syslog auf den USB Stick, so besteht die größere Chance beim nächsten crash dennoch was hilfreiches in dem Syslog zu finden.

10 hours ago, postboy99 said:

Unter logs, web ich dort zb im sylog mach warnings Suche finde ich lediglich:

Dec 15 16:22:37 Tower rc.docker: Pihole-DoT-DoH: Error response from daemon: Address already in use
Dec 15 16:22:37 Tower rc.docker: Error: failed to start containers: Pihole-DoT-DoH
Dec 15 16:22:37 Tower rc.docker: Pihole-DoT-DoH: Error response from daemon: Address already in use
Dec 15 16:22:37 Tower rc.docker: Error: failed to start containers: 

Was ist, wenn Du Pihole mal ein paar Tage abschaltest? Bleibt das Problem oder bleibt der Zugriff stabil?

Ohne jetzt genau zu wissen, was da passiert ist oder wo das Problem liegt:

Bei einigen Fällen ähnlicher Beschreibung nach Updates zeigten sich btrfs Fehler. Falls Du btrfs einsetzt, überprüfe das Dateisystem mal.

(Da 6.5 meiner Erinnerung nach noch kein zfs kannte, dürfte der Einsatz von btrfs sehr wahrscheinlich sein.)

Auch könnte es helfen, wenn Du eine diagnostics hier mal anbietest, womit man sich die Sache genauer ansehen kann.

16 hours ago, DataCollector said:

Sowas klingt meist nach Netzwerk Konfigfehlern.

Unraid der letzten 6.xx versionen hatte da Probleme mit Zuordnungen nach MAC oder so bei Fritzboxen oder auch den Unifi Dingern. Vielleicht ebschreibst Du Deine Netzwerkhardware mal etwas (zusätzlich zu der unten erwähnten diagnostics).

Ist lokaler Zugang per Tastatur/Bildschirm möglich?

Ich habe ein 1G Anschluss am Server, dort zum TP-Link Switch und dann direkt zur Fritzbox. Dort gebe ich der NAS eine feste IP. Kleine Bildschirm habe ich mal bestellt zum schauen, wenn Problem erneut auftritt.

Bitte aktiviere (wenn Zugriff besteht) die Speicherung des Syslog auf den USB Stick, so besteht die größere Chance beim nächsten crash dennoch was hilfreiches in dem Syslog zu finden.

So sollte passen?

Was ist, wenn Du Pihole mal ein paar Tage abschaltest? Bleibt das Problem oder bleibt der Zugriff stabil?

Ich habe jetzt mal alle nicht extrem wichtigen Docker heruntergefahren und werde es beobachten.

Bei einigen Fällen ähnlicher Beschreibung nach Updates zeigten sich btrfs Fehler. Falls Du btrfs einsetzt, überprüfe das Dateisystem mal.

Ich habe auf meiner einen von 2 HDDs ein paar SMART errors(aber schon seit einiger Zeit) aber das sollte doch nicht zum Systemabsturz führen, da Container auf der SSD laufen oder?!

Auch könnte es helfen, wenn Du eine diagnostics hier mal anbietest, womit man sich die Sache genauer ansehen kann.

Klar - siehe Anhang.

Vielen Dank für deine ausführliche Hilfe!

tower-diagnostics-20251216-2003.zip

2 hours ago, postboy99 said:

Ich habe ein 1G Anschluss am Server, dort zum TP-Link Switch und dann direkt zur Fritzbox.

Also eine Fritzbox als Router.

(ich bin gerade zu blind die Einstellung in der Diagnostics zu finden): zeige bitte mal die Advanced Einstellung des Docker Dienstes (Settings -> Docker -> Advanced View)

IM Syslog sehe ich in sehr kurzer Zeit sehr viele Aufrufe auf wechselnde Ports

Dec 16 18:20:46 Tower sshd-session[383339]: Starting session: command for root from 192.168.1.162 port ##### id 0

Dec 16 18:20:46 Tower sshd-session[383339]: Close session: user root from 192.168.1.162 port ##### id 0

Ich verstehe dies nicht so ganz... Da scheinen in sehr kurzer Zeit viele Anfragen zu laufen die sofort wieder geschlossen werden.

Das sieht mir nicht "Normal" aus. Ich bin aber zu wenig in dem Thema drin.

@alturismo Könntest Du bitte mal einen Blick in das Syslog der diagnostics werfen. Irgend kann ich hier nicht helfen. Vielleicht siehst Du mehr, warum er den Zugriff über Web auf die GUI verliert?

2 hours ago, postboy99 said:

So sollte passen?

Ja, der Screenshot sieht mir so aus, als wenn der Mirror zum Flash (nun) aktiviert ist.

2 hours ago, postboy99 said:

Ich habe auf meiner einen von 2 HDDs ein paar SMART errors(aber schon seit einiger Zeit) aber das sollte doch nicht zum Systemabsturz führen, da Container auf der SSD laufen oder?!

Laut diagnostics ist die SSD im Pool btrfs.

diskFsType="btrfs"

diskId="Samsung_SSD_850_EVO_500GB..."

Überprüfe dort das Dateisystem mal vorsorglich auf Fehler.

Ich sehe Hinweise auf eine WD Elements Disk. Nutzt Du USB Datenträger im Array?

====

Und sollte sich Dein Problem mal lösen würde ich empfehlen danach etwas aufzuräumen:

• Anscheinend hast Du so ziemlich (fast) alles installiert, was das "Nerdtools" hergab. Brauchst Du das wirklich alles?

• Auch sind bei einigen Devices die ASPM-fähigkeiten disabled. Vielleicht läßt sich das energetisch sparsamer gestalten.

• Auf dem USB Stick ist wohl auch mal etwas schief gegangen. Es gibt eine Datei, die darauf hindeutet, daß es einen Checklauf gab: "FSCK0000.REC".

  Fertige (nur so zum Spaß und Sicherheit) mal ein lokales Backup des USB Stick an. Wenn DU das Backup extern lagerst hast Du eine bessere Chance auf Reparatur, wenn mal was gravierendes schief geht.

6 hours ago, DataCollector said:

Könntest Du bitte mal einen Blick in das Syslog der diagnostics werfen. Irgend kann ich hier nicht helfen. Vielleicht siehst Du mehr, warum er den Zugriff über Web auf die GUI verliert?

da ist jetzt weder ein Server Fehler noch ein nginx (webui) Fehler zu sehen

On 12/15/2025 at 4:36 PM, postboy99 said:

Unter logs, web ich dort zb im sylog mach warnings Suche finde ich lediglich:

wie der Fehler besagt, der Docker ist falsch konfiguriert, schau dir da die Netzwerk / Port Settings an.

wenn das webui nicht mehr erreichbar ist, geht dann noch ssh von deinen clients aus ?

ist ja aktiviert, einfach mal testen, nur um zu sehen ob der Server komplett nicht mehr erreichbar ist oder wirklich nur das webui.

8 hours ago, postboy99 said:

So sollte passen?

rsyslog, hast du jetzt "doppelt", einmal als Netzwerk log und zusätzlich auf dem Stick, schalte Netzwerk logging wieder aus da dies früher aussteigt, syslog to flash reicht aus zum debugging und ist meist aussagefähiger (Netzwerk steigt meist früher aus).

die xyz ssh Zugriffe, nutzt du extern ein script, eine HA Integration, usw um Daten von Server abzufragen ? wenn ja, deaktiviere das mal oder update dies, ich meine die neuere HA Version "hämmert" nicht mehr so auf den Server ein und nutzt die API dafür.

wenn das nochmals passiert, ssh Test, wenn ssh geht, im terminal diagnostics aufrufen, dann haben wir eine zum Stand mit Fehler und sehen ggf. die Ursache, wenn auch ssh nicht geht, anstelle "hard power cycle", mal nur Power Button gedrückt und gewartet ob der Server normal herunter fährt ?

Dann könnte ggf. noch der Realtek Treiber eine Option sein, seit dem Linux Kernel xyz haben manche System Probleme ohne den separaten Treiber und mal ohne powertop testen, wobei wir das dann normal im log sehen beim nächsten "crash".

Danke Euch soweit, diese ssh Zugriffe sind Abfragen von einer App (Monitoring - wird manuell ausgeführt).

Habe mir in der Zeit jetzt noch nen kleinen Monitor bestellt, sodass ich beim nächsten "Ausfall" diesen anschließen werden aber seit ich gestern alles mögliche an Docker ausgeschaltet habe scheint es seither stabil.

Ich habe die Vermutung, dass es ein "altes" PiHole Docker war, welches eh nicht mehr gestartet ist. Dort hatte ich noch autostart an.

Zusätzlich habe ich aber mal eine Disk Check gemacht und der sieht glaube garnicht gut aus:

Kann man gegen diese Read errors etwas machen oder was bedeutet das konkret für mich?

Eine HDD hat langsam auch SMART errors.

On 12/16/2025 at 8:05 PM, postboy99 said:

Klar - siehe Anhang.

Die diagnostics enthält nicht das letzte Log, sondern nur das aktuelle. Also nicht das wo der Server crashte, sondern wo er gerade fehlerfrei läuft. Daher ist keine Analyse möglich (wenn nicht zufällig andere Fehler drin wären, ich sehe aber soweit nichts).

Aktiviere die Speicherung der Logs auf dem USB Stick und installiere das Skript:

https://forums.unraid.net/topic/121039-syslog-notify-create-notifications-if-specific-words-occur-in-the-logs/

Wenn die Logs auf dem Stick geschrieben werden, liegen sie dort in /logs als syslog und syslog-previous. Ich meine sie kommen dann auch automatisch in der das Diagnostics ZIP mit rein. Bin ich aber gerade nicht sicher.

EDIT: Die ganzen Lesefehler sind böse. Ich hoffe du hast Backups oder es sind keine wichtigen Daten auf Disk 1. Die ist vermutlich hinüber.

Hallo Zusammen,

die letzten Tage war es ruhig und ausfallfrei. Doch heute trat das Problem erneut auf.

Ich habe dann den Monitor angeschlossen, doch das Bild blieb dunkel(nach Neustart gab es Bild).

Im syslog sehe ich etliche Meldungen:
Dec 28 13:55:19 Tower kernel: e1000e 0000:00:1f.6 eth0: Detected Hardware Unit Hang:
Dec 28 13:55:19 Tower kernel:  TDH                  <ce>
Dec 28 13:55:19 Tower kernel:  TDT                  <e1>
Dec 28 13:55:19 Tower kernel:  next_to_use          <e1>
Dec 28 13:55:19 Tower kernel:  next_to_clean        <cc>
Dec 28 13:55:19 Tower kernel: buffer_info[next_to_clean]:
Dec 28 13:55:19 Tower kernel:  time_stamp           <12d910c42>
Dec 28 13:55:19 Tower kernel:  next_to_watch        <ce>
Dec 28 13:55:19 Tower kernel:  jiffies              <12e6f5b00>
Dec 28 13:55:19 Tower kernel:  next_to_watch.status <0>
Dec 28 13:55:19 Tower kernel: MAC Status             <40080083>
Dec 28 13:55:19 Tower kernel: PHY Status             <796d>
Dec 28 13:55:19 Tower kernel: PHY 1000BASE-T Status  <3800>
Dec 28 13:55:19 Tower kernel: PHY Extended Status    <3000>
Dec 28 13:55:19 Tower kernel: PCI Status             <10>
Dec 28 13:55:21 Tower kernel: e1000e 0000:00:1f.6 eth0: Detected Hardware Unit Hang:
Dec 28 13:55:21 Tower kernel:  TDH                  <ce>
Dec 28 13:55:21 Tower kernel:  TDT                  <e1>
Dec 28 13:55:21 Tower kernel:  next_to_use          <e1>
Dec 28 13:55:21 Tower kernel:  next_to_clean        <cc>
Dec 28 13:55:21 Tower kernel: buffer_info[next_to_clean]:
Dec 28 13:55:21 Tower kernel:  time_stamp           <12d910c42>
Dec 28 13:55:21 Tower kernel:  next_to_watch        <ce>
Dec 28 13:55:21 Tower kernel:  jiffies              <12e6f62c0>
Dec 28 13:55:21 Tower kernel:  next_to_watch.status <0>
Dec 28 13:55:21 Tower kernel: MAC Status             <40080083>
Dec 28 13:55:21 Tower kernel: PHY Status             <796d>
Dec 28 13:55:21 Tower kernel: PHY 1000BASE-T Status  <3800>
Dec 28 13:55:21 Tower kernel: PHY Extended Status    <3000>
Dec 28 13:55:21 Tower kernel: PCI Status             <10>

Kompletter Syslog im Anhang.

Dazu muss ich sagen, dass ich extra Mainboard und CPU ausgetauscht/aufgestockt habe auf einen Intel i3 14100 mit einem GIGABYTE H610I DDR4 Mainboard.

Sprich, wenn ich die Meldung richtig verstehe und eth0 (Netzwerkport) nicht mehr läuft, dann kann es ja eigentlich nicht der gleiche Fehler sein, weil ich davor ein ganz anderes Board und somit auch Netzwerkkarte hatte.

Das verwirrt mich.

tower-syslog-previous-20251228-1741.zip

6 minutes ago, postboy99 said:

Kompletter Syslog im Anhang.

leider nicht die diagnostics, aber mal geraten, power saving features aktiv wie aspm, powertop, tweaks, ... ?

wenn ja, mal deaktivieren, sieht verdächtig nach Netzwerkausfall aus wie du auch vermutest.