DataCollector

Alturismo meinte das Docker Image (die virtuelle Disk), welche per default btrfs ist. Und btrfs ist ein kontroverses Thema.
Meine Meinung: ich meide btrfs bei eigentlich allem, weil sich bei vielen gemeldeten Problemen nach einiger Suche zeigte, daß btrfs involviert oder gar die Ursache war.

Mit der Zeit lernt man dazu. Das war und ist bei Jedem so.

Wo findet man das Docker Image: in Settings / Docker wird angezeigt, wo das Image (die Datei) liegt.
Bei mir ist es (siehe Screenshot unten) /mnt/user/system/docker/docker-xfs.img

Und wie Du auch gleich erkennen kannst: ich habe mich dort dann doch eher für xfs anstatt btrfs entschieden.
Wenn Du sowieso das Image neu machen willst: ich würde dann auch Dir mal xfs ans Herz legen.

Da der Dockerdienst ja sowieso momentan nicht läuft solltest Du dort (beachte oben den Schalter um von der Basic Ansicht auf Advanced umzuschalten) die notwenigen Optionen an der Stelle finden.
Dann hast Du ein neues und leeres Image.
Wenn der Dockerdienst gestartet ist, solltest Du im Reiter "Docker" unter der Option Add COntainer auch Deine alten Templates wiederfinden, die DU dann Stück für Stück neu einspielen kannst.

Ein Wort noch, was in Alturismos Beitrag nicht so herausgesprungen ist: wenn das Dockerimage voll gelaufen ist, hat das einen Grund.
Nicht selten sind es falsch gesetzte Pfadangaben, die dann zu viele Daten ins Image geschrieben haben und es somit voll laufen liessen.

Will sagen:
1. fertige ab und zu Backups an und
2. Schau Dir Deine Angaben der einzelnen Dockerconbtainer nochmal an, denn sollte es wirklich mit den alten Parametern voll gemüllt worden sein, passiert das beim neuen Image bestimmt auch wieder, wenn Du nichts änderst.

Ich weiß nicht, ob es damit zu tun hat, aber ich sehe extrem häugie Ram Fehler (fast jeden Tag gecshätzt hunderte Einträge).
Auch wenn ECC ein paar Fehler abfangen kann: irgendwann ist es ggf. zuviel(e gleichzeitig).
Teste den RAM und bereite Dich darauf vor mindestens einen Rioegel zu tauschen oder die Betriebwerte abzumildern.

2,7MByte große Syslogdatei - über 28tausend Zeilen und fast alle/überwiegend viele haben mit dem ECC zu tun:
...
Feb 23 06:53:24 NASMediaServer kernel: {3449}[Hardware Error]: Hardware error from APEI Generic Hardware Error Source: 1
Feb 23 06:53:24 NASMediaServer kernel: {3449}[Hardware Error]: It has been corrected by h/w and requires no further action
Feb 23 06:53:24 NASMediaServer kernel: {3449}[Hardware Error]: event severity: corrected
Feb 23 06:53:24 NASMediaServer kernel: {3449}[Hardware Error]: Error 0, type: corrected
Feb 23 06:53:24 NASMediaServer kernel: {3449}[Hardware Error]: fru_text: CorrectedErr
Feb 23 06:53:24 NASMediaServer kernel: {3449}[Hardware Error]: section_type: memory error
Feb 23 06:53:24 NASMediaServer kernel: {3449}[Hardware Error]: node:60784 device:12343
Feb 23 06:53:24 NASMediaServer kernel: {3449}[Hardware Error]: error_type: 2, single-bit ECC

Feb 23 06:54:25 NASMediaServer kernel: {3450}[Hardware Error]: Hardware error from APEI Generic Hardware Error Source: 1
Feb 23 06:54:25 NASMediaServer kernel: {3450}[Hardware Error]: It has been corrected by h/w and requires no further action
Feb 23 06:54:25 NASMediaServer kernel: {3450}[Hardware Error]: event severity: corrected
Feb 23 06:54:25 NASMediaServer kernel: {3450}[Hardware Error]: Error 0, type: corrected
Feb 23 06:54:25 NASMediaServer kernel: {3450}[Hardware Error]: fru_text: CorrectedErr
Feb 23 06:54:25 NASMediaServer kernel: {3450}[Hardware Error]: section_type: memory error
Feb 23 06:54:25 NASMediaServer kernel: {3450}[Hardware Error]: node:60784 device:12343
Feb 23 06:54:25 NASMediaServer kernel: {3450}[Hardware Error]: error_type: 2, single-bit ECC

Feb 23 09:27:35 NASMediaServer rc.rsyslogd: Syslog server daemon... Started.
Feb 23 09:27:35 NASMediaServer cache_dirs: Arguments=-l off
Feb 23 09:27:35 NASMediaServer cache_dirs: Max Scan Secs=10, Min Scan Secs=1
Feb 23 09:27:35 NASMediaServer cache_dirs: Scan Type=adaptive
Feb 23 09:27:35 NASMediaServer cache_dirs: Min Scan Depth=4
Feb 23 09:27:35 NASMediaServer cache_dirs: Max Scan Depth=none
Feb 23 09:27:35 NASMediaServer cache_dirs: Use Command='find -noleaf'
...

Es ist möglich, daß der Kontroller einen Schlag weg hat.
Solche Fehleranzeigen sind ggf. nur die "Auswirkung". Aber vorher könnten schon hinweise erkennbar sein (Reduzierungen in der Schnittstellengeschwindigkeit, etc...).
Vielleicht kann man in den diagnostics mehr sehen.

Du sagst auch, daß Du die Kabel geprüft hast: Wie hast Du das gemacht?

Ein paar Schüsse ins Blaue, was vielleicht möglich ist:

Schuss 1:
Das "ASRock Fatal1ty AB350 Gaming-ITX/ac (90-MXB5P0-A0UAYZ)" hat einen Wifi, der anscheinend einen Key E belegt. (Laut www.gh.de und dem Manual)
Da CNVI eine Intel Technik ist sollte am Key E ein PCIe verfügbar sein.
Wenn der WiFi Adapter hinten im ATX Feld nur im M-2 Key E gesteckt ist (und nicht gelötet) und dieser nicht benötigt wird, kann man (mit sehr viel Bastelei) die PCIe Lane in dem Port auf Stand PCIe 3.0 x1 adaptieren.
(Bei Key E ist zwar sogar PCIe x2 spezifiziert, aber in aller Regel liegt dort nur PCIe 3.0 x1 an (sofern man PCIe nicht ganz weggelassen hat und bei Intel Boards nur noch CNVI einsetzt)).

Langer Rege kurzer Sinn: vielleicht kannst Du prüfen ob der WIFI im M.2 Key E im ATX Feld schadlos entfernbar ist. Dann hast Du möglicherweise einen PCIe 3.0 x1 um damit eine Grafikkarte zu betreiben.
Es gibt sogar etwas ältere PCIe x1 Karten, aber da PCIe abwärtskompatibel ist, kannst Du dort mehr oder minder jede Standard PCIe Grafikkkarte anschließen.
https://www.amazon.de/KALEA-INFORMATIQUE-M2-Karte-Verwendung-PCIe-Karte-Key-Anschluss/dp/B078883MK2
https://www.ebay.de/itm/365749105448

Nachteil: das wird ein ziemlicher Kabelverhau und die Graka in das (vermutlich) ITX Gehäuse zu friemeln wird auch bestimmt nicht einfach.

Schuss 2:
Es gibt PCie Switchkarten, die das gleichzeitige Anschließen von mehreren Geräten ermöglichen. Sowas in den PCIe x16 Slot rein und Du kannst Deine 10G Karte (die ja bestimmt nur x4 oder x8 ist) gleichzeitig mit einer Grafikkarte nutzen.
Das wird im Gehäuse aber vielleicht auch eng.
https://www.amazon.de/gp/product/B0CG1GXM26
https://www.amazon.de/KALEA-INFORMATIQUE-M2-Karte-Verwendung-PCIe-Karte-Key-Anschluss/dp/B078883MK2

Schuss 3:
Wenn Dein Mainboard Bifurcation beherrscht (und die CPU es auch unterstützt) könntest Du den x16 Slot auch 2fach benutzen.
Pferdefuß1: Um Bifurcatioon einzustellen musst Du auch erst einmal ins BIOS rein.
Pferdefuß2: Bei Bifurcation werden ja auch 2 (und die Adapterkarte) an x16 angeschlossen. Also auch da ggf. ein Platzproblem, wenn es nur ein winziges ITX Gehäuse ist.
https://www.amazon.de/10Gtek-Dual-NVMe-Adapter-Card-2-x-M-2-M-Key/dp/B09NKTYFHX
https://www.amazon.de/KALEA-INFORMATIQUE-M2-Karte-Verwendung-PCIe-Karte-Key-Anschluss/dp/B078883MK2


Dies sind technische Ideen, wie man ein System mit Deiner Bestückung ggf. um eine Graka erweitern kann (oder noch mehr). Ob es Sinn macht ein extra kleines ITX Board mit so einem zusätzlichen Verhau zuz erweitern ist zweitrangig und muß jede/r für sich selbst entscheiden..

Die Links stellen nur Beispiele dar um zu verdeutlichen, was ich meine. Dies sind keine Empfehlungen für diese Produkte.

Das sich xfs beiweiten seltener als Problemursache herauskristalisiert bei zurvor unerklärlich erscheinenden Problemen.

Wenn hier im Forum irgendwelche Probleme beschrieben werden,taucht nicht selten als Ursache im Rahmen der Recherche btrfs (bzw. damit im Zusamnmnenhang stehende Fehler) auf.

Deshalb habe ich alle Pools im Raidverbund von btrfs auf zfs umgestellt und auch meine Docker VDisks auf xfs.

Ich empfehle weiterhin für unraid:
Single Datenträger (also auch Array und hier auch Docker vDisk): xfs.
Wenn man mehrere Datenträger miteinander verbinden will: zfs.

Da Du Deine ursprüngliche btrfs vDisk leider entfernt hast ist eine nachträgliche Analyse nicht mehr möglich.

Vorausgesetzt, es ist nicht noch mehr schief gelaufen:

Backup Deinr Daten auffrischen (zumindest als UD sind ja alle wohl noch lesbar),
Array mit dem Tool new config auflösen (nur das betroffenen Array und nicht die Pools),
Array mit den Festplatten wieder neu erstellen,
Array starten und Paritycheck machen (und Parity bei bedarf korrigieren lassen).
Warten bis Paritycheck fertig ist und freuen, dass es wieder läuft.

Zeitbedarf bei 16TB großer Parity: geschätzt 1,5 Tage.

Wechsel zu einzelnem Datenträger mit xfs.
Alternativ (wenn es ein raid sein soll): zfs

Eigentlich klingt mir das ganze recht vernünftig eingestellt.
Primär oder exklusiv Pool
Wenn überhaupt Array als Secondry (falls der Pool doch mal voll läuft will man ja nicht gleich, daß alle Docker abschmieren).
Und wenn Mover aktiv wird, soll er alles von Array (was nicht gerade durch Docker blöockiert wird) wieder in den Pool verschieben.

Damit der Mover das machen kann, dürfen die Docker aber die Dateien eben nicht gerade festhalten. Also Docker aus, mover an, warten, docker wieder an, fertig.


Solange ausreichend Platz im (SD) Pool vorhanden ist, will man das nicht im Array haben, ja. Sollte aber man der Pool voll gelaufen sein, ist es für mich schon sinnvoll den Docker temporär auch im Array werkeln zu lassen, anstatt, daß einzelne Docker wegen Schreibfehlern Stück für Stück mit Fehlermeldungen (oder gar ohne) abschmieren.
Find ich gut.


Ich sehe da kein problem drin.


Vermutlich war der Dockerdienst dennoch an?


Stoppe alle Docker, stoppe den Docker dienst, starte den Mover.
Der sollte dann von der Disk in den Pool verschieben (sofern ausreichend Platz vorhanden ist).
Wenn der Mover fertig ist, kannst Du Docker Dienst und die Docker selber wieder starten.

Ich lasse mir dort die Geschwindigkeiten anzeigen, Die Anzahl der Schreibzugriffe selber interesseiert mich nicht wirklich.


Da dort nur die Zahlen seit dem letzten Reboot aufgelistet/summiert werden sagen die Zahlen nichts über absolute Schreibzugriffe aus. Da kann der Rechner schoin 3 Jahre existieren: ich scchätze DU hast zwischendurch schon einige Updates und reboot durchgeführt?

Hast Du die Systeme seit der allerersten Inbetriebnahme noch nie neu gebootet?


Nein, da Du vermutlich nicht beide Systeme absolut identisch eingerichtet hast und auch nicht immer absolut identisch nutzt.


ja.

Bevor Du die Lizenzen nun vermurkst hast, hätte ich es so gemacht:
- Den Stick mit der Plus Lizenz sichern.
- Dann in dem config Ordner des Plus Sticks alle Dateien löschen, ausser den dort enthaltenen plus.key.
Den Config Ordner des Basic-Sticks auf den Plus ordner kopieren (aber nicht die basic.key).
Stick booten.
fertig.
 
 
Die Zeitverschiebung macht es möglich.
 
 
Das war zu befürchten. Die IDs sind eben nun beide "verbrannt".
 
Zuerst mach ein Backup Deiner Sticks.
 
Die Konfigurtaiton hängt primär am config Ordner Mach Deinen neuen Stick. kopiere den gewüschten Konfig ordner drauf, entferne die unerwünschet basic.key datei.
Starten und die Lizenz darauf übernehmen lassen.
 
EDIT:
Wenn Dir dann Docker fehlen: Im Docker Tab mit AddContainer und der Auswahl der schon dort vorhandenen Container diese wieder installieren.
Die EInstellungen sind ja auch dem USB Stick und einen fehlenden Container zieht sich unraid dann in der aktuellen Version aus dem Netz.

Das hängt (für mich) von Größe und Wert (und Technik) der bestehenden USB Festplatten ab.   (Will sagen, man weiß von Deiner Situation/Hardware zu wenig).
 
Ich würde bevorzugen: Alles komplett neu/anders. USB Laufwerke nicht übernehmen.
 
Wenn man aber dann einen Satz 24TB festplatten als SATA neu kauft und einbaut und dafür dann mehrere 24TB ext. USB festplatten ausmustert wäre mir das zu teuer. Da würde ich dann schauen ob ich die 24TB USb nicht shucken kann und die direakt als SATA nutze.
 
Sollte es sich alt um einige der kleinen WD 2,5inch Modelle mit fest aufgelöteter USB Schnittstelle handeln ist das Shucken dort sinnlos, weil ,man die nicht pere SATA direkt anschließen kann.
 
 
Die Konfiguration ist ja auch dem USB Bootstick. Die brauchst Du eigentlich nicht zu ändern.

Das hat nichts mit 7.x zu tun.
Eigentlich ist die Aussage ziemlich eindeutig.
Deine Key Datei ist beschädigt.
Die Datei sollte auf dem USB Stick sein, sie scheint aber entweder nicht vorhanden oder beschädigt zu sein.
Solltest Du mal ein lokales Backup des USB Stick angefertigt haben ist die Datei auch dort drin.
Dein Stick scheint wohl ein Problem zu haben. Du solltest alles sichern, dann testen ob der Stick noch in Ordnung ist und wenn er in Ordnung ist, einmal neu formatieren, Deine Sicherung zurückspielen und den key aus einem früheren Backup dort hinzu fügen.
 
Das Problem solltest Du übrigens nicht auf die lange Bank schieben. Es könnte sein, daß Dein unraid nach einer gewissen Zeit dann nicht mehr offline startet.
 
 
USB ist im Array bei unraid nicht empfohlen.
Man kann in den Disk Settings das Timeout einstellen.
Leider richten sich diverse Bridges in exterenen USB Gehäusen nicht danach und die Platten gehen dann nicht in den Spindown.
Tja, erwähnte ich schon, daß USB im Array unter unraid eben nicht empfohlen wird?
 

Okay, bei einem UEFI System muß das EFI Verzeichnis so heißen. Wäre es ein CSM System müsste man das Verzeichnis umbenennen.
 
 
Es mag zwar so sein, aber, daß ein USB Stick physischen Schaden (Defekte Speicherblöcke) nur durch ein Update abbekommt ist unwahrscheinlich.
Ich vermute es sind schon bei der 7.0 Version wichtige Dateien beschädigt worden.
 
Ich würde (wie schon vorgeschlagen) von dem USB Stick ein Backup extern ablegen, dann den USB Stick in einen anderen PC stecken und erst einmal komplett löschen, dann einmal komplett voll beschreiben und prüfen ob dabei alles noch okay geblieben ist (unter Windows eignet sich dafür beispielsweise das Tool des heise Verlages: h2testw).
Wenn der Stick bei den Tests keinen Fehler aufweist: komplett löschen und den unraidStick mit der gewünschten unraid Version neu erstellen (bevorzugt auf die manuelle Weise).
https://docs.unraid.net/unraid-os/getting-started/manual-install-method/
Ich würde es direkt mit der Version 7.1.0 machen.
Dann kopierst Du aus dem Config Ordner Deines Backups nur die Lizenzdatei (*.key) in den config Ordner des neu erstellten USB Sticks.
Achte darauf, daß der EFI Ordner auch wirklich EFI heißt und der Name keinen Strich oder so enthält.
Dann versuche mal diesen frisch neu erstellen alten USB Stick in dem unraidPC zuu booten. Klappt das?
 
Wenn es klappt kannst Du von da aus weiter machen und versuchen Dein System richtig einzurichten. Da die Dateien der früheren Version auf dem Stick möglicherweise beschädigt sind (und wir ja nicht wissen, welche), würde ich ggf. versuchen möglichst wenige/keine weiteren Dateien des Backups in das config Verzeichnis des neu erstellten Sticks zu überspielen. Vielleicht solltest DU Dein System einfach mit den nun funktionierenden Stick neu einstellen. Ja, das ist aufwändig, aber man ist auch gleich Altlasten los.
 
Sollte der USB Stick bei dem Test (siehe oben, beispielsweise mit h2testw) einen oder mehrere Fehler gezeigt haben, scheint er wirklich defekte Speicherzellen oder gar einen Schaden im USB Stickkontroller zu haben. Dann ist es wirklich Zeit für einen neuen USB Stick.
 
 
 
Okay, Du hast anscheinend im BIOS eingestellt, daß er alle relevanten Informationen mit dem FullScreen AMI LOGO überdecken soll. Sowas schlte ich in aller Regel aus, damit man die Textmeldungen bekommt.
 
 
Checkdisk oder die internen WIndows Tools? Vergiß das.
Wie gesagt: Nachdem Du den Stick in ein Backup gesichert hast: löschen und mit h2testw unter windows einmal vollschreiben und lesen lassen.
https://www.heise.de/download/product/h2testw-50539
Wenn efhlerfreei: Löschen und unraid darauf frisch neu installieren (+Lizenzdatei).
Wenn Fehler gemeldet: Stick vermutlich beschädigt. Dann einen anderen nutzen.
 
 
 
Deinem Bild nach ist es ein N100. Hat zwar nichts mit Deinem Problem zu tun, aber da es nur sehr wenige empfehlenswerte N100 Platinen gibt: Das ist hoffentlich kein Mini PC, an dem Du Datentrtäger per USB anbindest (abgesehen vom unraid Boot Stick)?
Falle doch: das ist nicht empfehlenswert. Vielleicht solltest Du Dich nach einem anderen Setup umsehen.

Korrekt.
Und darin eben (vermutlich) einen der beiden enthaltenen Datrenträger.
Es wird eben immer gemeldet, daß es da BTRFS Read Errors bei /dev/sdf1 zu geben scheint, welche durch BTRFS korrigiert/ausgebügelt müssen/werden.
Ob es nun ein Fehler verursacht durch BTRFS selber ist, oder der Datenträger selber Probleme hat, ist anhand des Logs nicht erkennbar. Da aber die relevanten Smart Werte wohl nicht angestiegen sind, schätze ich, daß es wieder einmal ein rein interner BTRFS Fehler/Problem ist.
Man liest hier im Forum ja nicht zum ersten Mal davon, daß sich Probleme ergeben, die sich dann als BTRFS verursacht zeigen.
 
Bei Single Disks bevorzuge ich xfs, bei einem Verbund nutze ich seit unraid 6.12.x da eher zfs.
Selbst meine Docker Imagedatei habe ich von btrfs auf xfs umgestellt.
 
 
 
Okay, dann hast Du die also alle ins Array verschoben. Dadurch, daß BTRFS (vermutlich als Raid1 betrieben) die Fehler anscheinend erkannt hat, wurden die beim Umkopieren mutmaßlich behoben und Du solltest wohl dann im Array (hoffentlich) fehlerfreie Dateien haben.   (Die Hoffnung stirbt zuletzt 😄)
 
 
 
Der Paritycheck im array betrachtet nicht den logisch korrekten Inhalt der Dateien, bzw interessiert sich nicht, ob die Dateien darin den gewünschten Inhalt enthalten. Der Paritätschek sichert nur ab, daß die Quersumme aller Bits des selben Sektors (über alle Array Datenträger) dem entspricht, was da ursprünglich als Quersumme berechnet wurde als die Dateien da mal rein geschrieben wurden.
 
 
 
Die Samsung 850 Pro ist also Deine SATA Disk im SATA +NVMe BTRFS Raid1 Verbund.
Bisher hattest Du ja immer nur von "einer 128GB SSD-Platte und einem 128GB NVM-Speicher" geschrieben. (Ich wußte also nicht welche SSDs Du dort zusammengeschaltet hast.)
Wie schon gesagt: ich gehe ja nicht davon aus, daß die SSDs (egal welche der beiden) ein wirkliches Hardwareproblem hat.
 
Der "BTRFS Read Error" könnte im BTRFS System begründet liegen und der "(UDMA) CRC Check Error" in den Smartwerten könnte (mit großer Wahrscheinlichkeit) ein Verkabelungsproblem/SATA Datentransportproblem sein.
2 unterschiedliche Probleme die selber wohl nichts miteinander zu tun haben müssen.
 
Daß somit ein SMART Test eines (oder auch beider) Datenträger technisch keinen Fehler (abgesehen vom hochgelaufenen UDMA Zähler) findet ist somit logisch.
 
Ich wiederhole mich somit: "...und lasse dann Deine BTRFS Datenträger auf Fehler überprüfen und diese beheben." 
Damit habe ich mich aber wohl unklar ausgedrückt. Sorry!!
Ich meine daß Du nicht die SSDs einzeln auf Hardwareproblem prüfen sollst (abgesehen von der Verkabelung der SSD mit den CRC Fehlern), sondern das Dateisystem auf den Datenträgern (BTRFS). Damit war ein Scrubbing oder so gemeint.
Da Du aber Deine Daten wohl sowieso alle dort entfernt hast, kannst Du auch einfach den SSD Pool auflösen (new Config) mit den gewünschten neuen Datenträgern neu erstellen, dann den Pool mit dem gewünschten neuen Dateisystem formatieren (vielleicht dieses mal nicht mehr BTRFS?) und dann Deine Dateien wieder vom Array in den Pool zurückschreiben.
 
Ach ja: und dennoch finde ich den Ratschlag richtig, wenn man ein System hat, bei dem vielleicht Daten beschädigt werden können: Backup erstellen!
 
Ergänzungen zu Deinem SMART Protokoll:
Deine Samsung SATA SSD ist zwar SATA 3 (6GBit/s) fähig, wurde aber zum Testzeitpunkt aber nur mit SATA-2 (3GBit/s) betrieben.
Du hast also Deine (vermutlich) weitaus schnellere NVME SSD nicht nur durch SATA runter gebremst, sondern hast SATA auch noch einmal nur halb so schnell in Betrieb, wie es die SSD hergeben würde.
- Benutzt Du ein sehr altes Mainboard, welches nur SATA 2 Anschlüsse hat?
- Oder ein altes Intel Sandy Bridge Board, welches 2 unterschiedliche SATA Normen stützt (und Du hast die SSD an den langsameren Port angeschlossen)?
- Oder haben die Kontroller wegen den UDMA CRC Fehlern die Geschwindigkeit runter geregelt um weitere Fehler durch 'zu hohe Frequenten' auf dem zu schlechte Kabel zu vermeiden?
Das ist leider unbekannt.
Siehe Screenshot 1
 
Du hast auch nicht 99 Fehler im CRC Error Parameter Nummer 199, sondern nur 4.
Siehe Screenshot 2
 
 
Screenshot 1:

 
Screenshot 2:

Meine Aussage beruht darauf:
Ein frischer unraid USB Boot Stick funktioniert.
Ein manipulierter USB hat die beschriebenen Probleme.
 
Unraid selber speichert Änderungen in *.cfg Dateien.
Solange man also den Webzugriff nicht durch einen Router/Switch/Docker oder so filtert/manipuliert muß es eine Veränderung an unraid sein.
Also muß das Problem in den Einstellungen der *cfg Dateien sein.
 
Welche Einstellung es ist kann nur jemand herausfinden, der das Problem hat.
Also bleibt es nur die cfg Dateien zwischen "funktioniert" und "funktioniert nicht" zu vergleichen und jede Änderung, die diesen Themenbereich (Netzwerk) berührt, einzeln zu prüfen und ggf. auszuprobieren ob es das ist.
 
Da kann ich aus der Ferne auch nicht helfen, da ich das Problem nicht habe und somit selber nicht suchen könnte.
 

Ja.
 
 

Du hast ja schon genau festgelegt, was Du wie einsetzen willst.
Somit verstehe ich Deine Frage nicht wirklich.
Auch sehe ich keinen Datenträger, der sich um Datencache für das Array kümmern soll. Vielleicht solltest Du überlegen Deinen 2x2TB Pool dahingehend mitzuverwenden.
 
 
Wähle zuerst a oder b (siehe unten), dann mache mit c weiter:
 
a) Wenn Du Deine Daten über einen langen Zeitraum später nach und nach auf unraid über SMB kopieren willst, würde ich so vorgehen:
Du erstellst ein Array mit den Festplatten: 18TB als Parity die restlichen jeweils als Datenfestplatten, xfs (falls gewünscht encrypted).
 
b) Wenn Du Deine Daten schon weitgehend vorliegen hast (Deine HD Filme) und sie schnell ins Array pressen willst anstatt später über einen langen Zeitraum, dann würde ich das Array erst einmal ohne die 18TB Parity erstellen. Dann schreibt es sich schneller ins Array.
 
c) Dann erstellst Du einen Pool namens "cache" und steckst dort die 128GB NVME SSD rein.
Als nächstes erstellst Du einen weiteren Pool mit einem beliebigen Namen (vielleicht "stuff") dort ordnest Du die beiden 2TBV NVMe SSDs zu und verwendest zfs raid1 (mirror).
Nun startest Du das Array und in Folge dessen formatierst Du all die Datenträger.
Wenn Du Docker einstellst, entscheide Dich jetzt ob Du per default btrfs Image, xfs image oder Ordnerstruktur in dem Pool namens "cache" nutzen willst (ich nutze bevorzugt xfs Image). Dann kannst Du auch den Docker starten.
Dann kannst Du weiter machen und Deine Shares einstellen...
Jetzt stopfst Du Deine Daten in die unraid shares (ins Array und Deinen persönlichen pool kopieren).
 
Wenn alles/das meiste angekommen ist und Du Option b gewählt hast, kannst Du die 18TB Parity jetzt nachträglich einbinden.
 
So, da das alles aus dem Kopf auf die Schnelle getippt wurde hoffe ich, ich habe keinen Denkfehler eingebaut.
Have fun!

Ich sehe es als besser an: die defekte Datei(en) [*.bz] umbenennen, die gleichen Dateien aus dem passenden unraid ZIP aufkopieren und danach die alten Dateien löschen.
Dadurch ist gewährleistet, daß die vielleicht defekten Blöcke unter den Dateien nicht direkt neu beschrieben werden und somit die Datei wieder defekt ist.
Hintregrund: Im Gegensatz zu SSDs sind USB Sticks ziemlich dumm. Wenn sie einen Block als defekt erkannt haben wird dieser zwar verzeichnet und nicht mehr neu benutzt, aber ob der Block hier erkannt wurde weiss man nicht. Somit erst einmal belegt lasen und andere beschrieben.
 
Wenn man den Stick anzweifelt: Backup machen (ist übrigens immer ein gute Rat!), dann bei einem anderen PC ausgiebig testen (alles drauf löschen, mindestens einmal überschreiben und dann alle Blöcke lesen [das Windowstool "h2testw" ist dafür sehr gut geeignet]).
Falls der Stick es überlebt und keine/wenige Fehler anzeigt: Danach das Backup wieder aufspielen.
 

Das eine 990 Pro schon mal "abschmiert" habe ich schon hier gelesen.
Die betreffende Person hat gegen eine andere 990 Pro getauscht (wenn ich mich recht entsinne) und seitdem geht es.
 
EDIT:
https://forums.unraid.net/topic/186948-samsung-990-pro-verliert-regelmäßig-die-verbindung/
https://forums.unraid.net/topic/186205-mein-unraid-server/#findComment-1534639
 

Beide alten NVMe SSD rausnehmen. Eine davon in den ext Adapter.
Beide neuen NVMe SSD rein und Pool aufbauen.
(Falls unraid wegen fehlendem alten pool meckert mit 'new config' die Pools killen. alle noch vorhandneen pools dann wieder identiusch erstellen (falsl es neben dem hier besprochenen pool noch weitere gibt.)
 
Danach vom ext Adapter die Dateien 1:1 auf den nun neuen Pool kopieren.
 
Sollte bei den neuen SSDs/Pool etwas schief gehen hat man die Daten am ext. Adapter und seiner Zwillings NVMe SSD immer noch unverändert in der Hinterhand.
 

Das war eigentlich schon jahrelang möglich, aber...
 
 
...das ist eben erst bei unraid mit V7 möglich geworden.
 
 
Es verhält sich so, wie man es einstellt.
 
 
Eine Paritydisk (wie man es klassisch bei urnaid bezeichnet) betrifft das Array. Das hat mit einem Pool nichts zu tun.
 
 
Mirror = Spiegel
Eine Disk ist der Spiegel der anderen und beide haben den gleichen Dateiinhalt.
 
 
Ersteres sollte passieren.
 
 
Bezogen auf die Nutzdaten: Grundlegend stimmt das auch.
 
 
Das hängt auch von dem gewählten Dateisystem ab, aber ja, auch das ist grundlegend so gedacht. Evtl. muß man manuell noch die Synchronisation anstoßen, aber ja, das Dateisystem, welches den "Mirror" steuert, sollte sich darum kümmern. Das ist aber dann kein Feature direkt von unraid, sondern des gewählten Dateisystemes (zfs, btrfs, ...).
 

In Ergänzung zu der Aussage von alturismo:
 
Es kllingt, als wenn eine der BZ Dateien auf dem USB Stick defekt ist und deshalb das enthaltene Betriebssystem nicht booten kann.
 
Mir fallen 3 Möglichkeiten der Reparatur ein:
aber zuerst: kopiere Alle Dateien des USB Sticks erst einmal irgendwohin (nur zur Sicherheit).
 
a) Falls Du von den USB Stick schon einmal ein Backup mit der selben unraidversion gemacht hast, kannst Du (zumindest) die BZ Dateien aus Deiner Sicherung nehmen und auf den USB Stick wieder drauf kopieren.
 
b) falls Du kein früheres Backup angefertigt hast kannst Du Dir die ZIP mit der passenden Betriebssytemversion runter laden und aus dem ZIP die BZ Dateien nehme und die auf den USB Stick kopieren.
Die Zips der letzten paar Versionen kannst Du hier finden:
https://docs.unraid.net/unraid-os/download_list/ 
 
oder
 
c) Du löschst Deinen USB Stick, beschreibst ihn komplett mit der unraidversion neu und kopierst aus Deiner Sicherheitskopie (siehe oben, vor Punk a)) den "config" ordner auf den USB Stick (dort sollten die wichtigsten Konfigurationen und Kein Key enthalten sein)
 
Falls Du zukünftig des öfteren solche Fehler bekommst, könnte der USB Stick einen Knacks weg haben. Vielleicht überlegst Du es einfach mal (nachdem Du ein aktuelles Bakckup gemacht hast) den Stick einmal komplett zu überschreiben und dann den Inhalt zu testen.
Das Windowsprogramm h2textw eignet sich dazu ziemlich gut. Sollten sich bei dem Programm Fehler zeigen, mach Dich drauf gefasst einen neuen/anderen USB Stick beschaffen/verwenden zu müssen, weil der aktuelle dann wohl Probleme hat.
Und leider (im Gegensatz zu Festplatten oder SSDs) haben USB Sticks in dem Zustand keine Selbstreparaturfunktionen (mehr übrig) um Defekte weitergehend zu kaschieren.

1. Backup der Dateien auf dem Stick an eine andere/sichere Stelle.
2. Versuch mal den (oder vielleicht sogar einen anderen USBStick) neu zu machen. Du musst den ja nicht lizensieren, wenn er doch durchbootet.
 
Ich schätze eine der Dateien auf dem Stick ist nicht korrekt geschrieben worden.
 

Wir sind schon bei 6.12.14 (stable)
 
 
Deinem Screenshot nach: ja.
 
 
Wie kommst Du darauf?
ASM1064: Autotune: nein!!!!
ASM1166: Autotune; ja
 
 
Das war bei der ASM1064 ein Problem.
 
 
Teste erst ohne Flashen ob das System mit je einer der Karten nicht schon selber in die niedrigen C-States geht. Wenn das System mit einer der Karten bei C2 oder C3 hängen bleibt, dann kannst Du Erfolg damit haben wenn Du flashst.
Möglicherweise ist ja schon die Original Firmware sehr gut.
 
 
Hier ist zu viel "Bad". Das sollte (zum Strom sparen) möglichst alles auf Good stehen und das kannst Du bequem mit dem auto-tune hinbekommen.
 

dito
 
 
Den unraid USB Stick kannst Du aus unraid heraus direkt als ZIP Datei backuppen.
Für das erste Backup aller Deiner persönlichen Daten wirst Du sowieso erst einmal ein Vollbackup erstellen müssen.
 
 
Irgendwie wirst Du das System wecken müssen. WOL, IP STeckdose, Switchbot, RaspiKVM oder so...
Die beiden Disks werden aber dann ziemlich groß sein müssen um alle Daten des 8Bay NAS aufzunehmen.
 
 
Ist Dir das mgutt Script für Backups schon aufgefallen?