hawihoney

Das hatte ich oben geschrieben. Unraid müsste eine zweite Binär Operation nachschieben und könnte das falsche Bit ermitteln. Die Bit Position ist dann die Position der Disk im Array. So weit die Theorie. Allerdings kenne ich nicht die exakte Vorgehensweise. Arbeitet Unraid tatsächlich mit 32 Bit (meiner Meinung nach der Grund für das Plattenlimit) in einer Operation oder mit irgendeiner mir unbekannten Bulk-Operation (z.B. sektorweise).

Bei mir kracht Unraid nie runter. Und Verzögerungen im Shutdown habe ich bisher immer gefunden (100% offene Sessions). Beide Male war es ein wackelnder HBA - das erste mal nach dem Eintreffen meines zweiten Servers aus den USA (von LimeTech) und das zweite Mal nach einem Umzug (2009). Ich fummele halt nicht an funktionierenden Systemen rum. Müsste eigentlich mal einen BIOS Update machen (bei einem Reboot fehlt immer die selbe NVMe, bei einem Shutdown und Reboot nicht). Den Update schiebe ich wahrscheinlich auf ewig vor mir her. Nein. Ich habe einfach alle Dateien die rund um den Sync Error erstellt bzw. geändert wurden geprüft. Es waren beim ersten Mal 1408 Fehler (hat sich bei mir eingebrannt). Zu prüfen waren ziemlich viele Dateien. Das meiste war Content den ich auf Verdacht einfach wieder besorgt habe. Kenne ich nicht, aber ehrlich. So ein Tool ist pillepalle. Eine SQLite Db, ein Skript welches Hashes erzeugt, in der Db speichert und in ihr abgleicht. Ermittlung obsoleter Dateien. Speichern der Durchläufe. Und Pause/Resume bei Belastung des Systems. Ich hätte so ein Tool schon längst gebaut wenn ich es selbst nutzen würde. Darüber hinaus würde ich drei Monate Prüflauf oder so nicht wollen (Belastung, Strom, ...).

Du sagst es ja häufiger selbst: Software ist nicht so Deins. Du bist doch gut in Hardware. Hab gerade ein Problem mit meiner Klimaanlage. Ich hoffe Du verstehst meinen Vergleich. Habe mein ganzes Berufsleben Software gebaut. Aber das ist ein gigantisches Feld. Da spezialisiert man sich. Mit dem Auftauchen von OS/2 1.1 haben mein Partner und ich uns die Felder aufgeteilt (er Netzwerk und Kommunikation, ich Datenbanken und GUI. Davor haben wir beide alles betreut und entwickelt). Die Spezialisten sind tief im Kernel etc. Wenn die etwas nicht zur Verfügung stellen, dann kann der Rest der Entwickler nichts machen. Zudem bin nach wie vor der Meinung, dass die Ausgabe von Dateien und Ordnern beim Parity Check irrelevant ist. Heutzutage haben Dateisysteme Transaction-Logs (wie Datenbanken). Die reparieren sich bereits auf dieser Ebene selbst. Da die Parity kein Log pflegt, hat, wie ich oben schon schrieb, die "selbstheilende" Datenplatte Vorrang - das ist aber nur ein Grund von mehreren. Außerdem: Vermeide halt die vielen Crashes 😁 Das war nicht meine Frage. Du hättest gerne Ordner bzw. Dateien benannt. Wie Du siehst macht das meines Wissens kein Parity- bzw. Sync Tool. Was mag denn wohl der Grund sein? Setz bei Bedarf einfach Deine Hash-Tools ein. Hatte in nun 14 Jahren mit Unraid 2x Sync Errors - beide Male Hardware. Seit dem Rausschmiss von BTRFS gibts auch keine ausfallenden NVMes mehr bei mir. Spiel halt nicht so viel an den Kisten rum 😉 Nachtrag: Bei meinen Sync-Errors bin ich über das Datum der Dateien an die Kontrolle der Dateien gegangen.

Das habe ich auch nicht angedeutet. Nur wie Unraid das für jedes verwendete Dateisystem ermitteln kann, wird wohl nicht öffentlich zugänglich sein - denke ich mal. Ist auch nicht Unraids Aufgabe, ganz andere Layer sind da im Spiel. Ja, durch die FS Entwickler. Wenn es aber keine Tools von denen gibt, dann steht man da. Wie ist das eigentlich bei den klassischen RAID Systemen. Schreiben die Ordner bzw. Dateien bei einem Fehler raus?

Dual Parity. P+Q. Nennt man so. Nachtrag zur Recherche: Zunächst einmal ist das vom Dateisystem abhängig - die Du ja im Array fröhlich mixen kannst. Dann wird ja nur festgestellt, dass der kalkulierte Wert der Datenplatten nicht zur Parity passt. Datenplatten haben dabei Vorrang, also wird die Parity überschrieben. Willst Du dann wissen was sich an der Stelle geändert hat, müsste Unraid mit einer weiteren Binäroperation feststellen, welche der Datenplatten abweicht. Und dann springt noch die Verschlüsselung in den Weg. Das ist Forensik. Würde mich wundern wenn die Methode für jedes Dateisystem irgendwo frei verfügbar ist.

Offensichtlich landen Deine Daten in Deiner Windows VM (in der Image Datei). Plex erzeugt trillionen Metadaten-Dateien. Wenn die alle in der VM landen dann wäre das unausweichlich. Guck Mal wie groß die Image Datei ist und der Füllstand.

Für appdata/domains --> Cache Prefer Für normale Daten --> Cache yes Du nutzt für Deine Container zwei verschiedene Angaben durcheinander (/mnt/cache vs. /mnt/user). Das würde ich konsequent entweder auf eines oder das andere setzen. Traditionell /mnt/user. Ist der Mover bei Dir aktiviert?

Hä? Ich nutze 6.10.3. Ah, erst hieß es kaputt, jetzt heißt es per klick. Was kommt als nächstes? Es ist hier im Forum bestimmt ein dutzend mal beschrieben, wie man als Betreiber eines Unraid Servers den Conbee2 Stick in eine VM bekommt: Ausführen: ls -la /dev/serial/by-id/ In VM Konfiguration aufnehmen: <serial type='dev'> <source path='/dev/serial/by-id/usb-dresden_elektronik_ingenieurtechnik_GmbH_ConBee_II_********'/> <target type='usb-serial' port='1'> <model name='usb-serial'/> </target> <alias name='serial1'/> <address type='usb' bus='0' port='4'/> </serial> Fertig! So sieht das dann in der Home Assistant/Deconz Konfiguration aus und ist sofort einsatzbereit: Jetzt bin ich aber wirklich raus hier.

Nutzung von ungenutztem RAM für Verzeichnisstrukturen und Dateidetails bzw. -fragmenten macht Linux unter der Haube - und das sehr gut. In dem Sinne gibt es aus Linux Sicht kein ungenutztes RAM. Was Du nicht nutzt schnappt sich Linux und pagt lustig damit rum. Die paar GB sind wirklich nicht die Rede wert um damit etwas Zusätzliches anzufangen. Du kannst die tmp Deiner Container darauf umbiegen oder gleich ganze appdata Inhalte. Dann musst Du Dich aber selbst um das Synchronisieren kümmern. Mit RAM Disks, etc. habe ich seit dem letzten Jahrhundert nicht gearbeitet, da das Standard Ressourcen Handling einfach nur noch schwer zu toppen ist. Aber damals gab es auch RAM Kompressoren ... Linux und deren Ableger funktionieren am besten wenn wir Laien nicht daran rumfummeln. Ist so als pappst Du einen Spoiler an ein Neufahrzeug, welches während der Entwicklung tagelang im Windkanal war ...

Starte den Container einfach Mal neu. Zur Kontrolle Klick Mal neben dem "Host Path" in der Container Config auf Edit. Mach davon Mal Screenshot. Außerdem hast Du 2x Umask. Wieso? Einer kann bestimmt weg (Remove). @ich777 Wieso gibt es Umask und Umask Value?

Geh mal in Nextcloud in die Einstellungen und dort auf Übersicht. Was steht unter Version?

Komisch, merke ich nicht. Reiche drei verschiedene USB Devices an drei verschiedene VMs durch. Z.B. Conbee2 an Home Assistant, SSDs an Windows und die Unraid Lizenz-Sticks an Unraid-VMs. Da machst Du vermutlich etwas falsch. Klingt konstruiert: Speichere diese Daten dann halt nicht ins Array. Speichere auf einen Single Device Pool. Meines Erachtens eine Fehlkonfiguration. Lass uns aufhören. Du befindest Dich hier im Unraid Forum, Du fängst mich nicht mit Proxmox ein - egal wie Du Dich bemühst

Schweb mal mit der Maus über das gelbe Warnsignal. Was steht da?

Genau. Das meinte ich mit "Container Mapping /mnt --> /mnt". In Deinen Ausführungen geht es um das Ausführen eines Skripts mit dem Starten eines neuen oder "geparkten" Containers. Ich dachte in meiner naiven Denke an einen Python Container der wie alle anderen Container installiert ist (z.B. MKVToolNix) und gestartet bleibt. Und dessen Inneres ich dann nutzen kann - quasi als isoliertes Installationsverzeichnis. Und mit "docker exec" nutze ich das dann. So wie ich mir die MKVToolNix, MakeMKV und Plex Container zunutze mache. Das ist aus einer "include" meiner Python Skripte. Genau das würde ich auch gerne mit Python selbst erreichen: #### Container names (required) ################### plex_container = "plex" makemkv_container = "MakeMKV" mkvtoolnix_container = "MKVToolNix" #### Container tools (do not edit) ##### plex_media_scanner = f"docker exec {plex_container} /usr/lib/plexmediaserver/Plex\\ Media\\ Scanner" makemkvcon = f"docker exec {makemkv_container} env HOME=/config /opt/makemkv/bin/makemkvcon" mkvinfo = f"docker exec {mkvtoolnix_container} /usr/bin/mkvinfo" mkvpropedit = f"docker exec {mkvtoolnix_container} /usr/bin/mkvpropedit" ... command = f'{mkvpropedit} "{video_media_part_file}"{info}'

Hab im Web etwas über einen benötigten User 472 gelesen ... Ich hatte beim Umstieg auf 6.10.3 keine Berechtigungsprobleme festgestellt. Auch nicht beim Erstellen neuer Container, die ich ab und an mal aus Spaß installiere. Man muss auch mal Glück haben ...

Direkt im ersten Schritt habe ich Grafana installiert. Geändert habe ich nur die Host Url auf "http://192.168.178.35" und das appdata Verzeichnis auf meine übliche Ablage "/mnt/pool_nvme/system/appdata/grafana". Direkt nach der problemlosen Einrichtung habe ich den Container gestartet und dann kamen Permission Fehler. Grafana kann eigene Verzeichnisse nicht anlegen. root@localhost:# /usr/local/emhttp/plugins/dynamix.docker.manager/scripts/docker run -d --name='Grafana' --net='bridge' -e TZ="Europe/Berlin" -e HOST_OS="Unraid" -e HOST_HOSTNAME="Tower" -e HOST_CONTAINERNAME="Grafana" -e 'GF_SERVER_ROOT_URL'='http://192.168.178.35' -e 'GF_SECURITY_ADMIN_PASSWORD'='admin' -l net.unraid.docker.managed=dockerman -l net.unraid.docker.webui='http://[IP]:[PORT:3000]/' -l net.unraid.docker.icon='https://github.com/atribe/unRAID-docker/raw/master/icons/grafana.png' -p '3000:3000/tcp' -v '/mnt/pool_nvme/system/appdata/grafana':'/var/lib/grafana':'rw' 'grafana/grafana' 51a2736fb787a548086c7990dcb1e03e7da7779e38e1848088ab40a3adfda970 The command finished successfully! Mit dem Laptop kann ich auch nicht aus dem Container Log kopieren. Irre. Muss einen Screenshot machen. Was ist denn bloß los in der IT? Wie auch immer: Da ich nicht migriere sondern neu installiere muss mich ein Doc doch nicht interessieren. Ganz ehrlich, schwache Leistung der Grafana Erzeuger ... Wenn man danach googelt, dann finde ich tausende identische Fehler. Dazu im ersten Treffer eine überhebliche Antwort in deren Forum auf den Hinweis, dass deren Installations-Doc die notwendigen Rechte nicht erwähnt. Da mag ich mir nicht ausmalen was im Betrieb so alles auf einen zu kommt. Hab's wieder gelöscht. Kann nicht wichtig sein Sorry für die Verschwendung Deiner und meiner Zeit.

Ach so, sorry. Hab zwischenzeitlich wieder alles restlos gelöscht. Wenn es direkt im ersten Schritt schon Fehler gibt, dann gebe ich in letzter Zeit viel schneller auf als noch früher. Lebenszeit ist kostbar Vielen Dank für Deine Antwort.

@ich777 Habe gerade spaßeshalber versucht nach Deiner Anleitung das Ganze zu installieren: https://unraid.net/blog/prometheus Direkt nach dem Installieren von Grafana und dessen Start (Step #1) erhielt ich Permission Fehler. Diese habe ich noch nie beim installieren von Containern bekommen. Bevor ich mich jetzt auf die Suche mache, braucht es für diese Installation eine spezielle Umgebung? Grafana meckerte, es könne keine Verzeichnisse anlegen. Angegeben hatte ich /mnt/pool_nvme/system/appdata/grafana: root@Tower:/mnt/pool_nvme/system/appdata# ls -la total 0 drwxrwxrwx 11 root root 145 Jul 14 15:20 ./ drwxrwxrwx 6 root root 81 Dec 27 2021 ../ drwxr-xr-x 4 nobody users 28 Apr 7 16:55 MKVToolNix/ drwxr-xr-x 5 nobody users 115 Jul 12 09:50 MakeMKV/ drwxrwxrwx 8 nobody users 94 Sep 29 2021 SQLite/ drwxrwxrwx 6 nobody users 103 Jun 25 2021 mariadb/ drwxrwxrwx 11 nobody users 157 Jun 21 2021 nextcloud/ drwxrwx--- 9 nobody users 224 Feb 15 2021 nextcloud.data/ drwxrwxrwx 4 nobody users 163 Jul 14 02:00 nzbget/ drwxrwxrwx 5 nobody users 72 Jun 22 2021 plex/ drwxrwxrwx 14 nobody users 221 Jun 25 2021 swag/

Sieht geil aus, keine Frage. Dennoch hätte ich da mal eine Frage Die Frage ist nicht böse gemeint, mich interessiert es, denn ich nutze Home Assistant selbst, habe aber bisher den Server bewusst ausgespart. Home Assistant enthält bei mir ausschließlich Schalter, Sensoren, etc. die ich zum Gas-/Stromsparen (Steuerung Kälte, Wärme) oder für den Alarm (Wasser) benötige. Reine Auskunfts-Sensoren nutze ich nicht. Die zusätzlichen Tools wie Grafana, etc. ziehen die nicht selbst Strom? Ich weiß, das klingt jetzt dämlich, aber wenn in vielen Threads hier unbedingt noch 1-2 Watt aus den Systemen rausgekitzelt werden soll, wäre es dann nicht eher angebracht, auch bei der Software zu reduzieren? Wie gesagt, rein aus Interesse. Wenn Ihr das für Vernachlässigbar haltet, dann nichts wie her damit.

Bei all diesen Unterschieden, Stärken und Schwächen zwischen den verschiedenen Systemen, wird ganz gerne eines immer vergessen. Die Kernkomponente von Unraid - das ursprüngliche Killerargument - hat bis heute Bestand: Das Array. Packe einen Haufen unterschiedlicher (!) Platten in eine Zusammenstellung + sorge dafür, dass diese mit 1 bis 2 zusätzlichen Platten eine Ausfallsicherheit von 1 bis 2 Platten erhält + sorge dafür, dass jede der einzelnen Datenplatten ein eigenes Dateisystem pflegt, welches auch beim gleichzeitigen Ausfall von 3 oder mehr Platten, den Datenverlust in Grenzen hält + sorge dafür, dass immer nur eine Platte beim Lesen aktiv sein muss (Stromsparen!) + sorge dafür, dass maximal 2 bis 3 Platten beim Schreiben aktiv sein müssen (Stromsparen!) Das ist das Angebot, dem ich bisher nicht widerstehen kann, und das mir bisher AFAIK kein anderes System bietet. Letzte Woche erhielt ich von meinem Stromanbieter eine saftige Preiserhöhung. Ehrlich, da können mir für meinen Einsatzzweck ZFS, BTRFS, etc gestohlen bleiben. Da nehme ich die 1/3 Performance von Unraid (beim Schreiben mit Parity) und kleinere Nickeligkeiten mit Freuden in Kauf. Und sollte irgendwann mal der erwartete Multiple Array Support in Unraid einziehen, dann werde ich die zusätzlichen virtualisierten Unraid Arrays vermutlich in meinen Unraid Virtualisierungs-Host übernehmen können und bin in nicht mal 5 Minuten wieder in der Spur und kann weitere xx Watt für die dann überflüssigen HBAs einsparen (plus zwei nicht mehr benötigte VMs). Natürlich ist mir klar, dass andere Personen andere Anforderungen haben. Aber gerade in der heutigen Zeit - und meiner persönlichen Meinung nach haben die Probleme noch nicht mal richtig begonnen - wird das Unraid Array nicht so schnell seine Bedeutung verlieren. Nur meine 0,02 Euro.

Danke für Deine Ausführungen. Nur am Rande: Ich arbeite intensiv mit der Plex Web API (Beispiele): https://support.plex.tv/articles/201638786-plex-media-server-url-commands/ Wenn ich das mit Bash machen soll - ui ui.

Klar, das kenne ich. Das Problem ist aber, dass irgendein Paket andere Pakete bzw. das OS himmeln kann. Oder vice versa, durch einen Update des OS werden Pakete ausgehebelt. Ich würde gerne unter allen Umständen vermeiden, dass mir so etwas wie Anfang dieser Woche noch einmal passiert. Ganz eliminieren kann ich es nicht, denn Unassigned Devices, etc sind nahezu unverzichtbar und mit sehr vielen eigenen Paketen extrem nah am System. Aber alles was geht, will ich jetzt vom OS isolieren. Und da kam mir Docker in den Sinn. Ich hatte gerade einen notwendigen Disk-Rebuild (24 Stunden) gestartet, da habe ich bemerkt, dass ein gerade zuvor durchgeführter UD-Preclear Update (11.07.) alle meine User Skripte behinderte. Die liefen nicht mehr. Und on top war dann noch gleich ein Fehler in UD selbst am 04.07. reingerutscht, der dann auch noch einige Skripte, die zumindest auf der Konsole liefen, ebenfalls behinderte. Gut ich hatte die Fehler in beiden Plugins sofort gemeldet, aber das dauert halt seine Zeit. Für knapp 24 Stunden konnte ich nix machen, nix lief. Nur ein Reboot nach 24 Stunden half. Mittlerweile frage ich mich, warum man das Plugin System nicht mit einer Rollback Funktion versieht ... und solange es das nicht gibt würde ich gerne das eigentliche OS mehr abschotten.

Ich denke, dass Du die Anleitung (Unraid VM unter Proxmox) dann besser im Proxmox Forum veröffentlichst ... Es gibt AFAIK nur zwei Gründe um eine Unraid VM unter Unraid zu erstellen: 1. Test-/Spiel-Umgebung, 2. mehr Platten als die Unraid Pro-Lizenz in einem Array zulässt. Und das funktioniert beides einwandfrei. Das "Problem" mit dem Herunterfahren ist doch kein wirkliches Problem. Warum sollte ich einen Server/ein NAS dauernd runterfahren? Wenn es keine Updates (Software/Hardware) gäbe würde mein Server ewig durchlaufen. Das ist meines Wissens die Zielgruppe:

Kannst Du das denn nicht auf die /dev(disk/by-id Syntax ändern? Ich muss gestehen, dass ich in bash ein absoluter Stümper bin. Da gibt es erheblich bessere als mich. Bin eher in Hochsprachen unterwegs. Als faule Socke hätte ich mir an Deiner Stelle die 20 disk/by-ids mit ls ausgeben lassen, mit einem Makro mit dem smartctl Prefix versehen und in ein User Script gepackt. --> smartctl -s wcache-sct,on,p /dev/disk/by-id/ata-TOSHIBA_MG07ACA12TE_2210A02LF93G Müsste funktionieren.

Wofür brauche ich Guest Tools in einer Unraid VM? Kenne ich nicht, nie vermisst, brauche ich also nicht Das Herunterfahren der VM habe ich noch nie über den Haupt-Rechner gemacht. Als ich das aufgebaut hatte, da hieß es immer "Die VMs selbst ordentlich runterfahren - das braucht extrem lange". Und so ist es. Und so mache ich es seit Anfang an - immer über die GUI der VM runterfahren. Das ist der Ablauf bei mir. Deshalb fahre ich ungern runter: Stoppen ======= - Plex Container stoppen - Auf Hauptrechner und beiden VMs mit User Skripten die gegenseitigen Disk-Mounts runterfahren (alle drei Rechner haben Zugriff auf alle Disks der anderen) - VM01 stoppen (Kontrolle, Configuration valid) - VM02 stoppen (dto.) - VM01 herunterfahren (warten auf Anzeige power off) - VM02 herunterfahren (warten auf Anzeige power off) - Kontrolle ob Hauptrechner beide VMs als gestoppt anzeigt - VM03 (Home Assistant) stoppen - Alle restlichen Container stoppen (Stop all) - Hauptrechner stoppen - Hauptrechner herunterfahren - Hauptrechner vom Strom trennen - Gehäuse VM01 vom Strom trennen - Gehäuse VM02 vom Strom trennen Starten ======= - Gehäuse VM02 anschalten - Gehäuse VM01 anschalten - Hauptrechner anschalten (alle Container außer Plex, MakeMKV und MKVToolNix starten automatisch, VM03 ebenso, warten) - VM01 starten (warten bis deren Unraid komplett gestartet wurde) - VM02 starten (warten bis deren Unraid komplett gestartet wurde) - Auf Hauptrechner und beiden VMs mit User Skripten die gegenseitigen Disk-Mounts hochfahren (alle drei Rechner haben Zugriff auf alle Disks der anderen) - Plex, MakeMKV und MKVToolNix starten Das Herunterfahren des Hauptrechners ist eigentlich nie notwendig (außer in einem Update von Unassigned Devices Preclear werden falsche Binaries ausgetauscht - wie diese Woche geschehen), Plattentausch geht bei dieser Backplane auch ohne komplettes Herunterfahren. Das gilt übrigens auch für die Unraid VMs. Zum Plattentausch muss ich diese VM nur stoppen (nicht herunterfahren), Platte tauschen, Array starten. Das wars.