mgutt

Appdata sollte kein SMB Share sein. Zum Bearbeiten von Dateien bietet sich das File Manager Plugin an.

Fast Boot deaktiviert? Ist die iGPU im BIOS als primäre GPU ausgewählt?

Smarte Steckdose schon bestellt? 😅

Dh nach der Fehlermeldung wurde der Key aktualisiert? Weil hier wird klar gesagt, dass das durch eine korrupte Keydatei kommt: https://forums.unraid.net/topic/116171-solved-unraid-emhttpd-error-get_key_info-579-invalid-argument-help（已解决）/?do=findComment&comment=1055682 Die billigen Kingston SSDs machen gerne mal Probleme in Linux. Wobei jetzt in den Logs nicht zu erkennen war Interessant, dass die bei dir läuft. Bei mir ging die nicht. Ich würde die auf jeden Fall testweise rauswerfen. Der verbaute JMB585 Controller reagiert empfindlich auf powertop. Nutzt du das?

Dann ist er doch stromlos 😉 Hier und da wird vielleicht noch WoL versorgt, aber der Rest wie CPU, PCIe Slots usw ist komplett stromlos, was wir erreichen wollen. Anders wäre es bei einem Neustart. Da bleibt die Stromversorgung des Boards durchgehend erhalten.

Welchen Einfluss hat das auf den Kopiervorgang: sysctl vm.dirty_ratio=80 Dadurch wird dein RAM Schreibcache auf 80% des freien RAM vergrößert. Verfällt nach einem Neustart oder so wieder auf Standard ändern: sysctl vm.dirty_ratio=20

Spielt innerhalb von unRAID Einstellungen keine Rolle. Eher wenn man bestimmte Terminalbefehle verwendet. Zb würde ein "rsync /foo/ /bar/" den Ordner foo unterhalb von bar erstellen, während "rsync /foo/ /bar" nur den Inhalt der Ordner synchronisiert. Oder sagen wir man kopiert eine Datei mit "cp /foo/file /bar" und der Ordner "bar' existiert nicht. Dann würde er die Datei "bar" erstellen, welche die Kopie von "file" ist. Bei "cp /foo/file /bar/" gäbe es dagegen eine Fehlermeldung, dass der Zielordner nicht existiert. Also kommt tatsächlich auf das jeweilige Kommando an.

Naja, Dateisystem ist halt Fritte. Reparatur versuchen oder auch btrfs restore auf euren andere Platte, wenn du die Daten zumindest teilweise retten willst. Habe ich eigentlich schon gesagt, dass ich BTRFS nicht mag ^^

Ich wollte das Ergebnis haben ^^

Ja, passiert nach jedem Booten. Zeit ist falsch, er holt sich die Zeit vom NTP Server und korrigiert sie. Mich wundert, dass die Karte überhaupt funktioniert. Bei meinem letzten Test bootete mein Board nicht damit. Das klingt komisch. Er hat irgendein Problem deinen Key zu laden oder so. Stick kaputt?

Dann wird es 1x ausgeführt und das war es. Du musst einen Zeitplan einstellen

Doch das geht als Device und dann den Pfad /dev/Blabla 1:1 durchgeben Mein Home Assistant greift zb über /dev/ttyACM0 auf den ZigBee Stick zu. So sollte man zwei Pfade sehen können: ls -go /dev/serial/by-id Man kann sowohl /dev/bla oder /dev/serial/by-id/bla nehmen. Letzterer geht auch nach Umstecken auf eine andere Buchse, kann sich aber bei Firmware Updates des Sticks evtl ändern. Der erste kann sich bei jedem Booten ändern, wenn mehrere Sticks eingesteckt sind. Hat also alles Vor- und Nachteile.

Jo. Da /dev/nvme... nicht mehr da ist, gibt es keinen anderen Weg. Du solltest dir auch mal Gedanken über Backups machen. Siehe zb das VM Backup Plugin oder mein rsync incremental Script.

Installiere dir mal das Script: Außerdem Tools > Syslog und nur Errors und nur Warnings sichten. Liste auch mal deine Hardware auf.

Wie wäre es mit AdGuard Home? Der läuft meine ich in Bridge.

Der Server muss stromlos gemacht werden. Die NVMe sind komplett weg. Eventuell ist der Pool dann sogar ohne Reparatur wieder da. Scrub sollte man aber in jedem Fall machen. Vorher aber bitte syslogs runterladen und syslog mirror auf USB aktivieren. Du musst herausfinden wann die ersten Fehler waren und warum die NVMe verloren gegangen sind.

Jo ist so. Deswegen teste ich immer mit "rsync --dry-run /foo/ /bar" und dann mache ich "rsync /foo/ /bar & disown". So laufen Prozesse im Hintergrund.

Dann darf keine Key File auf dem Stick sein. Dann poppt das mit der URL doch automatisch auf?!

Bei DNS Anfragen? Da bekommst du vermutlich nicht mal 0.1 Mbit/s zusammen.

Wenn du nur eine Parität hast, hast du verloren, da die erste Disk nun nicht mehr wiederhergestellt werden kann. Denkbare Notlösung wäre jetzt alle Daten runterzukopieren, soweit das eben möglich ist. Wenn du Glück hast, ist die Disk an einer Stelle defekt, wo gar keine relevanten Dateien liegen.

Sicher dass man beides machen muss?! Normal hat man ja einen Key oder eine URL.

Ne das ist irgendein Flachbandkabel von Lenovo.

Der Vorgänger vom M920x, der M910x, hat übrigens auch zwei NVMe Slots, PCIe Slot und SATA, wobei bei dieser Kleinanzeige kein Kabel für SATA dabei war?! https://www.ebay-kleinanzeigen.de/s-anzeige/lenovo-tiny-m910x-i7-7700-cpu-32gb-ram-512gb-m-2-ssd-win10-/2279108288-228-2161 Der noch ältere Vorgänger, der M900x hatte nur Platz für eine M.2. Also ich denke noch ältere Modelle lohnen sich nicht zu kaufen.

Script is fixed. Released version 1.4 in the first post.

Das nützt nur eben Null, wenn der Intervall zB auf alle 2 Wochen steht und das erst 2 Wochen nach dem Crash durchgeführt wird. Ich halte auch rein gar nichts davon einen scrub ohne Reporting auszuführen. Dann findet scrub zwar Fehler, aber wissen tut man trotzdem nichts davon. scrub ist die Reparatur. Dazu müsste ich tatsächlich mal solche syslog-Einträge sehen. Am Ende ist mein Skript ja nur ein einfache Wort-Suche. Ergänzt man eben das entsprechende Wort.