seyz

Danke für deine Hilfe, Geduld und ausführlichen Antworten @DataCollector. Der ursprüngliche Plan war Unraid auf dem ersten Server zum Laufen zu bringen und dann den zweiten Server als Backup aufzusetzen. Da beides nicht wirklich passiert ist, muss ich mir jetzt erstmal eine neue Strategie überlegen. Ich habe keine sonderbaren Geräusche vernommen, aber mir ist aufgefallen, dass eine der betroffenen Festplatten von mir auf dem Kopf montiert wurde. Die werde ich noch mal umdrehen. Dann werde ich jede einzelne Platte erst mal sichern und dann schaue ich weiter. Vielleicht starte ich dann noch mal von vorn. Muss nur den Elan finden, da ich im Moment nicht so richtig Lust verspüre. Ich hab mich hinsichtlich Hardware noch mal schalu gemacht und liebäugel jetzt mit dem Intel Raid Expander RES2CV360. Ich hab gesehen, dass du den sogar hast. Hast du den auch mal mit Unraid probiert? Und noch eine Frage: Man kann viele der Expander mit zwei Kabel anschließen. Ist das sinnvoll nötig? Ich habe noch andere Hardware gefunden, die ich ebenfalls mal testen würde.

Kurz nach dem Neustart hat sich die GUI aufgehängt. Der Abbruch der Paritätsprüfung konnte ich ncoh erreichen, aber dann war nur noch der obere Teil der GUI zu sehen. Zugriff per SSH war noch drin, aber natürlich war ein Herunterfahren nicht möglich. Nach einem weiteren Neustart sieht das Ganze nun so aus. Der Witz: Trotz deaktivierter Paritätsfestplatte wird eine Prüfung (vermutlich nur auf Nr. 2) der Parität durchgeführt. Ich bin ratlos. So wie das jetzt aussieht, kann ich es nicht lassen. Aber selbst wenn ich mir einen neuen Controller hole, kann ich von vorne anfangen und dazu müsste das Ganze mal wenigstens eine Weile für ein vollständiges Backup funktionieren. Dass es im Anschluss läuft scheint mir aber mindestens fragwürdig. Für Ideen ohen Hardwaretausch, die ich direkt probieren kann, wäre ich dankbar. Edit: Scheint jetzt auch wirklich gar nchts mehr zu funktionieren. Beim Versuch die Paritätsprüfung zu unterbrechen hängt sich Unraid erneut auf. Dann geht wieder gar nichts. Ich kann ncihts machen, außer das System hart runterzufahren.

Wollte gerade herunterfahren und nun hat er sich wieder aufgehängt. Ich bin mir ziemlich sicher, dass das hochfahren nach dem Schlafen nciht gelingt und Unraid deshalb auch nicht herunterfährt. Docker war bereits manuell beendet. Nov 13 02:51:33 raider kernel: mpt2sas_cm0: log_info(0x31110101): originator(PL), code(0x11), sub_code(0x0101) Nov 13 02:51:33 raider kernel: program smartctl is using a deprecated SCSI ioctl, please convert it to SG_IO Nov 13 02:51:33 raider emhttpd: read SMART /dev/sda Nov 13 02:51:33 raider kernel: mpt2sas_cm0: log_info(0x31110101): originator(PL), code(0x11), sub_code(0x0101) Nov 13 02:51:33 raider kernel: mpt2sas_cm0: log_info(0x31110101): originator(PL), code(0x11), sub_code(0x0101) Nov 13 02:51:33 raider kernel: mpt2sas_cm0: log_info(0x31110101): originator(PL), code(0x11), sub_code(0x0101) Nov 13 02:51:33 raider kernel: mpt2sas_cm0: log_info(0x31110101): originator(PL), code(0x11), sub_code(0x0101) Nov 13 02:51:33 raider kernel: mpt2sas_cm0: log_info(0x31110101): originator(PL), code(0x11), sub_code(0x0101) Nov 13 02:51:33 raider kernel: mpt2sas_cm0: log_info(0x31110101): originator(PL), code(0x11), sub_code(0x0101) Nov 13 02:51:33 raider kernel: program smartctl is using a deprecated SCSI ioctl, please convert it to SG_IO Nov 13 02:51:33 raider kernel: mpt2sas_cm0: log_info(0x31110101): originator(PL), code(0x11), sub_code(0x0101) Nov 13 02:51:33 raider kernel: sd 9:0:0:0: device_block, handle(0x0012) Nov 13 02:51:35 raider kernel: mpt2sas_cm0: discovery errors(sata initialization failed): sas_address(0x5001438020e5bac0), handle(0x0012) Nov 13 02:56:13 raider root: Status of all loop devices Nov 13 02:56:13 raider root: /dev/loop1: [2049]:12 (/boot/bzfirmware) Nov 13 02:56:13 raider root: /dev/loop0: [2049]:10 (/boot/bzmodules) Nov 13 02:56:13 raider root: Active pids left on /mnt/* Heißt leider auch, dass ich wieder von vorne beginnen kann. Gibt es denn eine Möglichkeit den Prozess des Herunterfahrens zu unterbrechen/stoppen, so dass man wieder "normal" weiter machen kann? Auf shutdown -c folgt immer shutdown: not running. Liegt aber vielleicht auch daran, dass ich den shutdown über die GUI gestartet habe.

Fehler sind wieder da: Werde bei der nächsten Gelegenheit mal den Controller wechseln.

Genau das muss ich mir dann noch mal in Ruhe überlegen. Darin liegt klar eine Chance und das wird auf sowas vermutlich auch hinaus laufen, nur bisher bin ich den Schritt nicht gegangen, weil ich dann halt alle Kabel und alle Controller die hier rumliegen in die Tonne klopfen kann (oder ebay KA). Wäre halt alles von vorne. Nicht zu vergessen: Unraid wäre vermutlich auch von vorne. Und ich bin mir noch nicht sicher, ob das wirklich das OS meiner Wahl ist. Wir sind noch nicht wirklich warm gelaufen. Auch wenn ich weiterhin der Meinung bin, dass es ziemlich exakt das kann, was ich brauche.

Also das Problem mit der Parität konnte ich lösen. Ich hab noch mal einen Neustart gemacht. Danach konnte ich die HDD, die davor schon Par1 war wieder auswählen. Nun kam aber keine Anzeige mehr mit"falsch" und "alle Daten werden gelöscht...". Array konnte jtzt ganz normal gestartet werden. Bisher auch keine Fehler mehr.

Ich habs mir schon gedacht, aber jetzt weiß ich es sicher. Danke. Wie gesagt, hat sich der Controller nciht geändert. Lediglich ein anderes Kabel in einem anderen SFF-8087 Port. Sie taucht auf. Also die Festplatte (mit korrekter und gleicher Seriennummer) wird gelistet und kann auch als Par1 ausgewählt werden. Stromspartechnik sind die WDs gemint oder? Ich hatte beim Betrieb mit einem RAID-Controller/Expander damit noch nie Probleme und hab auch nie irgendwas abkleben müssen.

So was in der Art hatte ich schon gemacht, aber leider nciht so wrklch weiter gekommen. Es gibt ja in der Übersicht schon einen Hinweis auf Festplatten mit SMART-Fehlern. Von 24 HDDs haben 13 SMART-Fehler (soweit ich das gesehen habe immer UDMA_CRC). Ich hatte mir auch schon neue Kabel bestellt, weil das immer die UDMA_CRC-Fehler sind und die auf ein Kabelproblem -laut Forum - hindeuten, aber auch mit einem Delock Kabel (wie von @DataCollector vorgeschlagen) waren die Probleme da. Deshalb wollte ich mich, sobald etwas mehr Zeit, nochmal eine Lösung ohne 3 RAID-Karten überlegen. Da ich aber nicht 5000 € ausgeben möchte (und kann) und trotzdem mehr als 20 HDDs dranhängen werde, ist das etwas verzwickt.

So also herunterfahren hat geklappt. Ich hab ein anderes Kabel an einem anderen Slot am gleichen Controller verwendet. Nach dem Start habe ich nun eine neue Lage: Das Array startet nciht automatisch. Die Festplatte 1 von Parität ist nicht zugewiesen Nov 12 14:40:32 raider kernel: mdcmd (1): import 0 Nov 12 14:40:32 raider kernel: md: import_slot: 0 missing Disk1 hat er an der richtigen Stelle wieder platziert. Allerdings hat sie einen anderen Namen. Ist aber laut Seriennummer die gleiche Platte. Wenn ich jetzt die Platte der Parität wieder einhänge, startet der ganze Paritätsprüfungsprozess von vorne (2,5 d warten). Ist das sinnvoll? Wieso schmeisst er denn die jetzt überhaupt raus? Unraid listet die Platte korrekt auf. Sie wird erkannt, aber warum nicht als Parität geladen? vor Neustart: nach Neustart:

Danke @hawihoney. Steht schon mal nicht 0 199 UDMA_CRC_Error_Count -OSRCK 200 188 000 - 12679 @DataCollector vielleicht ein guter Ansatz. Ich werde mal nicht nur das Kabel wechseln sondern auch den Controller. Viele Grüße

Ok. Danke für deine Rückmeldung und Hilfe. Die sdy ist eine der beiden Platten für die Parität. Liegt bestimmt an einem der billigen SFF-8087 auf Sata. Ich weiß immer nich woher ich verlässliche Kabel bekommen kann ohne gleich so viel zu zahlen wie für ne HDD. Ist das auch das Problem der HDD sdt?

raider-diagnostics-20231111-1505.zipIch hoffe es hilft. Mit dem Tauschen der Kabel würde ich noch warten, da ich um einen Neustart nicht drum rumkomme und dann (etwas das ich wirklich nicht verstehe) alle Logs weg sind. Es gibt keine USB-Platten.

Vielleicht nochmal für alle der aktuelle Stand: wie oben schon gesagt, ist bei der Prüfung aber nur 1 Fehler gefunden worden.

Hallo @alturismo, danke für dein Input. Ich habs gleich mal angepasst. Hallo @MAM59 Die Paritätsprüfung ist nun abgeschlossen. Deshalb auch meine verspätete Antwort. Es wurde 1 Fehler gefunden. Hinter der betroffenen Festplatte steht nun aber eine noch höhere Zahl an Fehlern: 4096 Den Docker manuell zu stoppen, habe ich bereits versucht. Das hat nichts geändert. Der SATA-Controller ist eine LSI 9201-16e in Kombination mit einer Intel® RAID Expander Card RES2SV240 (auf die bin ich erst durch dieses Forum gekommen) und einer EXPANDER-KARTE HP 487738-001 (ähnlich, glaube nicht, dass ich da HP verbaut habe). Hat in dieser Konfig unter Windows einwandfrei funktioniert. Hallo @DataCollector, mit den Chesummen wüsste ich in jedem Fall schon mal mehr als jetzt. Deshlab meiner Mienng nach ein hilfreicher Ansatz. Danke! Du scheinst dich ja intensiv damit beschäftigt zu haben. Ich denke, ich werde trotz deiner Einwände erstmal das Plugin nutzen müssen, da mir schlicht das Wissen fehlt um sinnvolle Ergebnisse ohne Plugin zu schaffen. Aber danke, dass du das gleich offen gelegt hast. Hallo @hawihoney, genau das hatte ich wirklich oft hinsichtlich Unraid gelesen. Das war der Grund zu wechseln. Blöd, dass ich jetzt genau gegenteilige Erfahrung machen muss 🤣. Wie gesagt hat der Paritätscheck noch mehr Fehler auf der Festplatte gefunden. Kann es sein, dass mit dem Kabel evtl. was nicht passt und es deshlab zu Lese-/Schreibfehlern kommt? Gruß Felix

Ich habe keine Ahnung warum sich die Kiste nciht herunterfahren lässt. Ich werde aber das Gefühl nciht los, dass es was mit dem StandBy der Platten zu tun hat. Aber auch hier muss ich mich erst mal in den Aufbau der Logs, Speicherort usw. einarbeiten um zu verstehen, wo ich überhaupt hilfreiche Informationen zum Problem bekomme. Danke für den Hinweis auf den Abschnitt des Manuels. Werde ich mir, wie auch Uneven Parity Calc, mal anschauen.

Ich weiß nicht wodurch diese Fehler entstanden sind. Vielleicht durch das erzwungene Herunterfahren, aber eigentlich waren Schreibvorgänge abgeschlossen. Ich weiß auch nicht, wie ich bestimmen kann was fehlerhaft ist oder ob ich das überhaupt irgendwie kann. Ist das möglich? Wenn ich dich aber richtig verstanden habe, habe ich eigentlich (da ich mehr als eine Datenplatte habe) gar keine große Wahl. Parity korrigieren. Da ich noch kein vollständiges Backup habe, muss ich wohl damit leben.

Mhm spannend und schade. Danke für die Information. Eigentlich ist ja aber "gegen Ausfall" auch nicht ganz korrekt. Im Endeffekt hilft die Parität dann wirklich nur, wenn ein Festplatte (oder zwei) richtig sterben. Und auch dann hilft mir die Parität nur, wenn ich mir sicher bin, dass meine Parität sich nicht schon automatisch "falsche" Informationen besorgt hat oder? Hast du mir evtl. noch eine Info oder einen Link, wo ich mich zu Checksummen belesen kann? Oder ein Plugin? Bin für jeden Rat dankbar. Viele Grüße

Hallo liebe Community, mein Unraid ist hpts. Datenserver. VMs hab ich keine und in Docker einen Container. Da ich den Server nicht immer brauche, fahre ich Unraid auch mal herunter. Hierbei gibt es immer wieder Probleme und das Herunterfahren muss von mir erzwungen werden. Dadurch habe ich nun eine Meldung über 1024 Fehler an einer meiner Festplatten in der Arry-Übersicht. Nach einem solchen erzwungenen Neustart, startet die Paritätprüfung automatisch. Diese habe ich abgebrochen. Dafür einen erweiterten Smartselbsttest durchgeführt, der fehlerfrei abgeschlossen werden konnte. Meine Frage ist nun: wie bekomme ich diese Fehlermeldung wieder weg? Durch eine Paritätsprüfung? Oder ist das genau der falsche Weg, weil ich so die Fehler auf die Parität schreibe? Viele Grüße Felix

Abend, ich bin nun den Weg geagangen und hab meine zwei SSDs, die zusammengefasst und als btrfs formaitert waren wieder zu zwei einzelnen in xfs formatiert. Etwas hakelige Geschichte, da man erst mal Beide aus dem Cache Pool entfernen muss, um UNRAID klar zumachen, dass sie nicht mehr zusammen gehören. Denn nur dann lässt sich xfs als Format wählen. Nun appdata, system und das darunter liegende Docker-Verzeichnis eingerichtet und alles funtkioniert wieder. Ich muss mir nur noch überlegen, wie ich die eine Platte auf die andere regemäßig geischert bekomme. Oder ob ich das ganze ins Array sichere. Danke @alturismo für den Anstoß.

Denke dein letzter Punkt ist wichtig und blieb bisher von mir unbeachtet. Ich bin ja nur in dieses Problem gekommen, weil ich nicht einfach mal geschaut habe was die Container machen. Ein blick auf die Platte in der Übersicht und mir hätte auffallen können, dass es nicht rund läuft und Container nicht korrekt konfiguriert sind.... wieder was gelernt. Muss mal schauen, wie ich das mit dem Cache gelöst bekomme. Danke dir.

Danke @alturismofür die Antwort. Ich habe beides versucht. Bei der harten Variante bekomme ich gesagt, dass ich nur read-Rechte habe und bei der bevorzugten über das Menü und den Punkt vDisk-Datei löschen, wird - wie oben dargestellt - der Befehl zwar gestartet, aber es passiert nichts. Ich würde jetzt erst mal warten bis die Paritätsprüfung durch ist (Docker-FIle liegt NCIHT auf dem Array). Und dann werde ich einen zweiten Anlauf mit googlen starten. Ich hatte die BTRFS Methode von SpaceInvaders. Wie genau machst du das? Über Verzeichnis? Falls ich alles gelöscht und neu aufgesetzt bekomme, kann ich es ja dann gleich mal anders probieren.

Da ich eigentlich nur einen relevanten Docker am Laufen hatte, die Konfigdaten nicht verloren gehen sollten und im anderen Thread steht, dass das schnelle Füllen der Festplatte ziemlich sicher auf einen Konfigfehler eines Dockers zurückzuführen ist, habe ich versucht die docker.img zu löschen. Aber auch über "vDisk-Datei löschen" konnte ich nichts erreichen. Die liegt an zwei Orten, aber an beiden tut sich nichts. Beim Ausführen des delete-Befehls erscheint nur folgende Zeile in den Logs: Oct 14 18:17:56 raider ool www[11948]: /usr/local/emhttp/plugins/dynamix.docker.manager/scripts/docker_rm

Ich hatte dem Dockerimage 500 GB am Anfang gegeben, da ich - auch aufgrund bisheriger Dockererfahrungen - davon ausgegangen bin, dass das ewig reichen würde. Nachdem ich aber gesehen habe, dass die Disk 1 TB belgeten Speicherplatz hat, hat mich das etwas stutzig gemacht. Ich hab nun versucht Docker 900 GB zu Verfügung zu stellen, was zu den unten aufgeführten Meldungen führt. Der vDisk-PFad lautet: /mnt/user/system/docker/docker/docker/docker.img. Dort liegen auch schon Dateien. Mir ist nun etwas unklar, warum Docker dort keine Schreibrechte mehr hat. Vielleicht kann mir jemand das erklären? Ich muss dazu sagen, dass die Rechteverwaltung in Linux etwas ist, das ich ncoh nie wirklich verstanden habe. Achso die DOcker.img ist > 500 GB. Wie kann man heraus bekommen, wie es dazu kommen kan bzw. was sie groß macht. Außerdem ist mir natürlich ein Fehler unterlaufen und der Pfad oben wurd von mir zwischenzeitlich auf /mnt/user/system/docker/docker/docker.img geändert, weshlab jetz zwei docker.img in der Größe vorliegen. Löschen kann ich eine der beiden img natürlich nicht, da read only. Oct 14 17:28:32 raider winbindd[2490]: Copyright Andrew Tridgell and the Samba Team 1992-2022 Oct 14 17:28:32 raider winbindd[2492]: [2023/10/14 17:28:32.790227, 0] ../../source3/winbindd/winbindd_cache.c:3117(initialize_winbindd_cache) Oct 14 17:28:32 raider winbindd[2492]: initialize_winbindd_cache: clearing cache and re-creating with version number 2 Oct 14 17:28:32 raider emhttpd: shcmd (544): /etc/rc.d/rc.avahidaemon restart Oct 14 17:28:32 raider root: Stopping Avahi mDNS/DNS-SD Daemon: stopped Oct 14 17:28:32 raider avahi-daemon[21408]: Got SIGTERM, quitting. Oct 14 17:28:32 raider avahi-dnsconfd[21419]: read(): EOF Oct 14 17:28:32 raider avahi-daemon[21408]: Leaving mDNS multicast group on interface br0.IPv4 with address 192.168.108.81. Oct 14 17:28:32 raider avahi-daemon[21408]: avahi-daemon 0.8 exiting. Oct 14 17:28:32 raider root: Starting Avahi mDNS/DNS-SD Daemon: /usr/sbin/avahi-daemon -D Oct 14 17:28:32 raider avahi-daemon[2544]: Found user 'avahi' (UID 61) and group 'avahi' (GID 214). Oct 14 17:28:32 raider avahi-daemon[2544]: Successfully dropped root privileges. Oct 14 17:28:32 raider avahi-daemon[2544]: avahi-daemon 0.8 starting up. Oct 14 17:28:32 raider avahi-daemon[2544]: Successfully called chroot(). Oct 14 17:28:32 raider avahi-daemon[2544]: Successfully dropped remaining capabilities. Oct 14 17:28:32 raider avahi-daemon[2544]: Loading service file /services/sftp-ssh.service. Oct 14 17:28:32 raider avahi-daemon[2544]: Loading service file /services/smb.service. Oct 14 17:28:32 raider avahi-daemon[2544]: Loading service file /services/ssh.service. Oct 14 17:28:32 raider avahi-daemon[2544]: Joining mDNS multicast group on interface br0.IPv4 with address 192.168.108.81. Oct 14 17:28:32 raider avahi-daemon[2544]: New relevant interface br0.IPv4 for mDNS. Oct 14 17:28:32 raider avahi-daemon[2544]: Network interface enumeration completed. Oct 14 17:28:32 raider avahi-daemon[2544]: Registering new address record for 192.168.108.81 on br0.IPv4. Oct 14 17:28:32 raider emhttpd: shcmd (545): /etc/rc.d/rc.avahidnsconfd restart Oct 14 17:28:32 raider root: Stopping Avahi mDNS/DNS-SD DNS Server Configuration Daemon: stopped Oct 14 17:28:32 raider root: Starting Avahi mDNS/DNS-SD DNS Server Configuration Daemon: /usr/sbin/avahi-dnsconfd -D Oct 14 17:28:32 raider avahi-dnsconfd[2555]: Successfully connected to Avahi daemon. Oct 14 17:28:33 raider avahi-daemon[2544]: Server startup complete. Host name is raider.local. Local service cookie is 3024083632. Oct 14 17:28:34 raider avahi-daemon[2544]: Service "raider" (/services/ssh.service) successfully established. Oct 14 17:28:34 raider avahi-daemon[2544]: Service "raider" (/services/smb.service) successfully established. Oct 14 17:28:34 raider avahi-daemon[2544]: Service "raider" (/services/sftp-ssh.service) successfully established. Oct 14 17:28:44 raider ool www[2308]: /usr/local/emhttp/plugins/dynamix/scripts/emcmd 'cmdStatus=Apply' Oct 14 17:28:44 raider emhttpd: Starting services... Oct 14 17:28:44 raider emhttpd: shcmd (552): /etc/rc.d/rc.samba restart Oct 14 17:28:44 raider wsdd2[2489]: 'Terminated' signal received. Oct 14 17:28:44 raider winbindd[2492]: [2023/10/14 17:28:44.830746, 0] ../../source3/winbindd/winbindd_dual.c:1950(winbindd_sig_term_handler) Oct 14 17:28:44 raider winbindd[2492]: Got sig[15] terminate (is_parent=1) Oct 14 17:28:44 raider wsdd2[2489]: terminating. Oct 14 17:28:44 raider winbindd[2494]: [2023/10/14 17:28:44.830749, 0] ../../source3/winbindd/winbindd_dual.c:1950(winbindd_sig_term_handler) Oct 14 17:28:44 raider winbindd[2494]: Got sig[15] terminate (is_parent=0) Oct 14 17:28:46 raider root: Starting Samba: /usr/sbin/smbd -D Oct 14 17:28:47 raider smbd[3510]: [2023/10/14 17:28:47.014633, 0] ../../source3/smbd/server.c:1741(main) Oct 14 17:28:47 raider smbd[3510]: smbd version 4.17.10 started. Oct 14 17:28:47 raider smbd[3510]: Copyright Andrew Tridgell and the Samba Team 1992-2022 Oct 14 17:28:47 raider root: /usr/sbin/wsdd2 -d -4 Oct 14 17:28:47 raider root: /usr/sbin/winbindd -D Oct 14 17:28:47 raider wsdd2[3524]: starting. Oct 14 17:28:47 raider winbindd[3525]: [2023/10/14 17:28:47.067591, 0] ../../source3/winbindd/winbindd.c:1440(main) Oct 14 17:28:47 raider winbindd[3525]: winbindd version 4.17.10 started. Oct 14 17:28:47 raider winbindd[3525]: Copyright Andrew Tridgell and the Samba Team 1992-2022 Oct 14 17:28:47 raider winbindd[3530]: [2023/10/14 17:28:47.069880, 0] ../../source3/winbindd/winbindd_cache.c:3117(initialize_winbindd_cache) Oct 14 17:28:47 raider winbindd[3530]: initialize_winbindd_cache: clearing cache and re-creating with version number 2 Oct 14 17:28:47 raider emhttpd: shcmd (556): /etc/rc.d/rc.avahidaemon restart Oct 14 17:28:47 raider root: Stopping Avahi mDNS/DNS-SD Daemon: stopped Oct 14 17:28:47 raider avahi-daemon[2544]: Got SIGTERM, quitting. Oct 14 17:28:47 raider avahi-dnsconfd[2555]: read(): EOF Oct 14 17:28:47 raider avahi-daemon[2544]: Leaving mDNS multicast group on interface br0.IPv4 with address 192.168.108.81. Oct 14 17:28:47 raider avahi-daemon[2544]: avahi-daemon 0.8 exiting. Oct 14 17:28:47 raider root: Starting Avahi mDNS/DNS-SD Daemon: /usr/sbin/avahi-daemon -D Oct 14 17:28:47 raider avahi-daemon[3569]: Found user 'avahi' (UID 61) and group 'avahi' (GID 214). Oct 14 17:28:47 raider avahi-daemon[3569]: Successfully dropped root privileges. Oct 14 17:28:47 raider avahi-daemon[3569]: avahi-daemon 0.8 starting up. Oct 14 17:28:47 raider avahi-daemon[3569]: Successfully called chroot(). Oct 14 17:28:47 raider avahi-daemon[3569]: Successfully dropped remaining capabilities. Oct 14 17:28:47 raider avahi-daemon[3569]: Loading service file /services/sftp-ssh.service. Oct 14 17:28:47 raider avahi-daemon[3569]: Loading service file /services/smb.service. Oct 14 17:28:47 raider avahi-daemon[3569]: Loading service file /services/ssh.service. Oct 14 17:28:47 raider avahi-daemon[3569]: Joining mDNS multicast group on interface br0.IPv4 with address 192.168.108.81. Oct 14 17:28:47 raider avahi-daemon[3569]: New relevant interface br0.IPv4 for mDNS. Oct 14 17:28:47 raider avahi-daemon[3569]: Network interface enumeration completed. Oct 14 17:28:47 raider avahi-daemon[3569]: Registering new address record for 192.168.108.81 on br0.IPv4. Oct 14 17:28:47 raider emhttpd: shcmd (557): /etc/rc.d/rc.avahidnsconfd restart Oct 14 17:28:47 raider root: Stopping Avahi mDNS/DNS-SD DNS Server Configuration Daemon: stopped Oct 14 17:28:47 raider root: Starting Avahi mDNS/DNS-SD DNS Server Configuration Daemon: /usr/sbin/avahi-dnsconfd -D Oct 14 17:28:47 raider avahi-dnsconfd[3578]: Successfully connected to Avahi daemon. Oct 14 17:28:47 raider emhttpd: shcmd (569): /usr/local/sbin/mount_image '/mnt/user/system/docker/docker/docker/docker.img' /var/lib/docker 900 Oct 14 17:28:47 raider root: truncate: cannot open '/mnt/cache_ssd/system/docker/docker/docker/docker.img' for writing: Read-only file system Oct 14 17:28:47 raider kernel: loop2: detected capacity change from 0 to 1048576000 Oct 14 17:28:47 raider kernel: BTRFS: device fsid 66fe6747-4913-4504-9b97-e44602022607 devid 1 transid 31 /dev/loop2 scanned by mount (3632) Oct 14 17:28:47 raider kernel: BTRFS info (device loop2): using crc32c (crc32c-intel) checksum algorithm Oct 14 17:28:47 raider kernel: BTRFS info (device loop2): using free space tree Oct 14 17:28:47 raider kernel: BTRFS info (device loop2): enabling ssd optimizations Oct 14 17:28:47 raider root: ERROR: unable to resize '/var/lib/docker': Read-only file system Oct 14 17:28:47 raider root: Resize device id 1 (/dev/loop2) from 500.00GiB to max Oct 14 17:28:47 raider emhttpd: shcmd (571): /etc/rc.d/rc.docker start Oct 14 17:28:48 raider avahi-daemon[3569]: Server startup complete. Host name is raider.local. Local service cookie is 1863239704. Oct 14 17:28:48 raider root: starting dockerd ... Oct 14 17:28:49 raider avahi-daemon[3569]: Service "raider" (/services/ssh.service) successfully established. Oct 14 17:28:49 raider avahi-daemon[3569]: Service "raider" (/services/smb.service) successfully established. Oct 14 17:28:49 raider avahi-daemon[3569]: Service "raider" (/services/sftp-ssh.service) successfully established. Oct 14 17:29:18 raider emhttpd: shcmd (574): umount /var/lib/docker

Hallo in die Runde, Das Array ist nun eine Festplatte kleiner und läuft auch. Nach dem ich nun den Server zwei Mal neugestartet habe, konnte ich Docker nicht mehr starten. Da ich mit den Logs nichts anfangen konnte, habe ich den Docker v Disk Pfad geändert. Damit konnte ich Docker wieder starten. Das System kennt auch noch die ehemals installierten Container, wenn ich aber einen dieser Container starte sind keinerlei Einstellungen mehr vorhanden, was ich von Docker überhaupt nicht kenne. Den appdate PFad hab ich nicht verändert. In den Logs finde ich auch weiterhin sehr besorgniserregende Meldungen (siehe unten) Ich hab keine Ahnung was ich falsch gemcht habe und - viel wichtiger - wie ich das wieder reparieren kann. Jemand eine Idee? Edit: Der zu erst gepostet Eingangstext hat offensichtlich ncihts mit dem Problem zu tun und wurde deshalb von mir gelöscht. Viele Grüße Oct 14 12:53:27 raider avahi-daemon[5835]: avahi-daemon 0.8 exiting. Oct 14 12:53:27 raider root: Starting Avahi mDNS/DNS-SD Daemon: /usr/sbin/avahi-daemon -D Oct 14 12:53:27 raider avahi-daemon[6967]: Found user 'avahi' (UID 61) and group 'avahi' (GID 214). Oct 14 12:53:27 raider avahi-daemon[6967]: Successfully dropped root privileges. Oct 14 12:53:27 raider avahi-daemon[6967]: avahi-daemon 0.8 starting up. Oct 14 12:53:27 raider avahi-daemon[6967]: Successfully called chroot(). Oct 14 12:53:27 raider avahi-daemon[6967]: Successfully dropped remaining capabilities. Oct 14 12:53:27 raider avahi-daemon[6967]: Loading service file /services/sftp-ssh.service. Oct 14 12:53:27 raider avahi-daemon[6967]: Loading service file /services/smb.service. Oct 14 12:53:27 raider avahi-daemon[6967]: Loading service file /services/ssh.service. Oct 14 12:53:27 raider avahi-daemon[6967]: Joining mDNS multicast group on interface br0.IPv4 with address 192.168.108.81. Oct 14 12:53:27 raider avahi-daemon[6967]: New relevant interface br0.IPv4 for mDNS. Oct 14 12:53:27 raider avahi-daemon[6967]: Network interface enumeration completed. Oct 14 12:53:27 raider avahi-daemon[6967]: Registering new address record for 192.168.108.81 on br0.IPv4. Oct 14 12:53:27 raider emhttpd: shcmd (263): /etc/rc.d/rc.avahidnsconfd restart Oct 14 12:53:27 raider root: Stopping Avahi mDNS/DNS-SD DNS Server Configuration Daemon: stopped Oct 14 12:53:27 raider root: Starting Avahi mDNS/DNS-SD DNS Server Configuration Daemon: /usr/sbin/avahi-dnsconfd -D Oct 14 12:53:27 raider avahi-dnsconfd[6976]: Successfully connected to Avahi daemon. Oct 14 12:53:27 raider emhttpd: shcmd (275): /usr/local/sbin/mount_image '/mnt/user/system/docker/docker/docker/docker.img' /var/lib/docker 500 Oct 14 12:53:27 raider root: Creating new image file: '/mnt/user/system/docker/docker/docker/docker.img' size: 500G Oct 14 12:53:28 raider root: btrfs-progs v6.3.3 Oct 14 12:53:28 raider root: See https://btrfs.readthedocs.io for more information. Oct 14 12:53:28 raider root: Oct 14 12:53:28 raider root: NOTE: several default settings have changed in version 5.15, please make sure Oct 14 12:53:28 raider root: this does not affect your deployments: Oct 14 12:53:28 raider root: - DUP for metadata (-m dup) Oct 14 12:53:28 raider root: - enabled no-holes (-O no-holes) Oct 14 12:53:28 raider root: - enabled free-space-tree (-R free-space-tree) Oct 14 12:53:28 raider root: Oct 14 12:53:28 raider root: Label: (null) Oct 14 12:53:28 raider root: UUID: 66fe6747-4913-4504-9b97-e44602022607 Oct 14 12:53:28 raider root: Node size: 16384 Oct 14 12:53:28 raider root: Sector size: 4096 Oct 14 12:53:28 raider root: Filesystem size: 500.00GiB Oct 14 12:53:28 raider root: Block group profiles: Oct 14 12:53:28 raider root: Data: single 8.00MiB Oct 14 12:53:28 raider root: Metadata: DUP 1.00GiB Oct 14 12:53:28 raider root: System: DUP 8.00MiB Oct 14 12:53:28 raider root: SSD detected: no Oct 14 12:53:28 raider root: Zoned device: no Oct 14 12:53:28 raider root: Incompat features: extref, skinny-metadata, no-holes, free-space-tree Oct 14 12:53:28 raider root: Runtime features: free-space-tree Oct 14 12:53:28 raider root: Checksum: crc32c Oct 14 12:53:28 raider root: Number of devices: 1 Oct 14 12:53:28 raider root: Devices: Oct 14 12:53:28 raider root: ID SIZE PATH Oct 14 12:53:28 raider root: 1 500.00GiB /mnt/cache_ssd/system/docker/docker/docker/docker.img Oct 14 12:53:28 raider root: Oct 14 12:53:28 raider kernel: loop3: detected capacity change from 0 to 1048576000 Oct 14 12:53:28 raider kernel: BTRFS: device fsid 66fe6747-4913-4504-9b97-e44602022607 devid 1 transid 6 /dev/loop3 scanned by mount (7177) Oct 14 12:53:28 raider kernel: BTRFS info (device loop3): using crc32c (crc32c-intel) checksum algorithm Oct 14 12:53:28 raider kernel: BTRFS info (device loop3): using free space tree Oct 14 12:53:28 raider kernel: BTRFS info (device loop3): enabling ssd optimizations Oct 14 12:53:28 raider kernel: BTRFS info (device loop3): checking UUID tree Oct 14 12:53:28 raider emhttpd: shcmd (277): /etc/rc.d/rc.docker start Oct 14 12:53:28 raider avahi-daemon[6967]: Server startup complete. Host name is raider.local. Local service cookie is 2000595344. Oct 14 12:53:28 raider root: starting dockerd ... Oct 14 12:53:28 raider avahi-daemon[6967]: Service "raider" (/services/ssh.service) successfully established. Oct 14 12:53:28 raider avahi-daemon[6967]: Service "raider" (/services/smb.service) successfully established. Oct 14 12:53:28 raider avahi-daemon[6967]: Service "raider" (/services/sftp-ssh.service) successfully established. Oct 14 12:53:29 raider rc.docker: created network ipvlan br0 with subnets: 192.168.108.0/24; Oct 14 12:56:00 raider root: Fix Common Problems Version 2023.10.08a Oct 14 12:56:08 raider root: Fix Common Problems: Warning: Syslog mirrored to flash Oct 14 12:56:23 raider kernel: docker0: port 1(veth98d2169) entered blocking state Oct 14 12:56:23 raider kernel: docker0: port 1(veth98d2169) entered disabled state Oct 14 12:56:23 raider kernel: device veth98d2169 entered promiscuous mode Oct 14 12:56:23 raider kernel: docker0: port 1(veth98d2169) entered blocking state Oct 14 12:56:23 raider kernel: docker0: port 1(veth98d2169) entered forwarding state Oct 14 12:56:23 raider kernel: docker0: port 1(veth98d2169) entered disabled state Oct 14 12:56:23 raider kernel: eth0: renamed from veth0a56152 Oct 14 12:56:23 raider kernel: IPv6: ADDRCONF(NETDEV_CHANGE): veth98d2169: link becomes ready Oct 14 12:56:23 raider kernel: docker0: port 1(veth98d2169) entered blocking state Oct 14 12:56:23 raider kernel: docker0: port 1(veth98d2169) entered forwarding state Oct 14 12:56:56 raider kernel: verify_parent_transid: 31 callbacks suppressed Oct 14 12:56:56 raider kernel: BTRFS error (device sdb1): parent transid verify failed on logical 1718665216 mirror 1 wanted 41735 found 41656 Oct 14 12:56:56 raider kernel: repair_io_failure: 154 callbacks suppressed Oct 14 12:56:56 raider kernel: BTRFS info (device sdb1): read error corrected: ino 0 off 1718665216 (dev /dev/sdc1 sector 1202272) Oct 14 12:56:56 raider kernel: BTRFS info (device sdb1): read error corrected: ino 0 off 1718669312 (dev /dev/sdc1 sector 1202280) Oct 14 12:56:56 raider kernel: BTRFS info (device sdb1): read error corrected: ino 0 off 1718673408 (dev /dev/sdc1 sector 1202288) Oct 14 12:56:56 raider kernel: BTRFS info (device sdb1): read error corrected: ino 0 off 1718677504 (dev /dev/sdc1 sector 1202296) Oct 14 13:01:58 raider kernel: BTRFS error (device sdb1): parent transid verify failed on logical 1887289344 mirror 1 wanted 41741 found 41664 Oct 14 13:01:58 raider kernel: BTRFS info (device sdb1): read error corrected: ino 0 off 1887289344 (dev /dev/sdc1 sector 1531616) Oct 14 13:01:58 raider kernel: BTRFS info (device sdb1): read error corrected: ino 0 off 1887293440 (dev /dev/sdc1 sector 1531624) Oct 14 13:01:58 raider kernel: BTRFS info (device sdb1): read error corrected: ino 0 off 1887297536 (dev /dev/sdc1 sector 1531632) Oct 14 13:01:58 raider kernel: BTRFS info (device sdb1): read error corrected: ino 0 off 1887301632 (dev /dev/sdc1 sector 1531640) Oct 14 13:01:58 raider kernel: BTRFS error (device sdb1): parent transid verify failed on logical 1606516736 mirror 1 wanted 41735 found 41655 Oct 14 13:01:58 raider kernel: BTRFS info (device sdb1): read error corrected: ino 0 off 1606516736 (dev /dev/sdc1 sector 983232) Oct 14 13:01:58 raider kernel: BTRFS info (device sdb1): read error corrected: ino 0 off 1606520832 (dev /dev/sdc1 sector 983240) Oct 14 13:01:58 raider kernel: BTRFS info (device sdb1): read error corrected: ino 0 off 1606524928 (dev /dev/sdc1 sector 983248) Oct 14 13:01:58 raider kernel: BTRFS info (device sdb1): read error corrected: ino 0 off 1606529024 (dev /dev/sdc1 sector 983256) raider-diagnostics-20231014-1335.zip