hawihoney

Gerne, kann man auch später noch in NullKomaNix ändern. Die XML Dateien der Container werden auf dem Stick gespeichert und können bei einer kompletten Neuinstallation des Docker-Subsystems durch Knopfdruck rekonstruiert werden. Das kommt natürlich auf die Verteilung und die Art Deiner Platten an. Docker-Subsystem, Container, KVM-Subsystem, VMs gehören auf das Schnellste im System. Das ist üblicherweise M.2 NVMe angeschlossen an PCIe, M.2 NVMe angeschlossen an SATA, SSD, Array - wie Du siehst in absteigender Reihenfolge. Es lohnt sich genau das zu kontrollieren. Du willst Plex mit seinen eigenen "trillionen" Dateien nur in Ausnahmefällen auf einer SSD oder gar auf dem Array. Das macht keinen Spaß. Ja, das ist der Trend. Ich gucke mir ein Video an und weiß wie etwas funktioniert ... Wenn man etwas nicht einer weiteren Person erklären kann, dann weiß man es nicht. Das ist ebenfalls von Oma

Meines Erachtens gehst Du falsch an das neue System heran. Fang doch mal einfach einfach an: Nimm Dir einen einfachen Container wie MakeMKV um zunächst das Docker Subsystem kennenzulernen. Fragen sind: Welcher Art soll die Speicherung des Docker Subsystems (docker.img) sein (BTRFS Image, XFS Image, Verzeichnis)? Wo legst Du diese Datei/Verzeichnis hin (Cache|Pool)? Stelle dieses Zielverzeichnis in den Docker Settings fest. Verändere bei der Installation des ersten Containers (MakeMKV) mal nichts. Kannst Du diesen installieren, liegt der Ordner dort wo Du wolltest (unter appdata), kommst Du mit der GUI auf den Container? Wenn Du dann damit vertraut bist, kannst Du weiter gehen ... Oma sagte immer: Bevor du den Bagger bekommst, lernst du erst mal schaufeln. Die Tendenz die ich allgemein in diesem Forum zu erkennen glaube ist, dass oftmals direkt mit dem Kompliziertesten, und dann auch noch mit Allem gleichzeitig, begonnen wird. Um bei Oma zu bleiben: Wer Gitarre spielen kann, kann nicht automatisch Klavier spielen. Proxmox ist die Gitarre, Unraid ist das Klavier (oder vice versa). Aber beides sind Musik-Instrumente .

My Unraid VMs have all host CPUs assigned (not isolated). It's perfectly balanced.

I'm running two Unraid VMs on an Unraid host since years. It's rock solid. Starting up and shutting down the whole system is a combination of manual and automatic tasks - but when do you shutdown a server.

Ich denke, dass bei Dir etwas völlig falsch läuft. Ich nutze seit Jahren den stabilen "linuxserver/nextcloud" Container. Die Version die hier läuft lautet: Diese Nextcloud Instanz nutzt den ebenfalls von Linuxserver.IO stammenden stabilen "linuxserver/mariadb" Container. Dessen Version lautet: root@aedf3e4660c9:/# mysqld --version mysqld Ver 10.5.12-MariaDB-log for Linux on x86_64 (MariaDB Server) Bevor Du auf der Kommandozeile jonglierst würde ich einfach beide Container von Grunde auf neu installieren. Ich verwendete seinerzeit die anhängende Installationsanleitung. Ich ziehe solche Dokumente grundsätzlich als PDF - kann also nicht sagen, ob es diese Anleitung in dieser Form noch im Web gibt. Achte bitte darauf, dass es im Zuge von MariaDB um zwei User/Passwörter geht (Admin und User) und das Nextcloud zwei Verzeichnisse benötigt - das übliche config/appdata Verzeichnis sowie ein zusätzliches Datenverzeichnis. Verwechsle das jeweils nicht. Installing Nextcloud On Unraid With LetsEncrypt Reverse Proxy.pdf

Das habe ich nie ausprobiert. Vielleicht haben chmod/chown eine vorherige Prüfung auf die gewünschten Werte eingebaut - ich weiß es aber nicht. Ich habe zu oft Tools gesehen die alles überklatschen was ohnehin vorhanden ist. Wenn mir das jemand mal zeigt, ändere ich das sofort. Mich würde unnötiges Überschreiben mit den dann zwangsläufig durchgeführten Schreibzugriffen ärgern. Aber wie gesagt, das habe ich nie hinterfragt. So arbeite ich halt immer, das werde ich in diesem Leben auch nicht mehr los

Klar, war nur Teil eines umfangreicheren Skripts. Teste die Befehle mal einzeln auf der Konsole.

Ich nehme eine einfache Variante in einem User-Script: find /mnt/disk17/Dokumente/ -type f -not -user nobody -exec chown nobody:users {} \; find /mnt/disk17/Dokumente/ -type d -not -user nobody -exec chown nobody:users {} \; find /mnt/disk17/Dokumente/ -type f -not -perm 666 -exec chmod 666 {} \; find /mnt/disk17/Dokumente/ -type d -not -perm 777 -exec chmod 777 {} \;

Dauerbetrieb ist unter Unraid aber nicht gleich Dauerbetrieb. Der Stick steckt zwar drin, wird aber nach dem Booten nur noch bei Änderungen an der Konfiguration beschrieben. Du archivierst alte Diagnostics? Warum?

Welche von denen nutzt Du als Unraid Sticks? unitedCONTRAST II wegen USB 2.0? Oder tatsächlich pSLC für USB 3.1? In fast 13 Jahren Unraid ist mir erst ein USB Stick abgeraucht, meistens lässt sich ein Problem mit einem Disk Check beheben. Wäre aber trotzdem nett zu wissen was empfehlenswert ist.

Alles klar. War nur vorsichtshalber. Man kennt ja nicht den Wissensstand der Benutzer.

Du solltest den Plex-Papierkorb erst dann löschen, wenn nach einer Umstellung von User-Shares auf Disk-Shares, ein Aktualisieren der betreffenden Bibliothek abgeschlossen ist. Sonst gehen Abspielstatistiken, etc. verloren. Also: Erst Ordner in einer Plex-Bibliothek von "user" nach "diskx" ändern. Dann "Mediathek-Dateien einlesen" für die betreffende Bibliothek starten. Anschließend exemplarisch an einem Inhalt dieser Bibliothek kontrollieren ob er als Duplikat mit einer "2" markiert wurde --> Erfolg. Jetzt kannst Du den Plex Papierkorb für diese Bibliothek leeren. Achtung: "Papierkorb leeren" nur machen wenn Du nicht zusätzlich Inhalte von USB-Devices, etc. über Plex abspielst.

Ich verkaufe derzeit meine ganzen alten Festplatten bei eBay. Das sind hauptsächlich 2TB und 3TB Platten aber auch ein paar andere. Hersteller sind HGST, Seagate, WD und Toshiba. Alle Platten stammen aus meinen Servern, wurden erfolgreich mit preclear gelöscht und enthalten somit die Unraid Signatur. Das bedeutet, dass diese Festplatten sofort in ein Unraid Array integriert werden können. Der zeitraubende Löschprozess kann somit entfallen. In den Details der Auktionen findet Ihr relevante SMART Werte und die Dauer und Geschwindigkeit des Löschprozesses. Letzteres gibt ein gutes Bild der sequentiellen Schreibgeschwindigkeit. Ich bin noch dabei weitere Platten einzustellen, schaut also bei Interesse einfach mal rein. Sucht über die erweiterte Suche nach dem Verkäufer: honey-auctions

If a disk is precleared with the plugin and the "Unraid signature" is applied to the disk, can I put this disk in other Operating Systems as well without any problems? E.g. can I format a precleared disk with Unraid signature on a Windows system without removing that signature first? Thanks in advance.

Sehe ich das richtig: Kernel Oops in strcmp ausgelöst durch btrfs? Starte mal den Server im Maintenance Mode (ohne Plugins wie cache-dirs, etc.) und ohne den Docker Compose Aufruf im go file. Danach sollte das Eingrenzen des Fehlers einfacher werden.

Das war der Fehler. Man klickt eigentlich nie auf Formatieren - außer beim Hinzufügen einer weiteren Platte:

Weil je nach Auslastung die Informationen nicht mehr im Cache liegen. Die zusätzliche Verwaltungsebene FUSE (!!!) muss irgendwo zwischenspeichern, was alles auf dem User-Share und dessen zugeordneten Platten liegt während in meinem Fall die exakte Platte in der sqlite Tabelle media_parts Spalte file von Plex direkt vermerkt ist. Ich rede von großen Installationen bzw. begrenzten Ressourcen bei denen das passieren kann. Bei mir war es über ein Jahr so, bis ich in Plex auf Disk Shares umgestellt habe. Den Effekt den ich persönlich erfahren hatte ist: Ich klickte in Plex auf Content. Danach starteten nacheinander alle Platten des in Plex hinterlegten User-Shares. Bei damals 24 Platten im User Share dauerte das ca. 3-4 Minuten bis der Content tatsächlich startete. Damals hatte ich dann auf Disk-Shares umgestellt und alles war gut - maximal 15 Sekunden bis die eine, direkt angesprochene Platte gestartet war. Plex ist übrigens in so einem Fall des Verschiebens oder Umhängens clever genug und tauscht nur den Wert in der Spalte file in der Tabelle media_parts aus. Der Rest bleibt unverändert. Lass uns aufhören, wir drehen uns im Kreis.

Süß Irgendjemand muss am Ende des Tages entscheiden, wo die tatsächliche Adresse des Content liegt. In meinem Fall (Disk-Shares) fragt Plex nach: /mnt/disk1/Bilder/yyyy/yyyy xyz/yyyymmdd hhmmss abc.jpg Im alternativen Fall (User-Shares) fragt Plex nach: /mnt/user/Bilder/yyyy/yyyy xyz/yyyymmdd hhmmss abc.jpg Wir sind uns doch einig, dass im letzteren Fall eine weitere Verwaltungsebene zwischengeschaltet ist, oder? Und wenn wir uns darüber einig sind, dann könnte es doch sein, dass wir uns darüber einigen könnten, dass diese Verwaltungsebene zusätzliche Resourcen benötigt. Und an dieser Stelle einfach weiter denken Wie gesagt, wir reden nicht über - ahem - 8 Platten. Wir reden über mächtig viel Content. Da gibt es zwei Varianten und beide wurden in diesem Thread angesprochen.

Welche Platte fährt denn Plex im User-Share hoch? Nein, so funktioniert das nicht. Plex greift auf Content im User-Share zu und wenn Unraid die Verwaltungsdaten der zugehörigen Platte des Contents im Cache hat, dann klappt der unmittelbare Zugriff. Sonst nicht. Warum gibt es denn sonst diese Cache Plugins. Ist aber auch egal. Ich habe das selbst erfahren müssen und erst die Umstellung auf Disk-Shares in Plex hat Abhilfe geschafft. BTW, es geht um über 400 TB hier.

Weil Format nur die Verwaltungsinformationen für ein leeres Dateisystem schreibt. Wie machst Du das denn jetzt? Array inkl. dieser Platte gestartet oder nicht? Ich befürchte, dass Du alles machst ohne die Hintergründe von Unraid zu beachten. Dann wird es noch viele weitere Probleme geben.

Du hast das System mit den Parity Platten nicht verstanden. Darauf befinden sich die kumulierten Bits aller Array Platten. Da kann man nix runter kopieren. Parity Platten haben noch nicht mal ein Dateisystem. Wenn der letzte von Dir oben beschriebene Schritt die Datenwiederherstellung war, dann wurde genau das, was zuvor auf der Platte war, rekonstruiert. Und das war dann wohl eine frisch formatierte Platte. Wie gesagt, es sollte vorsichtshalber noch eine weitere Person hier rein schauen. Ich bin mir aber ziemlich sicher ...

Wie gesagt, dass hängt am RAM-Ausbau, der Menge des Content, der Anzahl der Platten im User-Share und dem Cache-Status. Bei kleineren Systemen mag das klappen, bei mir war der Schwellenwert schon vor Jahren überschritten:

Ich denke, dass nur die Zuordnung "Cache=Nur|Only" im Share "Downloads" das Problem ist. Alles landet auf dem 250 GB Cache und wird niemals ins Array geschrieben. Meiner Meinung nach muss er nur beim Share "Cache=Ja|Yes" setzen und den Mover anschmeißen, oder?

Ich fürchte Du hast durch das Formatieren die Platte leer gemacht. Gleichzeitig wurde durch das Formatieren die Parity aktualisiert. Bei der Datenwiederherstellung wurde das Ergebnis des Formatierens wieder zurückgespielt. Hast Du ein Backup der Daten? Wenn ja, kopiere es einfach wieder auf die Platte. Wenn nein, dann muss jemand anderes hier reinspringen. Meiner Meinung nach wurde die Platte beim Formatieren gecleared und anschließend erst formatiert. Kann das jemand bestätigen?

Plex spricht dann halt gezielt die eine Platte an und nicht einen User-Share. Je nach RAM-Ausbau, und RAM-Cache Status, kann Unraid bei Nutzung des User-Shares gezwungen sein mehrere Platten hochzufahren. Das entfällt dann komplett. Es gibt hier sogar Disk-Caching Plugins um das Problem zu umgehen. Diese Plugins lesen dann regelmäßig alle Platten um den RAM-Cache zu füllen. Das braucht man bei Nutzung von Disk-Shares in Plex überhaupt nicht. So sieht das bei mir aus: