hawihoney

Dann solltest Du diesen Stick in der VM XML entweder als Vendor:Product oder Bus:Device manuell eintragen. Sicher, dass der Stick vom Unraid Host nicht anderweitig verwendet wird? Hierzu gibt es dutzende Beispiele im Forum. Ich habe vor ein paar Jahren einen MischMasch aus diesen beiden Links verwendet: https://www.linuxserver.io/blog/2015-12-14-creating-an-unraid-virtual-machine-to-run-on-an-unraid-host https://wiki.unraid.net/Manual/VM_Guest_Support#Unraid_as_a_VM Ist ganz einfach. Sobald die VM vom Stick gebootet werden kann, läuft die Unraid VM.

Vielen Dank für Deine Antwort. Ich dachte eigentlich, dass der rclone Container noch einen zusätzlichen Benefit gegenüber dem Plugin hat (z.B. automatische Einrichtung in CLI und GUI an Hand der übergebenen Variablen). Im Moment erscheint mir der Mehrwert bei diesem speziellen Container eher - ähm - rudimentär. Letztendlich habe ich bis auf wenige systemnahe Plugins alles auf Docker Container umgestellt weil ich das Gekasper mit NERD/DEV Plugin satt war - die jetzt ohnehin nicht mehr empfohlen sind. Ich warte noch etwas. Vielleicht kann mich noch jemand aufs Pferd hieven. So schnell gebe ich nicht auf

Ich hoffe jemand kann mir mit dem o.g. helfen. Ich nutze den binhex-rclone Container und verstehe einfach nicht was der von mir will. Bevor ich noch einen weiteren Tag mit "Spielen" vergeude frage ich vorsichtshalber mal hier Ich habe u.a. die folgenden Einstellungen vorgenommen: In der Container Console erscheint nun der Root-Folder /media der auf /mnt/disk17 gemappt ist. So weit so gut. Warum ich aber nun RCLONE_REMOTE_NAME angeben muss ist schon mal Frage #1. Dieser Container erzeugt keine rclone.conf. Das muss man später per Konsolenbefehlen selbst machen. Wieso also diese Variable? Frage #2 bezieht sich dann gleich auf RCLONE_MEDIA_SHARES. Mit den Shares wird meines Wissens im Container nirgendwo etwas gemacht. Wofür gibt man die dort an? Nachdem ich einige Zeit verkaspert habe um eine rclone.conf auf meinem Headless Server zu erzeugen (über einen Windows Rechner auf dem man die Datei erzeugt) habe ich die GUI aufgerufen. Dort gibt es nun mein "remote" aus der Variable RCLONE_REMOTE_NAME. Aber sonst nix. Ich habe nun mal spaßeshalber auf der Konsole einen eigenen Befehl ausgeführt. Das klappt auch. Aber warum habe ich nun diese ganzen Variablen ausgefüllt? Wo sind nun die drei MEDIA_SHARES abgeblieben? Warum habe ich die Richtung und die Art der Übertragung ausgefüllt wenn das nirgendwo erscheint? rclone sync /media/Dokumente/ remote:/Dokumente/ *NACHTRAG* Während der manuelle sync Befehl tausende Testdateien überträgt, zeigt das rclone Dashboard 0% Aktivität. Ist die GUI nur ein Fake bzw. nur eine Demo? Wo ist meine Gedankenfehler bzw. mein Brett vor dem Kopf? Vielen Dank.

Das verstehe ich nicht. Im BIOS taucht die Disk nicht auf. Und dann öffnest Du Diskpart und dort kannst Du sie bearbeiten? Wie geht denn so was? Fehler in der BIOS Anzeige? Welches Mainboard ist das?

Das hat nichts miteinander zu tun. Unraid prüft die Unraid Signatur im MBR auf der Platte. Wenn die nicht existiert, dann wird die Platte von Unraid ohnehin komplett überschrieben. Wipefs erstellt meines Wissens nämlich keine Signatur - nur Preclear macht das. Also wird eine neu hinzugefügte, mit Wipefs behandelte Platte, von Unraid komplett gecleared. Eine mit Wipefs behandelte Austauschplatte wird hingegen komplett gesynct und neue, erweiterte Bereiche werden gecleared. Ein Parity Mismatch kommt nicht durch das Hinzufügen/Austauschen einer Platte. Es sind die bestehenden Platten die eine Differenz aufweisen.

Früher ging das tatsächlich. Heute nicht mehr. Der Windows Fehlertext beschreibt das ziemlich genau. Hier noch in Deutsch:

Die Parity Platte(n) wurden angepasst. Deshalb gibt es keine Fehler mehr. Grundsätzlich hat die Daten-Festplatte immer Vorrang. Es wird nie beim Parity-Check auf eine Daten-Platte geschrieben (die technischen Ausnahmen wie das Schreiben auf Reserve-Sektoren lasse ich mal außen vor). Es wird immer nur auf der Parity-Platte korrigiert. Beim Schreiben auf das Parity Protected Array werden die Platten in einer zeitlichen Abfolge bedient. Gibt es eine Differenz, dann ist "höchstwahrscheinlich" die Daten-Platte korrekt beschrieben und die Parity-Platte noch nicht. Selbst beim Abbruch des Schreibens auf die Daten-Platte gibt es dort "Selbstheilungsmechanismen" wie Transaktions-Logs die beim nächsten Boot einen konsistenten Zustand erzeugen. Deshalb läuft das immer so ab und deshalb ist es genau so auch richtig. Die Daten-Platte hat immer Recht! In extrem seltenen Ausnahmen, die eher durch Hardware-Fehler zu erklären sind, können die Daten auf der Daten-Platte defekt sein. Aber das läßt sich mit Bordmitteln nicht klären.

Bin halt "Alte Schule": So wenig wie möglich installieren, auf das Wesentliche reduzieren, ... Den FileManager wird wohl in absehbare Zeit jeder installiert haben. Ggfs. muss man in ihm nur weitere Extensions wie *.YAML anschalten (config auf Flash). Dann kann der quasi fast alles.

Geht auch über das stinknormale Dynamix File Manager Plugin. Da muß nix installiert werden.

Das kann ich so genau nicht sagen. Ich habe für jeden Container ein passendes User-Skript und die laufen täglich. Da sich darunter eine ziemlich umfangreiche Plex Installation befindet, und die Gesamtauslastung des Caches bei über 250 GB liegt, denke ich, dass es so in der Größenordnung liegt. Die Laufzeiten der Skripte hatte ich mal protokolliert und dementsprechend getaktet. Der ganze Zinober startet jeden morgen um 04:00. Das letzte Skript startet dann um 07:20.

Beim letzten Update wurde "Credits Detection" von Plex eingeführt und sofort scharf gestellt. Ein einfacher Test wäre, dieses Feature testweise und übergangsweise zu deaktivieren: https://support.plex.tv/articles/credits-detection/

Ja, 2-stufig. Das erhöht die Verfügbarkeit. 19 Sekunden aufs Array und die Container laufen wieder. Vom Array gehts nach extern. Wie lange das dann dauert spielt keine Rolle mehr.

Zum Beispiel MariaDB und Nextcloud in einem User Script - 19 Sekunden heute morgen. Ist das ein Problem? docker stop nextcloud docker stop mariadb rsync -avPX --delete-during /mnt/pool_nvme/system/appdata/mariadb/ /mnt/disk17/Backup/Tower/system/appdata/mariadb/ rsync -avPX --delete-during /mnt/pool_nvme/system/appdata/nextcloud/ /mnt/disk17/Backup/Tower/system/appdata/nextcloud/ rsync -avPX --delete-during /mnt/pool_nvme/system/appdata/nextcloud.data/ /mnt/disk17/Backup/Tower/system/appdata/nextcloud.data/ docker start mariadb docker start nextcloud

Nur am Rande: Eine USB 2 Verlängerung kann in diesen Fällen helfen. https://www.amazon.de/gp/product/B00NH11R3I/

Im selben lokalen LAN?

Hängt gegebenfalls vom Container ab. Bei meinem Homeassistant Container geht das so: root@Tower:~# ls -go /dev/serial/by-id/ total 0 lrwxrwxrwx 1 13 Feb 9 12:21 usb-dresden_elektronik_ingenieurtechnik_GmbH_ConBee_II_XXXXXXXX-if00 -> ../../ttyACM0 Davon verwende ich diesen String: /dev/serial/by-id/usb-dresden_elektronik_ingenieurtechnik_GmbH_ConBee_II_XXXXXXXX-if00:/dev/ttyACM0 Hier wird das als Value eingetragen:

Alle modernen Dateisysteme arbeiten wie Datenbanken mit "Transaction Logs". Beim Hochfahren werden diese geprüft ob unvollständige Aktionen (z.B. durch einen Absturz) korrigiert werden müssen. Die Platten starten also immer, das macht jedes OS automatisch beim Start. Stell die Spin-Down Zeit auf eine geringe Zeit. Ich habe 15 Minuten eingestellt.

Aus Deinem Text kann ich nur erahnen, dass es sich um zwei verschiedene Platten handelt. Ist der Parity Sync selbstständig abgebrochen oder hast Du den abgebrochen? Wie auch immer. Es sind mindestens noch alle Daten vorhanden die nicht auf den beiden ausgefallenen Platten liegen - das ist der Unterschied zwischen klassischen RAID Systemen und Unraid. Bei klassischen RAID Systemen wäre jetzt alles weg. Guck einfach mal auf alle individuellen Platten. Vielleicht kannst Du ja noch vieles retten.

Ist das ein Pfad im Container? Wenn ja, dann hast Du vermutlich das komplette Wurzelverzeichnis aller User Shares von Unraid in den Container gemappt. /mnt/user/ -> /media/mnt/user/ Und wenn das korrekt ist, dann kannst Du jedem Unterordner von /mnt/user/ individuelle Cache Einstellungen vergeben, da es sich bei den direkten Unterordnern von /mnt/user/ um Unraid Shares handelt.

Wenn Du das passende Package hast, dann kannst Du das mit seinen Abhängigkeiten in /boot/extra/ packen.

Interessant. Es gibt eine iSerial (00E04C239987). Wundert mich.

Hatte meine erste Antwort gelöscht, hatte mich auf den Conbee Stick bezogen - was falsch war. Was kommt wenn Du folgendes eingibst: lsusb -D /dev/bus/usb/001/006 Steht da irgendwo eine iSerial?

Was ist denn drin? Entweder in der Unraid GUI gucken oder: ls -l /mnt/user/user

So ist es auch. Du hast aber die Dinge in einer falschen Reihenfolge gemacht. Das entnehme ich es jedenfalls der Historie hier. Um eine Platte auszutauschen muss man nix anderes machen als: - Array stoppen, Rechner runterfahren - alte Platte raus, neue Platte rein - Rechner starten - In Unraid GUI die neue Platte dem Slot der alten Platte zuweisen - Array starten mit Haken an "Ja, ich bestätige Replacement Disk" Alles andere sind in meinen Augen esoterische Schritte die das Handling unnötig aufbauschen und für Anfänger verkomplizieren. Preclear ist meiner persönlichen Meinung nach einfach nicht erforderlich. Unerfahrene Unraider preclearen, formatieren innerhalb Unassigned Devices und stecken die bereits formatierte Platte ins Array. Tja, und dann kommen Nachfragen, die bei der Standardprozedur nicht erscheinen. Preclear nutze ich persönlich nur noch zum Löschen von gebrauchten Platten vor dem Verkauf. Ich gehe gleich z.B. in den Keller und schraube eine neue Platte rein. Aus der Verpackung nehmen und gem. den Schritten oben werde ich vorgehen. Wie immer. Bei ca. 200 Festplatten in den Jahren war nicht eine DOA. Unraid precleared selbst - sofern nicht vorher schon geschehen - aber die Schritte werden einfach komplizierter für Unerfahrene durch das Preclear vorab.

1.) Gab es schon vor Deiner Aktion eine Disk3? 2.) Guck mal auf die Platte mit "ls -l /mnt/disk3". Was kommt?