G0ldenB0Y

Also es war definitiv ein Strom-Problem. 3 HDDs die immer wieder ausstiegen, einzige Gemeinsamkeit: Sie hingen alle an einem Strom-Strang. Als ich zwei Stränge getauscht hatte, waren es andere HDDs die nicht gingen. HDDs bzw. die Last umverteilt und siehe da, es geht wieder ohne Ausstieg. Eventuell liegt es daran, dass ich im BIOS was geändert habe nach dem Umzug, weil Unraid nicht startet, obwohl ich nur den Stick vergaß wieder anzustecken. Schön Blöd. Auch habe ich den Green-Modus in Unraid mittlerweile aktiviert. Bei allen Platten (ca. 4 weitere) sicherheitshalber anschließend xfs_repair wenn nötig noch durchgeführt. Läuft erstmal wieder. <Bereits 11% der Parität wieder hergestellt> Jedoch beginnt er mit 74 MB/s zu anfang und geht irgendwann nach einigen Stunden runter auf 4 MB/s. Das scheint mir nicht normal zu sein. Ich kann das zwar beheben, indem ich pausiere und später wieder fortfahre. Aber das ist kein akzeptabler Zustand. Jemand eine Idee? Was mir noch auffällt ist, dass nach der PAUSE der Mover noch ne Weile läuft. Als ob er Sachen aus dem Cache noch abarbeitet. Sollte der Cache bzw. die Cache-Platte nicht eigentlich nur für Datentransfer von der Cache-Platte selbst dienen auf HDDs?

Fehlerlog einer von drei Platten: Feb 13 04:23:26 Tower kernel: ata4.00: failed command: READ FPDMA QUEUED Feb 13 04:23:26 Tower kernel: ata4.00: cmd 60/18:f0:10:bb:a3/05:00:59:01:00/40 tag 30 ncq dma 667648 in Feb 13 04:23:26 Tower kernel: ata4.00: status: { DRDY } Feb 13 04:23:26 Tower kernel: ata4: hard resetting link Feb 13 04:23:32 Tower kernel: ata4: link is slow to respond, please be patient (ready=0) Feb 13 04:23:33 Tower kernel: ata4: SATA link up 1.5 Gbps (SStatus 113 SControl 310) Feb 13 04:23:33 Tower kernel: ata4.00: configured for UDMA/33 Feb 13 04:23:33 Tower kernel: ata4: EH complete Feb 13 04:23:34 Tower kernel: ata4.00: exception Emask 0x10 SAct 0x607c00 SErr 0x4090000 action 0xe frozen Feb 13 04:23:34 Tower kernel: ata4.00: irq_stat 0x00400040, connection status changed Feb 13 04:23:34 Tower kernel: ata4: SError: { PHYRdyChg 10B8B DevExch } Feb 13 04:23:34 Tower kernel: ata4.00: failed command: READ FPDMA QUEUED Feb 13 04:23:34 Tower kernel: ata4.00: cmd 60/40:50:58:c6:a3/05:00:59:01:00/40 tag 10 ncq dma 688128 in Feb 13 04:23:34 Tower kernel: ata4.00: status: { DRDY } ........... Feb 13 04:29:30 Tower kernel: ata4.00: exception Emask 0x1 SAct 0x800000 SErr 0x0 action 0x0 Feb 13 04:29:30 Tower kernel: ata4.00: irq_stat 0x40000001 Feb 13 04:29:30 Tower kernel: ata4.00: failed command: READ FPDMA QUEUED Feb 13 04:29:30 Tower kernel: ata4.00: cmd 60/08:b8:00:00:00/00:00:00:00:00/40 tag 23 ncq dma 4096 in Feb 13 04:29:30 Tower kernel: ata4.00: status: { DRDY } Feb 13 04:29:30 Tower kernel: ata4.00: configured for UDMA/133 (device error ignored) Feb 13 04:29:30 Tower kernel: ata4: EH complete Feb 13 04:29:30 Tower kernel: sd 4:0:0:0: [sdq] tag#31 UNKNOWN(0x2003) Result: hostbyte=0x00 driverbyte=DRIVER_OK cmd_age=0s Feb 13 04:29:30 Tower kernel: sd 4:0:0:0: [sdq] tag#31 Sense Key : 0x2 [current] Feb 13 04:29:30 Tower kernel: sd 4:0:0:0: [sdq] tag#31 ASC=0x4 ASCQ=0x22 Feb 13 04:29:30 Tower kernel: sd 4:0:0:0: [sdq] tag#31 CDB: opcode=0x88 88 00 00 00 00 00 00 00 00 00 00 00 00 08 00 00 Feb 13 04:29:30 Tower kernel: I/O error, dev sdq, sector 0 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 2 Feb 13 04:29:30 Tower kernel: Buffer I/O error on dev sdq, logical block 0, async page read Feb 13 04:29:30 Tower kernel: sd 4:0:0:0: [sdq] tag#13 UNKNOWN(0x2003) Result: hostbyte=0x00 driverbyte=DRIVER_OK cmd_age=0s Feb 13 04:29:30 Tower kernel: sd 4:0:0:0: [sdq] tag#13 Sense Key : 0x2 [current] Feb 13 04:29:30 Tower kernel: sd 4:0:0:0: [sdq] tag#13 ASC=0x4 ASCQ=0x22 Feb 13 04:29:30 Tower kernel: sd 4:0:0:0: [sdq] tag#13 CDB: opcode=0x88 88 00 00 00 00 00 00 00 00 00 00 00 00 08 00 00 Feb 13 04:29:30 Tower kernel: I/O error, dev sdq, sector 0 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 2 Feb 13 04:29:30 Tower kernel: Buffer I/O error on dev sdq, logical block 0, async page read Feb 13 04:29:30 Tower kernel: sd 4:0:0:0: [sdq] tag#14 UNKNOWN(0x2003) Result: hostbyte=0x00 driverbyte=DRIVER_OK cmd_age=0s Feb 13 04:29:30 Tower kernel: sd 4:0:0:0: [sdq] tag#14 Sense Key : 0x2 [current] Feb 13 04:29:30 Tower kernel: sd 4:0:0:0: [sdq] tag#14 ASC=0x4 ASCQ=0x22 Feb 13 04:29:30 Tower kernel: sd 4:0:0:0: [sdq] tag#14 CDB: opcode=0x88 88 00 00 00 00 00 00 00 00 00 00 00 00 08 00 00 Feb 13 04:29:30 Tower kernel: I/O error, dev sdq, sector 0 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 2 Feb 13 04:29:30 Tower kernel: Buffer I/O error on dev sdq, logical block 0, async page read Feb 13 04:29:30 Tower kernel: sdq: unable to read partition table Feb 13 04:29:30 Tower kernel: sd 4:0:0:0: [sdq] Attached SCSI disk Feb 13 04:29:32 Tower kernel: sd 4:0:0:0: [sdq] tag#16 UNKNOWN(0x2003) Result: hostbyte=0x00 driverbyte=DRIVER_OK cmd_age=0s Feb 13 04:29:32 Tower kernel: sd 4:0:0:0: [sdq] tag#16 Sense Key : 0x2 [current] Feb 13 04:29:32 Tower kernel: sd 4:0:0:0: [sdq] tag#16 ASC=0x4 ASCQ=0x22 Feb 13 04:29:32 Tower kernel: sd 4:0:0:0: [sdq] tag#16 CDB: opcode=0x88 88 00 00 00 00 03 a3 81 2a 00 00 00 00 08 00 00 Feb 13 04:29:32 Tower kernel: Buffer I/O error on dev sdq, logical block 1953506624, async page read

Morgen, ich benötige mal fachmännische Hilfe von euch. Ich bin vor kurzen umgezogen und habe ggf. 1-2 den Tower nicht sauber heruntergefahren, weil es schnell gehen musste. Der letzte monatliche Paritätscheck wurde auch ausgelassen. Daher wollte ich diesen nun nachholen. Dabei ist eine Festplatte disabled wurden, um das Problem zu beheben habe ich eine neue Server-Konfiguration angelegt. Soweit so gut, damit ist die Parität weg und ich wollte diese wieder herstellen. Eine HDD hat er dann pattu nicht mehr angenommen, wegen kann er nicht mounten. Daher habe ich xfs_repair durchgeführt mit Zero Log und seitdem geht diese auch wieder. Jedoch bekomme ich seitdem weiterhin schlechte Übertragungen und Errors. Ich habe schon ein paar Kabel durchgetauscht, daran scheint es aber nicht unbedingt zu liegen. Ich habe 2x SATA Controller Cards mit je 6 Ports. Vermutung ging auch schon in diese Richtung oder das das Netzteil nicht ausreichend Leistung bringt für alle HDDs. Jedenfalls sind es immer mal wieder andere HDDs die gefühlt Probleme machen. Ich würde bei allen xfs_repair im Wartungsmodus einmal durchführen lassen oder was denkt ihr ist der richtige Weg?

Hi, danke für den Hinweis. Nur leider ohne Erfolg. Zuerst mit Krusadar ""chmod 777 -R iobroker-data" im iobroker Ordner Dann in der Unraid-Console im root Und auch über Plugin dem Share AppData Rechte neu vergeben ohne Erfolg. Muss wohl ein anderen Docker Container nehmen. Geht zwar nachdem man den gesamten AppData Ordner mit Konfig wegschmeißt. Aber wie man ließt kommt das Problem nach einiger Zeit wieder und hält somit nur temporär an.

Guten Abend zusammen, ich habe gerade meinen js-controller auf die aktuellste Version über die Weboberfläche aktualisieren. Was für mich neu war, dass es überhaupt ging. Nur leider startet jetzt der Container nicht mehr durch. Er bleibt nach Schritt 3 hängen. Bin ich der einzige mit dem Problem? Und hat jemand eine Lösung dafür? -------------------------------------------------------------------------------- ----- Step 3 of 5: Checking ioBroker installation ----- -------------------------------------------------------------------------------- (Re)setting permissions (This might take a while! Please be patient!)... Done. Checking Database connection... Failed. Please check your configuration and try again. For more information see ioBroker Docker Image Docs (https://docs.buanet.de/iobroker-docker-image/docs). This Script will exit now.

Danke dir alturismo, hab jetzt alles umgezogen auf den neuen Container mit neustem OS und neuster CrushFTP-SW. Ich hatte vorher natürlich unter apps geschaut und kein aktuellen Container gefunden. Der Klick auf "Click Here To Get More Results From DockerHub" hat geholfen. @MAM59 ja der Trick ist mir bekannt. Jedoch wurde vorher Java 16 benutzt und in der neuen Version Java 17, daher konnte er eben in der Admin-Oberfläche nicht mehr alles darstellen und ich wollte ehrlich gesagt auch die neuste OS-Version von Linux Alpine. Ach ja und FTP ist einfach ne tolle Sache, vor allem wenn man damit aufgewachsen ist ;) Warum ich nicht einfach die Funktion vom Unraid-Server selbst genommen habe ist diese, dass ich meine Datenbank über SFTP abgleiche, aber auch Kameras habe die nur FTP können und auf meinem Server backupen. Außerdem erscheint es mir viel sinnvoller sowas zu isolieren in einem Container. Somit existiert auch kein direkter Zugriff auf den Unraid-Server über den selben Port, falls ich es doch mal übers Internet freigeben möchte. Tue ich jedoch nicht, baue mir lieber vorher ein VPN auf.

Hallo zusammen, zu aller erst habe ich den User angeschrieben, nur leider keine Antwort bekommen. Tippe darauf, dass er nicht mehr aktiv daran arbeitet. Die CrushFTP Version ist schon stark veraltet im Container und sehr wahrscheinlich auch anfällig gegenüber Log4J. Daher wollte ich Sie updaten, was auch über die Oberfläche geht. Danach startet der Container nicht mehr und nur ein Löschen und neu Aufsetzen des Containers war mir möglich. Also was habe ich dann noch getan? Ich habe versucht, dass Betriebssystem zu updaten und zu upgraden. Das mit dem Update über die Befehle update und upgrade hat soweit auch funktioniert. Auch konnte ich danach meine CrushFTP Software auf die neuste Version updaten. Jedoch geht soweit alles, nur die Server-Admin Oberfläche nicht. Vermutlich weil diese anderes als der Rest auf eine neuere Java-Version aufbaut. Das Betriebssystem Alpine habe ich ebenfalls versucht eine Versionsstufe höher und auf Version 17 zu bekommen. Leider ohne Erfolg. Alle Befehle gingen durch und ohne Fehler. Jedoch zeigt er immer noch die alte Version an unter cat /etc/alpine-release. Als ob er meine Änderungen ignoriert. Hat hier jemand ein Rat?