hawihoney

Nur so am Rande: Überlass einfach dem Host die Zuordnung der CPUs. Gib jeder VM alle Kerne (CPU Pinning). Weise aber unter CPU Isolation nix zu. Einzelne 100% Kerne ist meist - nicht immer - ein SMB Problem. Wäre interessant zu sehen ob es IO-Wait ist oder eine tatsächliche Auslastung. Das kann man z.B. in htop sehen. Abgesehen davon: Ohne die Diagnostics kann man nix sehen.

Das syslog gibt nichts her. Lediglich eine Meldung erfordert Deinen Eingriff - aber das hat sicherlich nichts mit den "Hängern" zu tun: Diese Dateien solltest Du zusammenführen. Des weiteren gibt es SMART Errors z.B. "Reallocated_Sector_Ct=10" und "UDMA_CRC_Error_Count" auf Deinen Devices. Letzteres weist auf ein Verkabelungsproblem hin. Bei der Verwendung des root_shares in der smb_extra muss ich passen. Ob es dadurch Probleme geben könnte weiß ich nicht. Das Docker Image liegt auf Unassigned Devices während appdata auf dem Cache liegt. Ist das so gewollt? Cache ist ein Single Device BTRFS Pool. Hier bin ich persönlich "biased". Bei einem Single Device Pool würde ich immer XFS wählen. Das ist aber meine persönliche Einstellung im Gegensatz zu vielen anderen hier. Der Begriff "Hänger" impliziert, dass etwas nur hängt aber nicht abstürzt. Bitte genauer spezifizieren.

Kein Problem. Nein. Es geht um die globalen Anmeldedaten der Externen Speicher - sofern Du diese verwendest. nobody greift dann auf /Dokumente aus dem o.g. Beispiel zu und stellt diese Nextcloud zur Verfügung. Die Nextcloud-User die wiederum darauf zugreifen dürfen - nennen wie sie mal User1 und User2 - definiert man neben dem externen Speicher. Schau Dir einfach die Seite an. Dann wird das klar. Ich bin mit meinen Daten schon dutzendfach umgezogen. Verschiedene Betriebssysteme, NAS, Verwaltungsprogramme. Meine Daten sind uralt und extrem gepflegt. Die überlasse ich keiner Software damit die jedesmal alles in andere Strukturen stecken. Das will ich einfach selbst kontrollieren.

Ohne tief in die Details zu gehen: Du hast auf Deinem Array (!!!) Shares wie zum Beispiel /mnt/user/Bilder oder /mnt/user/Dokumente. appdata liegt wie gewohnt auf dem Cache oder einem Pool (wenn vorhanden) und sollte auch aus Performance-Gründen als solches angesprochen werden (/mnt/cache|pool/appdata). Unterhalb dieses Shares legen die Container ihre config Ordner ab. Damit hast Du i.d.R. nix zu tun. Das Mapping des Plex Containers könnte dann /mnt/user/Bilder <--> /Bilder lauten. Abhängig vom verwendeten Container gibt es vordefinierte Path-Variablen für diese Container-seitigen Ordner. Dann würdest Du diese für das Erstellen des Mappings verwenden. Abhängig davon ob Plex Deinen Content löschen darf (nein) ist dieses Mapping entsprechend mit Rechten zu versehen (r/w-slave oder r-slave). Innerhalb Plex greifst Du dann auf /Bilder zu. Nextcloud ist leicht anders gestrickt. Nextcloud pflegt ein config Verzeichnis für seine Daten sowie ein data Verzeichnis für Deine Daten. Diese würde ich i.d.R. verteilen auf config --> Cache|Pool, data --> Array. Du kannst data theoretisch als /mnt/user/Nextcloud <--> /Nextcloud mappen. Als Mapping für Deine Daten würdest Du /mnt/user/Bilder <--> /Bilder bzw. /mnt/user/Dokumente <--> /Dokumente verwenden. Innerhalb Nextcloud greifst Du dann auf /Bilder bzw. /Dokumente zu. Zusätzlich kennt Nextcloud Externe Speicher. Gerade wer schon umfangreiche Daten besitzt, wird diese zu schätzen wissen. Du richtest einfach innerhalb der Nextcloud GUI einen Externen Speicher Eintrag für Deine o.g. Besipiel-Ordner ein Dokumente --> /Dokumente, Bilder --> /Bilder. Gleichzeitig wählst Du die Nextcloud-User die auf diese zugreifen dürfen. Als globale Anmeldeinformation definierst Du nobody mit leerem Passwort. Ich arbeite ausschließlich mit externen Speichern. Nextcloud darf gerne mit seinen /config und /data Verzeichnissen spielen, aber der eigentliche Content gehört mir und den pflege ich über die externen Speicher. Wenn ich etwas außerhalb kopiere, dann geht das direkt in meine eigenen Ordner. Beim Zugriff über Nextcloud scannt dieses die externen Speicher und pflegt den Content automatisch in seine Datenbank ein.

Plex muss Deine Dateien nur lesen können. Es sei denn Du hast in den Plex Einstellungen "Dateien dürfen gelöscht werden" aktiviert. Welche Shares? Unraid, Nextcloud, ... Im Nextcloud würde ich bei den externen Speichern gerne nobody mit seinem Passwort verwenden - der hat aber keines. M.M.n. ist das nicht ganz durchdacht. Solange bis ich das verstanden habe setze ich nachts alle Dateien auf nobody:users und 777. Dann klappt wieder alles.

umask steht auf 000. Das Problem ist folgendes: Stell Dir zwei User vor - User1 und User2. Beide User existieren in allen Rechnern (z.B. Windows) und melden sich entsprechend an. In Nextcloud gibt es beide User ebenso und auch in Unraid. Wenn die User Dateien hochladen so geschieht dies immer mit diesen Usern (SMB, DAV Nextcloud...user, etc) Jetzt verschiebt der User Dateien innerhalb Nextcloud. Nun trifft Plex auf den Plan und kann nicht mehr die Bilder lesen. Denn beim Verschieben durch den User entstehen andere Rechte. Ich habe das nie verstanden und nie klären können. Also setze ich nachts alles auf nobody und 777 ohne zu wissen warum.

Klar, geht. Habe ich genau so. Je nachdem was Du damit vor hast, würde ich Plex/Nextcloud aber nur Leserechte geben. Da bei uns die Mobilgeräte neue Bilder über Nextcloud hochladen, hat Nextcloud r/w-slave und Plex r-slave. Da ich aber nach 13 Jahren Unraid den Sinn oder Unsinn des Users nobody noch nicht verstanden habe, läuft das bei uns aber nicht rund. Jeder User hat seinen eigenen Unraid-, Windows- und Nextcloud-User. Unter diesen werden Dateien hochgeladen. Leider haben dann entweder Plex oder Nextcloud, je nach Uploader, keinen Zugriff. Das ist dämlich aber ich verstehe das, obwohl man mir das schon dutzendfach erklärt hat, nicht. Wer nobody verstanden hat, schafft das wohl. Ich muss nachts chown und chmod anwerfen damit es passt.

Wer nicht weiß was das Usenet ist oder sich nicht dafür interessiert: Bitte nicht lesen. --- Aus Langeweile wollte ich mir einen eigenen Usenet-Indexer in Python programmieren. Das lief auch so weit ganz gut, bis ich ein paar Berechnungen auf Basis der Daten eines einzelnen Tages durchführte. Danach war das Experiment ganz schnell beendet. Wen es interessiert - hier ein paar Eckdaten: Usenet Provider: Eweka Eweka Retention: 4.790 Tage Anzahl Groups/Gruppen: 111.117 Anzahl Messages/Artikel aller Groups/Gruppen: 492.544.548.539 Kalkulierte durchschnittliche Groesse eines Headers/Nachrichtenkopfs: 814 Bytes Kalkulierte Groesse aller Header/Nachrichtenkoepfe: 400.931.262.510.746 Bytes Exemplarische binaere Gruppe: alt.binaries.frogs Anzahl Messages/Artikel in der o.g. Group/Gruppe: 11.376.291.702 Kalkulierte Groesse aller Header/Nachrichtenkoepfe der o.g. Group/Gruppe: 9.260.301.445.428 Bytes ... und das ohne den eigentlichen Inhalt der Nachrichten ... Zur Erzeugung der NZB-Dateien werden nur die Header-Daten benötigt. Diese alleine, ohne den eigentlichen Nachrichteninhalt, kumulieren auf sagenhafte ca. 400 TB. Mein Respekt und Dank gilt daher den bekannten Indexern wie NZBIndex, NZBKing, BinSearch, etc... Keine Ahnung wie das die Indexer so eindampfen können, dass es überhaupt handbar wird.

... und sind sie kaputt? Ich habe schon Festplatten im unteren 3-stelligen Bereich bei Amazon gekauft und die kommen auch manchmal so an. Bisher war nur eine einzige DOA. Festplatten brauchen schon extreme negative Beschleunigungswerte um kaputt zu gehen.

Server und WLAN widersprechen sich einfach. Hier die drei Einsatzszenarien von der Unraid Website. Da passt WLAN nun wirklich nicht: Network-Attached-Storage/Application Server/Virtualization Host Wenn ich in Deiner SItuation wäre, dann würde ich mir einen WLAN-Repeater mit LAN Buchse o.ä. kaufen.

Achtung: Löscht keine Verzeichnisse sondern nur Dateien. Musst noch einen find mit -type d -empty -delete anhängen. Im Grunde genommen läuft es auf etwas Ähnliches wie das hinaus: rsync -av --remove-source-files <source> <target> && find <source> -type d -empty -delete

Such mal in diesem Board nach dem Plugin "User Scripts". Mit dem Plugin kann jedes Skipt zeitgesteuert aktiviert werden. Fehlt nur noch der passende Befehl fürs Verschieben. Den trägst Du dann dort ein.

In meinem Fall ging es nicht um Python v2 vs. Python v3 sondern um Python v3 3.9 vs. Python v3 3.6. Da gab es Inkompatibilitäten in den Tools aus Nerd- bzw. Dev-Pack. Wenn Du nach v2 vs. v3 fragst, lass die Finger von v2. Ist 2020 ausgelaufen. Es gibt syntaktisch einige gravierende Änderungen wie schon simple Dinge wie "print 'x'" vs. "print('x')". Returntypen von Funktionen können unterschiedlich sein, etc. etc.

Hab gerade mal nachgeschaut. Bis auf zwei, sind alle Container von Linuxserver.IO (swag, mariadb, nextcloud, nzbget, plex). Die beiden anderen von jlesage. Wobei ich mich gerade frage, wieso makemkv und mkvtoolnix nicht von Linuxserver.IO zur Verfügung gestellt werden ...

ich will das jetzt nicht groß zum Thema machen, aber für mich ist das wirklich kein Argument. Wie man hier vielleicht mitbekommen hat, stamme ich aus einer ganz anderen Generation - bin schon lange Privatier. Ich musste noch kommerzielle Assembler Programme in 1 KB RAM unterbringen. Der verschwenderische Umgang mit Resourcen - nur weil man sie hat - lehne ich bei Programmen/Anwendungen kategorisch ab. Wie gesagt, das ist meiner EDV/IT Ausbildung geschuldet die in den 70ern des letzten Jahrhunderts startete. So manches Framework ist so groß, da passten meine dutzend letzten kommerziellen Anwendungen (C, Android/Java) aus Anfang 2000 locker zusammen rein - ohne zusätzliche Frameworks. Wenn es keinen gravierenden fachlichen oder sachlichen Unterschied zwischen zwei gleichartigen Anwendungen gibt, werde ich immer die kleinere nehmen.

Was ist eigentlich der Unterschied für mich als Benutzer zwischen den verschiedenen Containern? Ich las vor einiger Zeit das ich777 Container auf Apache basieren, andere auf Alpine. Was bedeutet das für mich? Sind die kleiner, größer, schneller, langsamer oder gibt es gar Unterschiede im Funktionsumfang bzw. dem Handling? Vielen Dank.

Nur noch mal als Warnung: Meine oben gezeigten rsync Parameter synchronisieren. Ein reines Kopieren ginge anders. Wie gesagt, man muss die Parameter - und die Nutzung des jeweils letzten '/' - vom genauen Einsatzzweck abhängig machen. Mein Skript oben synchronisiert zwei Verzeichnisse. Das kopiert: rsync -av /mnt/user/<Sharename1>/ /mnt/user/<Sharename2>/

Auf diese Weise landet alles, was im Container temporär nach /tmp geschrieben wird, im RAM. /bla ginge auch, aber was/wer schreibt schon in /bla? Ich hatte eine gewisse Zeit /tmp meiner Container überwacht und bei intensiver Nutzung für diese Container das Mapping geändert: Host: /tmp/<Containername> Container: /tmp

Schon klar, war eher eine Zwinkerfrage. Hatte mir die Einsatzgebiete, sowie Pros und Contras, zwischen /tmp, /var/tmp und dev/shm schon vorher durchgelesen. Ich bin mit /tmp bisher extrem gut gefahren. Noch nie ein Problem. Mit anderen Varianten hatte ich schon mal Probleme. Das /tmp/<containername> <--> /tmp Mapping hat den geschmeidigen Vorteil, dass auch andere temporäre Dateien der jeweiligen Container dort landen. Da bei mir jede Nacht alle Container per User Script gestoppt, gesichert und wieder gestartet werden, sehe ich da eher kein Problem. Allerdings überlege ich getrade, in dem zugehörigen User Script vorsichtshalber noch ein Löschen des jeweiligen /tmp Bereich des Containers einzubauen. So etwas wie: docker stop <containername> rsync <container> <container_backup> rm /tmp/<containername> docker start <containername>

/tmp unter Unraid ist dann eine 100% RAM Disk (minus den laufenden Kram), oder

Am 16.09.2021 starb Sir Clive Sinclair, der Entwickler diverser Kleincomputer wie Sinclair ZX80, ZX81, ZX Spectrum und QL - die ich in genau dieser Reihenfolge besaß - und für die ich meine ersten Programme entwickelte und verkaufte. Ohne Sinclair und seine Produkte wäre ich nie in die IT (FKA EDV) eingestiegen. Sinclair war ein Visionär. Manche Produkte waren genial, manche kolossale Flops. Eine BBC Doku mit dem Titel "Micro Men (2009)" u.a. mit Martin Freeman dreht sich um Sinclair und u.a. seinen Geschäftspartner Chris Curry. Programmiert wurden die Geräte zunächst in Zilog Z80 Assembler, spätere seiner Produkte in Motorola 68008 Assembler. Der ZX80 zum Beispiel besaß 4 KB ROM und 1 KB RAM. An den Rechner hing man dann einen TV (Koax) und einen Kassettenrekorder für die Programme. Programme wurden auf 15 min Kassetten (wie Musik Kassetten) geliefert. Der Zilog Assembler war z.B. auf der A-Seite der Kassette, der zugehörige Linker auf der B-Seite der Kassette. Zum Übersetzen eines Assembler Programmes lief zunächst der Compiler 15 Minuten lang, dann der Linker 15 min lang. Wenn man dann einen Fehler beim Linken feststellte, dann begann man wieder von vorne: Kassette mit Sourcecode laden, Sourcecode ändern, Sourcecode auf Kassette speichern. Compiler Kassette in das Kassettendeck einlegen usw usf. Später gab es eine externe 16 KB RAM Erweiterung, die ich eigens in England kaufte, sowie Microdrives, die die Kassetten teilweise ablösten. Später habe ich mit Kumpeln eine Adapterplatine gebaut und einen zugehörigen Treiber. Damit konnten wir eine 5 MB IBM Festplatte an den Sinclair QL anschliessen. Die Programmierung unter diesen Voraussetzungen hat mich nachhaltig beeinflusst. Hier einige Links: https://de.wikipedia.org/wiki/Clive_Sinclair https://de.wikipedia.org/wiki/Sinclair_ZX80 https://de.wikipedia.org/wiki/Sinclair_ZX81 https://de.wikipedia.org/wiki/Sinclair_ZX_Spectrum https://de.wikipedia.org/wiki/Sinclair_QL https://de.wikipedia.org/wiki/Microdrive_(Bandlaufwerk) Auf diese Anzeige hin habe ich in 1980 meinen ersten Sinclair ZX80 erworben:

Nein, es war aber auch noch nie ein Problem. 4x 4K Transcode hatte ich schon, 5x 4K Transcode noch nie. Der Plex Server ist in dieser Angelegenheit eigentlich ausgereift. Die GUI auf den diversen Klienten ist da schon eher das Problem.

Das User Scripts Plugin wäre eine Variante. Du legst dort ein neues Skript an, gibst diesem einen Namen (e.g. "Sync Share1 nach Share2") und in dem Script trägst Du etwas wie folgt ein: #!/bin/bash #arrayStarted=true #clearLog=true #noParity=true #Achtung: An der Quelle gelöschte Dateien werden am Ziel ebenfalls gelöscht (AKA Sync) rsync -avPX --delete-during /mnt/user/<Sharename1>/ /mnt/user/<Sharename2>/ Das "Schedule" für dieses Skript setzt Du auf "Custom" o.ä. und in das dann erscheinende Eingabefeld dahinter trägst Du "0 * * * *" ein (natürlich alles ohne die Anführungszeichen). Nach dem Bestätigen mit "Apply" o.ä. wird Dein Skript zu jeder vollen Stunde zur Minute 0 ausgeführt. Je nachdem was Du erreichen willst, solltest Du die rsync Parameter checken.

Je nach verfügbaren RAM kannst Du das Plex Transcoding auf das RAM umbiegen. Das haben viele hier entsprechend konfiguriert. Es gibt hierzu zwei Techniken. Ich nutze einfach einen Ordner unterhalb von /tmp (/tmp/plex) auf dem Host und reiche diesen im Container Mapping an den Container (/tmp). Der /tmp/plex Ordner auf dem Host muss natürlich für den Container beschreibar sein. So läuft das bei mir seit Jahren. Hab allerdings auch 128 GB verbaut. Je nach verwendetem Plex Container gibt es bereits vorkonfigurierte Mappings für Transcode - die muss man dann nur entsprechend mit einem Ordner auf dem Host füllen. Das neue und aufwändige Sonic Music Matching von Plex mit seinen Temp Dateien läuft übrigens bei mir auf diese Weise ebenfalls im RAM. Dadurch klappt das erheblich schneller. Ich hatte kurzfristig mal auf eine andere RAM Variante umgestellt, die hatte aber nach ein paar Runden meinen Rechner bis zum Stillstand gehimmelt. Das werde ich nicht mehr nutzen.

Temporäre Plex Transcoder Dateien auf ein verschlüsseltes Drive zu legen halte ich persönlich für überflüssig. Unabhängig davon kann ich mir sehr gut vorstellen, dass ein zusätzlicher Layer für die Verschlüsselung Performance frist. Ich habe von 25-50% je nach Quelle im Web gelesen - abhängig natürlich von genutzter Prozessor-Power und Software- vs. Hardware-Verschlüsselung. Ich persönlich arbeite nicht mit Verschlüsselung. Z.B. NVMe und LUKS: https://unix.stackexchange.com/questions/615159/nvme-performance-hit-when-using-luks-encryption