hawihoney

Wie hast Du das formatiert? Du hast das Array gestoppt, die Platte auf XFS gesetzt, das Array gestartet und dann? Der exakte Ablauf wird benötigt. Je nach durchgeführten Schritten hast Du nun eine leere Platte oder durch die Datenwiederherstellung nach wie vor verschlüsselte Daten auf der Platte.

Der Share Downloads nutzt den Cache und der steht auf Cache=Only|Nur. Meines Wissens schreibst Du damit den Cache voll und es wird nichts ins Array verschoben. Ich denke dort müsste Ja|Yes stehen.

Verstehe ich nicht: Handelt es sich um eine neue Platte oder eine Austauschplatte.

Mußt Du nicht. Du kannst ja nach wie vor mit beidem arbeiten. Befüllen über die User-Shares, Plex liest über die Disk-Shares. Das Beste aus beiden Welten.

Tut mir echt leid, aber meine alten Augen können diese winzige Schrift mit dem schwarzen Hintergrund nicht lesen. Irgendwas stimmt nicht mit der Download Zuordnung, aber das ist eher auf Grund des Musters geraten, die Buchstaben kann ich nicht erkennen. Jetzt verstehe ich auch warum weiße Schrift auf schwarzem Hintergrund augenschonender sein soll, man liest halt nicht mehr

Bevor ich das Ensemble bei eBay einstelle: Verkaufe die u.a. Komponenten gebraucht gegen Abholung im Kölner Norden. Diese Komponenten waren lange Jahre bei mir im Einsatz und funktionierten bis zum Ausbau einwandfrei - mgutt war beim Ausbau dabei Das ist eine Monster Zusammenstellung mit extrem hoher konstanter Leistung. Ich dachte an irgendwas zwischen EUR 150 und EUR 200. Wie gesagt, gegen Abholung. Sollte das System wider Erwarten DoA sein, dann gibt es den Kaufpreis im Austausch gegen die Ware zurück (inkl. ggfs. notwendiger Versandkosten). 1x Supermicro X9DRi-F Mainboard 2x Intel Xeon E5-2680 v2 CPU (insgesamt 20 Kerne/40 Threads) 2x Supermicro SNK-P0050AP4 Cooler 8x 16GB RAM --> 128 GB Ein paar Bilder hängen an. Hier ein Link zu meinem alten System:

In dem Du in Plex statt mit den User-Shares mit Disk-Shares arbeitest. Trage in den Libraries einfach alle Platten ein, die den entsprechenden Content enthalten. Z.B. Statt: /mnt/user/Movies --> /mnt/disk1/Movies --> /mnt/disk3/Movies Dazu muss natürlich in den Container-Settings /mnt (r-slave) statt /mnt/user/Movies gemappt werden.

Weiß nicht wie Du auf den Betrag kommst. Habe selbst Anfang des Jahres aufgerüstet für eine dicke Kiste. Neues Server Motherboard (Supermicro X12SCA-F), neuer Prozessor (Intel Xeon W-1290P), neues RAM und Lüfter. Damit lag ich auf einem Drittel Deines o.g. Preises. Aber meine Kiste fährt, im Gegensatz zu Deinen erheblich höheren Anforderungen, "nur" 3 VMs und wird nicht zum Spielen genutzt. Es gibt hier professionelle/kommerzielle Hardware-Berater. Die können solche Einteilungen in Preissegmente/Use-Szenarien sicherlich vornehmen. Allerdings befürchte ich, dass es das nicht für lau gibt. Das geht m.E. weit über eine einfache Kaufberatung hinaus. Unter einer einfachen Kaufberatung verstehe ich "ich mache das, was brauche ich dafür". Im Gegensatz dazu ist "mach mir mal eine Liste was man alle machen könnte und was ich dafür benötigen würde" etwas ganz anderes ...

The error says: Drive full. Download paused. Show screenshot of cache disk (main page) and container settings.

Es waren Deine Anforderungen. 6 VMs, diverse Container, dedizierte Gaming Grafikkarte, dedizierte Soundkarte... Was hattest Du erwartet?

Wo kommt denn das her - achtet auf den Schreibfehler: Ignoring unknown parameter "direcetory mask" Starte mal bitte im Maintenance Mode ohne Plugins. Meines Erachtens stimmt etwas nicht mit der Installation.

Offline uncorrectable und Current pending sectors sind eindeutige Fehler. Sofern es eine funktionierende Parity sowie Backups der relevanten Daten gibt würde ich die Platte aber nicht sofort rauswerfen. Ich würde sie unter genauer Beobachtung halten. Mach regelmäßige Parity Checks und prüfe ob die Werte steigen.

Habs gefunden, sorry für den überhasteten Post: lsusb -D /dev/bus/usb/001/010 [...] iSerial 3 4C530001110213121321 [...]

Mir ist einer von zwei USB Devices abgestürzt. Das erste USB Device hängt als Unraid Boot Stick am Host. Das zweite USB Devices ist an eine VM durchgereicht. Beide sind vom selben Typ (Product:Vendor). Deshalb werden beide per Bus:Device angesprochen. Was mir nun fehlt ist die Verknüpfung zwischen einer disk-by-id zu einem Bus:Device. Das kann ich bisher sagen: root@Tower:~# ls /dev/disk/by-id/usb-* /dev/disk/by-id/usb-SanDisk_Cruzer_Fit_4C530001110213121321-0:0@ /dev/disk/by-id/usb-SanDisk_Cruzer_Fit_4C530001220213122434-0:0@ /dev/disk/by-id/usb-SanDisk_Cruzer_Fit_4C530001110213121321-0:0-part1@ /dev/disk/by-id/usb-SanDisk_Cruzer_Fit_4C530001220213122434-0:0-part1@ root@Tower:~# lsusb Bus 001 Device 004: ID 0781:5571 SanDisk Corp. Cruzer Fit Bus 001 Device 010: ID 0781:5571 SanDisk Corp. Cruzer Fit root@Tower:~# lsscsi [0:0:0:0] disk SanDisk Cruzer Fit 1.00 /dev/sda [2:0:0:0] disk SanDisk Cruzer Fit 1.00 /dev/sdc Im lsusb sind beide SanDisk zu sehen (Bus:Device 001:004 und 001:010). Eine ist aktiv im Host, von der zweiten suche ich nun den Bus:Device. Da ich Bus:Device vom Host ebenfalls nicht kenne, ist das schwierig. Gibt es irgendeinen Befehl mit dem man die Zuordnung zwischen diesen Informationen finden kann? TLDR: Wie finde ich vom /dev/disk/by-id/usb-SanDisk_Cruzer_Fit_4C530001110213121321-0:0 die Bus:Device Kennung? Vielen Dank.

Nein. Ich würde grundsätzlich keine unterschiedlichen Techniken in einem Array oder Pool mischen. Entweder HDDs, SSDs oder NVMe/PCIe. Wenn man mischt, dann bekommt man immer den jeweils kleinsten Nenner. Ich will dich nur darauf aufmerksam machen, dass die beiden o.g. Pool Devices in einem Pool beim Schreiben maximal 550 MB/s erreichen und nicht die theoretisch möglichen 3500 MB/s der NVMe. Beim Lesen sieht es anders aus. Wenn Du Ausfallsicherheit brauchst aber keine andere Möglichkeit siehst, dann mach halt diesen Pool. Du solltest dann halt nur wissen was Dich erwartet.

Sehe ich das richtig? Du kombinierst eine SSD und eine NVMe in einem Pool? Die NVMe ist 6x schneller als die SSD. Der Pool wird nie sein Potential ausschöpfen können.

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.