hawihoney

Es gibt ein Problem mit 6.12.9 unter ganz bestimmten Umständen. Wer diese Konfiguration betreibt sollte 6.12.9 noch nicht installieren. Es geht um CIFS/SMB Remote Mounts die mit Unassigned Devices in Unraid angelegt werden (/mnt/remotes/xxx). Das heißt Unraid ist der Klient einer CIFS/SMB Verbindung. Die Funktion von Unraid als Server einer CIFS/SMB Verbindung ist nach derzeitigem Erkenntnisstand davon nicht betroffen. Es gibt zwei aktuelle Bug Reports, einer ist von mir: Weiterhin gibt es von @dlandon einen Hinweis wohin das Problem zeigt (Kernel/SAMBA): Erkennen könnt Ihr das Problem eindeutig an den CIFS VFS Fehlern in der syslog. Wenn diese auftauchen, dann seht Ihr oder Eure Software nur einen Teil der existierenden Ordner oder Dateien. Das kann erhebliche Probleme nach sich ziehen. Wer 6.12.9 über 6.12.8 bereits installiert hat, und diese Konfiguration betreibt bzw. den Fehler bekommt --> ein Downgrade auf 6.12.8 ist jederzeit problemlos möglich:

Versuch doch erstmal das Ganze ans Laufen zu bringen - nicht immer weitere Störfeuer. Hast Du meine beiden Anmerkungen oben umgesetzt?

Versuch doch mal Custom "user" unter Parent Directory und Camera Name unter Child Directory. Hier treffen zwei dämliche Systeme aufeinander.

Ich sach doch, das verwirrt total. Ziel Lokal /mnt/user/Test_LB/ readonly Quelle Remote ssh root@host:/mnt/user/Test/ Der kann am Ziel nicht schreiben. Nachtrag: Ändere /mnt/user/ auf read/write und schmeiß diesen überflüssigen Pfad aus den Container-Einstellungen:

Damit wir das richtig verstehen. Host: /mnt/user/Test/ <--> im Container: /mnt/user/Test/ Remote Host: /mnt/remotes/<Servername>/Test/ <--> im Container: /mnt/user/Test/ Wie heißen die voll qualifizierten Ordner? Und welcher Ordner läßt sich wo nicht löschen? Mir fehlt da Einiges an Details.

Für eines der kommenden Release wird erwartet, dass die Grenzen fallen werden. Wenn ich das im Interview mit dem Inhaber richtig gehört habe, dann wird das Array zu einem Pool. Und man wird dann mehrere Array-Pools anlegen können. In diesem Zuge fallen dann auch die Grenzen des Movers. Pool zu Pool wird dann möglich sein. Wie gesagt: Das wurde im Interview angedeutet.

Das geht nicht ohne Eingriff des Herstellers. Es wird zwar nie erwähnt, aber die Lizenz ist nicht nur an den Stick sondern auch an die E-Mail Adresse gebunden. Wende Dich an den LimeTech Support und schildere Deine Situation. Halte Kaufnachweise o.ä. bereit. Die werden die Lizenz auf die neue E-Mail transferieren und der alten E-Mail den Zugang entfernen: https://unraid.net/contact

Aber die hast Du eben nicht - und mich hat das bereits verwirrt. /mnt/user/user/... oder /mnt/user/remotes/... ? Würde ich nie so machen. Wenn schon dann: /mnt/addons/ --> /mnt/addons/ /mnt/disks/ --> /mnt/disks/ /mnt/remotes/ --> /mnt/remotes/ /mnt/user/ --> /mnt/user/ Dann könntest Du wie selbstverständlich z.B. von /mnt/user/Dokumente/ nach /mnt/remotes/Backup/Dokumente/ oder vice versa sichern und es würde bei Host und Container mit identischen Pfaden gearbeitet. Alles andere wird auf Dauer verwirren. Aber wie schon von Euch gesagt: Das ist Latte, kann jeder machen wie er will. Oder für die, die wissen was sie machen, und vielleicht faul sind: /mnt/ --> /mnt/

Hab zwar selber keine User Shares im Einsatz, aber sind die remotes tatsächlich auch unter /mnt/user/ zu finden? Dann würde bei mir /mnt/user (FUSE) über drei Rechner laufen. Das kann ich mir nicht vorstellen. Ich denke die drei kann man nur über /mnt/xxx/ erreichen (xxx -> addons|disks|remotes).

Steht in der Hilfe bei den Disk Settings (ersetze Cache durch Pool, werde ich mal weitergeben):

Wenn Du eine alte Lizenz gekauft hast, dann bleibt diese gültig:

Natürlich nicht. Eine einzelne Parity-Platte kann eine einzelne Daten-Platte nur mit Hilfe aller anderen Daten-Platten rekonstruieren. Erneut verweise ich auf die offizielle Doku. Hier wird die Funktionsweise erläutert: https://docs.unraid.net/legacy/FAQ/Parity/ Es gibt aber noch eine ganz einfache Lösung für Dich: Tausche 1x 8 TB durch die neue 16 TB und lass die andere 8 TB drin. Kannst die dann später mal ebenfalls gegen 16 TB tauschen ...

Der offizielle Weg: Schritt 1: 1x 8 TB gegen neue 16 TB tauschen https://docs.unraid.net/legacy/FAQ/replacing-a-data-drive/ Schritt 1a: Daten von zweiter 8 TB auf neue 16 TB verschieben. Schritt 2: 1x 8 TB entfernen https://docs.unraid.net/legacy/FAQ/shrink-array/ Bei Schritt 1 habe ich das noch nie gemacht. Ging auch ohne:

Das macht eigentlich der Parameter allow_other im rclone mount. Mich wundert schon, dass es zwischen @alturismo und mir unterschiedliche Berechtigungen nach dem mount gibt. Bei mir ist es so wie beim @sylvio2000: root@Tower:~# ls -la /mnt/addons/gdrive/ total 0 drwxrwxr-x 1 nobody users 0 Feb 25 21:20 ./ drwxrwxrwt 3 nobody users 60 Feb 25 21:20 ../ drwxrwxr-x 1 nobody users 0 Feb 24 2023 Backup/ Vielleicht sollte mal jemand testen ob in dem fraglichen Container mit einem eigenen User und einer eigenen Gruppe gearbeitet wird.

Bei mir laufen ein paar dutzend Python Skripte per User Scripts Plugin auf diese Art und Weise: #!/bin/bash #arrayStarted=true #backgroundOnly=true #clearLog=true #noParity=true python3 /mnt/disk1/Projekt/Source.py Kannst aber auch das Python Skript komplett in das User Skript kopieren: Musst wahrscheinlich nur einen She Bang für Python an erster Stelle setzen. Das habe ich aber noch nie so gemacht da ich lieber den Code auf dem Array entwickle statt auf dem Stick.

Es gibt halt mehrere Wege. Das hängt an den persönlichen Erfahrungen bzw. Wünschen. Ich persönliche halte den Preclear für völlig überflüssig. Unraid macht das selbst. Eine Festplatte kann zu jedem Zeitpunkt ausfallen. Natürlich gibt es Statistiken, dass, sollte eine Platte den Beginn überstehen, dann hält sie auch weiter durch. Dann giibt es noch die Fraktion die beim Homelab die beschränkte Performance während des Preclears durch Unraid bemängelt. Jeder hat da seinen eigenen favorisierten Weg. Ich gehe immer den offiziellen Weg. Ich habe bestimmt 200-300 Platten, wenn nicht noch mehr, in Unraid Arrays gesteckt. Da wurde nix von mir precleared. Ich precleare nur gebrauchte Platten bevor ich sie bei eBay einstelle.

Geh einfach den offiziellen Weg. Das garantiert zu jedem Zeitpunkt die Ausfallsicherheit und ist simpel: Array stoppen Beide zusätzlichen Datenplatten eintragen Array starten --> Unraid cleared und formatiert die beiden selbst https://docs.unraid.net/unraid-os/manual/storage-management/#data-disks Array stoppen Zusätzliche Parity Platte eintragen Array starten --> Unraid macht sein Ding mit der 2. Parity Platte https://docs.unraid.net/unraid-os/manual/storage-management/#parity-disks --> Macht 2 Sync Läufe von jeweils ca. 35 Stunden bei 18 TB.

Kein Thema hier - läuft.

Wer es noch nicht mitbekommen hat. Am 27.03.2024 startet das neue Unraid Lizenzmodell. Wer also noch in den Genuß von lebenslang gültigen Basic und Plus Lizenzen kommen will, der sollte nun zuschlagen (Neukauf bzw. Upgrade). Das selbe gilt auch für die lebenslang gültige Pro Lizenz. Der Preis der Pro Lizenz (heißt dann Lifetime) wird fast doppelt so teuer. FAQs findet Ihr in diesem Beitrag: https://forums.unraid.net/topic/158737-new-unraid-os-license-pricing-timeline-and-faqs/

Wie schon geschrieben bin ich raus. Ich habe es genau so am laufen. Allerdings nicht mit diesem Container. Ich bezweifle aber das es daran liegt.

Nur noch eine kleine Anmerkung dazu: Das regelt man im Docker Universum in den Container-Einstellungen über weitere Volume-Mappings. Jeder Pfad erhält dann eigene Zugriffsrechte. Beispiel: /mnt/user/MeineLiebevollKuratierteFilmSammlung/ <-> /media/MeineLiebevollKuratierteFilmSammlung/ (read/slave) /mnt/user/TVKrempel/ <-> /media/TVKrempel/ (read/write/slave) Hat nur einen winzigen Nachteil: Brauchst zwei Plex Libraries. Kann man verschmerzen. Bzgl. Vertrauen: Das eine ist eine millionenfach installierte kommerzielle Anwendung (closed source). Das andere ein milliardenfach genutztes Subsystem für Anwendungen (open source). Da fällt bei mir die Wahl nicht schwer Aber wie gesagt, alles gut. Der Vollständigkeit halber. So sieht das bei mir aus. Der /mnt/ Pfeil zeigt zum Container. Das bedeutet readonly.

Wäre aber schon blöd wenn die liebevoll kuratierte Sammlung über die Wupper ginge. In Linux Distributionen regelt man den Zugriff über die Benutzer, Gruppen und deren Berechtigungen. Unraid ist aber keine Standard Distribution. Es ist ein NAS++. Und das macht es aufwändiger. Was die Performance angeht. 4K Streams? Kein Thema. Das machen unsere iGPUs. Da dümpelt hier die CPU vor sich hin. 2-3 4K sind hier wirklich kein Thema. Es quietscht nur bei den grafischen Untertiteln. Auch hier kein Bedarf der Grundsatzdiskussion. Nur eine der gewünschten Meinungen. Es sollte nur ein Hinweis sein.

Der Plex Media Server war vor vielen Jahr - weit vor dem Docker Support - bereits Bestandteil von Unraid und wurde auf dem Stick hinterlegt. Für alle Fälle möchte ich aber darauf hinweisen, dass Docker nicht nur ein nettes Gimmick ist. Docker bildet eine Isolationsschicht zwischen dem lokalen System - dem Unraid Server - und einer Anwendung wie Plex. Beispiel: In Deiner Installation hat Plex ungehinderten Zugriff auf Deine Laufwerke. Du verläßt Dich auf die entsprechende Einstellung in den Plex Settings (Löschen erlauben). Aber sollte die Anwendung Amok laufen, dann könnte sie Dir alle Platten löschen. In meiner Installation z.B. hat der Plex Container nur Leserechte auf die Laufwerke. Da kann die Anwendung machen was sie will, sie kommt nicht durch. Das ist nur einer der Vorteile wenn man Anwendungen in die Container sperrt. Ist aber schön zu hören, dass Du Unterschiede feststellst. Meine Installation reagiert jedenfalls aus dem Container heraus unfassbar schnell. Ich wüsste nicht wie Plex bei mir schneller sein sollte. Ich staune immer wieder wie zappig das System reagiert.