mgutt

Kann ich leider nicht verwenden, da Samsung kein Update bei den Root Zertifikaten macht.

Also sind da sehr wohl Dateien drin. Naja aber der erstellt doch irgendwo seine Backups (außerhalb des Containers)?!

Mach mal im unRAID Terminal das: ls -lah '/mnt/user/media/Ebooks/$MdR'* Der unRAID Dateiexplorer hat manchmal Bugs bei der Darstellung.

Hast du ein Backup vom appdata wo die Rechte nicht korrigiert wurden? Wie sieht so ein Lucky Backup aus? Also ist das ein Ordner. Zeig mal bitte Screenshots.

Ehrlich gesagt bin ich zu geizig wegen einem popeligen Zertifikat statt 0 € für Let's Encrypt plötzlich 500 € pro Jahr für ein Wildcard Zertifikat zu zahlen. Gibt es die auch in billig?

Jo, ist sauber. Fix Common hatte ja auch keine doppelten Dateien gemeldet. Sieht also alles gut aus.

Naja auf eine USB Platte, in die Cloud, auf einen zweiten Unraid Server...

First page, read the 5xx error paragraph.

Use a different container: https://hub.docker.com/_/nginx

Langsam habe ich das Gefühl, dass die ihre Fabriken absichtlich anzünden oder Rohstoffe verlieren / zerstören um die Preis hoch zu halten. Wobei ich mir kaum vorstellen kann, dass die da so einen großen Einfluss auf die Preise haben werden. Dafür ist der Marktanteil zu klein und wir sprechen ja nur von 13% eines Quartals: https://blocksandfiles.com/2022/01/06/samsung-increasingly-dominates-enterprise-ssd-market-as-intel-fades/

Ach so. Das ist ein optionales Plugin. Dann schreib doch nicht Skript ^^ Ok, dann besteht absolut Hoffnung, dass zumindest appdata in Ordnung ist. Aber die Rechte deiner Backups sind in jedem Fall kaputt. Jo

Mach auf jeden Fall ein Backup von deinem Stick. Warum die br-Fehlermeldungen kommen, weiß ich gerade auch nicht. Vielleicht stoppst du kurz mal das Array und veränderst mal in den Netzwerk-Einstellungen was hin und her. Dann sollte das denke ich wieder korrekt auf dem Stick gespeichert sein, was auch immer diesen Fehler verursacht.

Ein RAID ist kein Backup. Mehr wird man dir da nicht sagen können. Wenn du das Risiko fährst und auf Backups verzichtest: Kein Backup, kein Mitleid.

Settings > Docker > docker.img löschen

Nur 1x M.2 ist ja Wumpe, wenn man mit einem 10 € Adapter nachhelfen kann. Das Board hat die X4 ja noch als separaten PCIe Slot übrig. Trotzdem hat das Board einen großen Nachteil: Nur 4x SATA. Keine Ahnung was Supermicro in letzter Zeit macht. Beim W580 Board haben sie den selben Blödsinn gemacht und sogar noch den PCIe X4 Slot abgeschafft.

Du meinst unter "Unraid OS die Option New Permissions"? Wenn du das ausgeführt hast, hast du dir mit aller Wahrscheinlichkeit nach ein paar oder alle deine Container zerschossen. Es gibt sogar einen Hinweis dafür, wobei ich das schon länger kritisiere warum appdata bei diesem Tool überhaupt ausgewählt werden kann bzw nicht von vorneherein in einem separaten Dropdown oder so ist (mit fetter roter Warnung): Du siehst bei Fix Problems Logs auch, dass das Plugin bewusst appdata überspringt: Auch das weil in diesem Verzeichnis unterschiedlichste Rechte gelten und Fix Common Problems würde dir sonst tausende "Fehler" anzeigen. Auch spaceinvader ist nicht unfehlbar. Durch die "Korrektur" der Rechte würde ich sagen, dass jetzt nur noch ein Backup von appdata hilft. Doppelt doof: Die Backups hast du auch zerschossen, weil du ja auch da die Rechte "korrigiert" hast. Ich hoffe du hast noch welche in einem TAR oder außerhalb des Servers. Wenn nein: Arschkarte. Entweder bei Null anfangen oder jeden Container einzeln neu installieren und Rechte notieren. Dann die Rechte des Backups entsprechend anpassen (viel Handarbeit) und das bei jedem Container einzeln.

Unsinn. Die Dateien der Container behalten ihre Rechte, wenn Unbalance sie verschiebt. Die meisten Container haben eigene Rechte, die mit Unraid nichts zu tun haben. Die darf man gar nicht ändern. Das Skript was du benennst kenne ich auch nicht. Was soll das sein? Bliebe aber immer noch das Problem, dass der Docker-Dienst gelaufen ist, korrekt? Also du hast nicht Docker auf "Nein" gestellt, sondern nur die Container gestoppt? Ich denke mal schon. Ich verstehe nicht mal wo du Permission Errors siehst. Wie wäre es, wenn wir mal bei einem Container anfangen oder du mal irgendwas inhaltliches postest. zB Screenshots. Ganz grundlegend würde ich Docker beenden und das docker.img löschen lassen. Danach schaust du über Shares > System rechts das Ordnersymbol ob das docker.img wirklich weg ist und wo eigentlich das system-Share liegt. Ist die LOCATION nur eine bestimmte Disk? Ok, dann weiter. Shares -> appdata rechts das Ordnersymbol. Sind alle Dateien aus appdata auf einer bestimmten Disk oder verteilt? Falls sie verteilt sind: Kannst du ausschließen, dass es Dopplungen gibt? Also eine Datei auf Disk1 UND Disk2 liegen? Das darf auf keinen Fall sein. Prüfe so viele Dateien wie möglich. Ist dagegen LOCATION nur eine Disk. Wie sind die include-Disk-Einstellungen beim Share appdata. Darf appdata auf alle Disks schreiben oder nur auf ausgewählte? Sollten alle sein. Falls nein. Ändern und Array neu starten. Docker starten. Das erstellt nun ein neues docker.img. Jetzt Docker > Add Container und einen Container auswählen, der ohne Abhängigkeiten zu anderen Containern läuft. Wie sehen da die Pfade aus? Steht da überall /mnt/user oder sind gar Disk-Pfade hinterlegt wie /mnt/disk1 oder so? Wenn überall /mnt/user steht kannst du den Container starten. Läuft er? Wenn nein, warum nicht? Was sagen die Logs des Containers. Solange dieser eine Container nicht läuft, würde ich erst mal gar nicht weiter machen.

Die Datei ist wichtig und darf nicht einfach entfernt werden. In der Go-Datei wird die WebGUI geladen. Die kryptischen Infos deuten daraufhin, dass dein Stick kaputt ist oder zumindest irgendwas einfach nur Müll in die Go Datei geschrieben hat, was aber eigentlich nicht passiert, weil die Go-Datei von keinem mir bekannten Prozess geändert wird. Original-Inhalt der Go-Datei: #!/bin/bash # ------------------------------------------------- # Start the Management Utility # ------------------------------------------------- /usr/local/sbin/emhttp & Hast du ein Backup vom Stick? Spontan hätte ich gesagt neuen Stick installieren und aus dem Backup das Config-Verzeichnis wiederherstellen.

Open the containers console and check the last entries: tail -n200 /var/log/letsencrypt/letsencrypt.log

Wenn die Container während dem Verschieben liefen, ist das auch nicht verwunderlich. Hatte das keiner gesagt, dass man die Container erstmal stoppen muss? Ist natürlich Scheiße. Hast du Backups von appdata? Das Problem ist nämlich unter anderem, dass du 2x verschoben hast. Damit hast du 100pro die ersten Originaldateien mit korrupten überschrieben, denn wenn der Container weiter in eine offene Datei schreibt, die bereits verschoben wurde, verbleibt auf der Quelle eine korrupte Mini-Datei. Deine Tests kannst du dir daher sparen. Die erkennen keine korrupten oder falsch positionierten Dateien. Du musst dir das so vorstellen, dass du quasi während Windows lief die komplette C Platte auf Platte D verschoben hast. Das überlebt kein laufendes System. Unbalance nutzt rsync. Allerdings muss die Option "-H" gesetzt sein. Kann gut sein, dass das bei Unbalance nicht gemacht wird.

Installiere die offiziellen Container, dann brauchst du auch keine Terminal Kommandos ausführen. In der Fehlermeldung steht übrigens eine andere IP als du angegeben hast.

Willst du permanent auf die NVMe zugreifen? Wenn nein, dann ist das alles irrelevant. Die geht ja sofort in den Tiefschlaf, wenn nichts übertragen wird. Ich würde viel eher auf den Preis schauen. Und gerade die überteuerten Red Produkte fallen da direkt raus.

Das geht auch mit "normaler" Hardware, aber Verfügbarkeit ist das Problem. Wenn mein Board sterben sollte, wüsste ich gar nicht was ich kaufen sollte.

@ich777 evtl eine wichtige Info für dich

Ist die Parity eben einen Tag kaputt und wird neu aufgebaut. Klar, kann natürlich in die Hose gehen, aber da wären wir wieder beim Thema Backup. Kann ja schließlich genauso gut ein Blitz reinhauen oder irgendwas anderes die Daten zerlegen.