hawihoney

Aus heiterem Himmel habe ich seit zwei Tagen Probleme mit dem Zugriff von außen. Ich kann mir diese Probleme einfach nicht erklären und würde mich über Tipps freuen: Ich habe bei duckdns.org eine Subdomain registriert. Nennen wir sie xxxxxxxx.duckdns.org. In SWAG habe ich dazu nextcloud und plex angegeben (also nextcloud.xxxxxxxx.duckdns.org und plex.xxxxxxxx.durckdns.org). So läuft das seit Jahren. Seit zwei Tagen nun ist mal die eine (nextcloud) und mal die andere (plex) nicht erreichbar. Mal bekomme ich einen Fehler der auf eine Namensauflösung verweist, mal einen Fehler (nicht erreichbar) und nach ein paar Sekunden kommt die Website dann doch. Wenn ich auf der Konsole des Servers mit nslookup teste, dann bekomme ich höchst seltsame Ergebnisse: root@Tower:~# nslookup nextcloud.xxxxxxxx.duckdns.org Server: 192.168.178.1 Address: 192.168.178.1#53 Non-authoritative answer: Name: nextcloud.xxxxxxxx.duckdns.org Address: 91.xxx.xxx.76 Name: nextcloud.xxxxxxxx.duckdns.org Address: 2003:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:ec92 root@Tower:~# nslookup plex.xxxxxxxx.duckdns.org Server: 192.168.178.1 Address: 192.168.178.1#53 ** server can't find plex.xxxxxxxx.duckdns.org: SERVFAIL In SWAG sieht das so aus: Zunächst dachte ich es liegt am DNS. Eingetragen war in der Fritzbox der DNS meines Telekoms Zugangs. Den hatte ich dann testweise durch Cloudflare (1.1.1.1) oder Google (8.8.8.8) ersetzt. Das hat aber nicht geholfen. Die Probleme habe ich über Mobilgeräte (LTE) genauso wie über Windows. Hat jemand eine Idee was das sein könnte? Wie kann mal die selbe Subdomain (plex.xxxxxxxx.duckdns.org) funktionieren und die andere nicht (nextcloud.xxxxxxxx.duckdns.org). Vielen Dank.

Da würde ich mal ansetzen. /dev/mapper ist nicht von Unraid. Solange ich zurückblicken kann war es so wie in der Liste unten und nicht anders. /dev/md* --> /mnt/disk*. So sieht das auf meinem Haupt-Server aus. Die Ausgabe habe ich nur um die vielen /mnt/remotes (Unassigned Devices) gekürzt. /mnt/disks, /mnt/remotes und /mnt/rootshare sind von UD. Die overlays kamen irgendwann mit Docker. /mnt/user und /mnt/user0 kamen (und gingen - bei mir) mit den User-Shares. Die pools kamen erst vor Kurzem. Das meiste stammt aber genau so noch aus Anfangstagen: root@Tower:~# df -h Filesystem Size Used Avail Use% Mounted on rootfs 63G 976M 62G 2% / tmpfs 32M 1.3M 31M 5% /run /dev/sdd1 15G 336M 15G 3% /boot overlay 63G 976M 62G 2% /lib/firmware overlay 63G 976M 62G 2% /lib/modules devtmpfs 8.0M 0 8.0M 0% /dev tmpfs 63G 0 63G 0% /dev/shm cgroup_root 8.0M 0 8.0M 0% /sys/fs/cgroup tmpfs 128M 564K 128M 1% /var/log tmpfs 1.0M 0 1.0M 0% /mnt/disks tmpfs 1.0M 0 1.0M 0% /mnt/remotes tmpfs 1.0M 0 1.0M 0% /mnt/rootshare /dev/md1 11T 11T 20G 100% /mnt/disk1 /dev/md2 11T 11T 11G 100% /mnt/disk2 /dev/md3 11T 11T 16G 100% /mnt/disk3 /dev/md4 11T 11T 17G 100% /mnt/disk4 /dev/md5 11T 11T 28G 100% /mnt/disk5 /dev/md6 11T 11T 33G 100% /mnt/disk6 /dev/md7 11T 11T 21G 100% /mnt/disk7 /dev/md8 11T 11T 16G 100% /mnt/disk8 /dev/md9 11T 11T 11G 100% /mnt/disk9 /dev/md10 11T 11T 16G 100% /mnt/disk10 /dev/md11 11T 11T 13G 100% /mnt/disk11 /dev/md12 11T 11T 17G 100% /mnt/disk12 /dev/md13 11T 11T 11G 100% /mnt/disk13 /dev/md14 11T 11T 13G 100% /mnt/disk14 /dev/md15 5.5T 5.5T 20G 100% /mnt/disk15 /dev/md16 11T 11T 11G 100% /mnt/disk16 /dev/md17 3.7T 3.1T 605G 84% /mnt/disk17 /dev/md18 11T 11T 9.5G 100% /mnt/disk18 /dev/md19 11T 11T 3.6G 100% /mnt/disk19 /dev/md20 11T 11T 37G 100% /mnt/disk20 /dev/md21 11T 11T 13G 100% /mnt/disk21 /dev/md22 11T 11T 5.0G 100% /mnt/disk22 /dev/nvme0n1p1 932G 209G 723G 23% /mnt/pool_nvme shfs 228T 227T 937G 100% /mnt/user /dev/nvme1n1p1 932G 241G 691G 26% /mnt/disks/NVMe2 /dev/sdb1 1.9T 698G 1.2T 38% /mnt/disks/pool_ssd /dev/loop2 1.0G 4.9M 904M 1% /etc/libvirt overlay 932G 209G 723G 23% /var/lib/docker/overlay2/9c3b1a35a6f003a0998916ccdc09c5a770c6f8990cefe6dfcb739ddc59076400/merged overlay 932G 209G 723G 23% /var/lib/docker/overlay2/832b60984ae67cb6a9acba9fcbea57904a8e68037bf6c1612a596ebb4468d9ec/merged overlay 932G 209G 723G 23% /var/lib/docker/overlay2/5a91d2aba41b53cb0cf3387af22ea2f2b5d0a8d6cba2ad0c6632d0f6f691a7d6/merged overlay 932G 209G 723G 23% /var/lib/docker/overlay2/1bb39e54dbdbca640ecb1f50510780c2232d3a31de49f2ca080bbf7c974c91dc/merged overlay 932G 209G 723G 23% /var/lib/docker/overlay2/25b9c4616bf9d4a979a907deedf933b05f178eda8d8e8a4651fa0ac359df8429/merged overlay 932G 209G 723G 23% /var/lib/docker/overlay2/d73fb010cfd76d190a3e4db7cd68a85ab78dfd36ced4e0b9512f2121d4e00f07/merged overlay 932G 209G 723G 23% /var/lib/docker/overlay2/88106699d68600d9e20c36b1869e8f1530bc6cbbbd2673ad66923155956bc963/merged overlay 932G 209G 723G 23% /var/lib/docker/overlay2/d2baec3937bab2f40f154229b0e640e36cdeaea4792d9320324b240bcf39c675/merged tmpfs 13G 0 13G 0% /run/user/0

Seltsam. Ich habe die bei mir nicht selbst gelöscht. Die waren irgendwann einfach weg.

3 Server hier - 2x 6.11, 1x 6.10.3. User Shares aktiviert aber nicht genutzt. Keiner hat mehr /mnt/user0. Ich meine ich hätte vor einiger Zeit in den Ankündigungen darüber gelesen.

Was ist denn /dev/mapper/? Das habe ich noch nie gesehen. Und /mnt/user0/ gibts auch nicht mehr. Muss mal gucken auf welcher Version Du bist.

Ich gehe jetzt bewusst nicht auf die Wünsche und deren Sinn ein. Aber was Du Dir wünschst wäre einfach zu lösen: 1.) Installiere das User Scripts Plugin 2.) Füge in einem neuen User-Script diese Befehle ein. Kopiere für jede existierende weitere Daten-Platte die Zeile mit dem "tree" und passe sie an. Nennen wir das Skript mal "Export Disk Strukturen": #!/bin/bash #arrayStarted=true #clearLog=true #noParity=true tree /mnt/disk1 > /mnt/disk1/WohinAuchImmer/Disk1.txt tree /mnt/disk2 > /mnt/disk1/WohinAuchImmer/Disk2.txt 3.) Füge in einem weiteren User-Script diese Befehle ein. Wie Du siehst müsstest Du für jede Festplatte die Du unter 2.) aufgenommen hast unter 3.) einen weiteren Parameter aufnehmen. Nennen wir dieses Skript mal "Durchsuche Disk Strukturen": #!/bin/bash #arrayStarted=true #clearLog=true #noParity=true #argumentDescription=Wonach willst Du suchen? echo "Gesucht wird nach: $1" grep -i "$1" "/mnt/disk1/WohinAuchImmer/Disk1.txt" "/mnt/disk1/WohinAuchImmer/Disk2.txt" | sort | uniq sleep 5m Anmerkungen: 1. Ich habe das jetzt aus dem Ärmel für Dich geschrieben. Das kann man sicherlich noch schöner und geschickter lösen. 2. Ich verwende "tree" statt "find" da ich die schöne Ausgabe mag. Kann man aber auch ändern. 3. Den Ordner "/mnt/disk1/WohinAuchImmer" in den Skripten musst Du natürlich durch etwas für Dich passendes ersetzen und vorher anlegen. 4. Als Such-Parameter ist nur ein Wort erlaubt. Das liegt am Plugin selbst:

Ich weiß, ist off topic. Meiner Meinung nach stimmt dann aber etwas nicht. Das darf einfach nicht sein. Hätte viel zu viel IT in meinem Leben gebaut und begleitet um das bei mir zu akzeptieren. Zudem kenne ich sowohl die Plex Datenbank und die Metadaten Struktur auf der Platte ziemlich genau um zu verstehen wie das abläuft. Wenn Plex appdata auf einem eigenen Device(Pool) liegt und Du mit Disk-Shares in den Mediatheken arbeitest, dann sind nur diese gefragt. Warum sollte Unraid auf die konkrete Frage nach /mnt/.../appdata/ und /mnt/diskx/.../*.mkv antworten "Ich mach mich mal auf die Suche auf ein paar anderen Platten". Das widerspricht jeglicher Logik und Erfahrung und würde mich, wäre ich denn betroffen, fuchsteufelswild machen und ich würde Otto bei Plex bzw. die Jungs hier stündlich nerven. Auf der einen angefragten Platte dauert der erste Zugriff dann logischerweise minimal länger da noch nix gecacht ist. Jedenfalls läuft das hier so. Und m.E. muss das auch so sein. Was Plex alllerdings ganz gerne nach einem Neustart macht ist selbst mal kurz überall zu schauen. Das geht aber schnell und ich merke es nur wenn ich mich darauf konzentriere. Nach einem Server Neustart kontrolliere ich noch schnell ob alles läuft (VMs, Container, Mounts) und aktiviere dann den Spin-Down. Ab da ist dann Ruhe und nur betroffene Platten starten bei Bedarf.

Aber genau das ist hier der Unterschied. Bei Nutzung von Disk-Shares gibt es das nicht. Ich greife auf Film X zu, Plex weiß, daß der auf /mnt/diskX liegt und startet diese, und nur diese. Egal ob beim ersten Zugriff oder später. Im Übrigen ist mir aufgefallen, dass beim Installieren von Unraid Updates (hier 6.11), nach dem Sync, der Cache entleert ist. Das würde bedeuten, dass nach dem simplen Installieren (ohne Reboot) eines Unraid Updates, User-Shares bei den ersten 1-2 Zugriffen komplett durchsucht würden.

Noch eine Analogie zu diesem Plugin: KFZ-Hersteller schicken die Fahrzeuge unzählige Stunden in den Windkanal um sie möglichst effizient und mit wenig Wind-Widerstand zu produzieren. Das Fahrzeug wird verkauft und irgendein Depp schraubt einen Spoiler dran. So kommt mir das Cache Dirs Plugin vor. Die Kernel Entwickler haben unzählige Stunden in das Paging und Caching investiert. Dann kommt ... Nicht böse sein. IMHO ist das Plugin die Lösung für ein Problem das es nicht gibt. Lieber einen RAM-Riegel mehr rein und das Plugin raus, das erspart häufige Lesezugriffe des Plugins und damit verbundenes Aufwachen der Platten. Der Riegel ist dann schnell bezahlt ... Nur meine 2 Cent.

Das Plugin nutze ich nicht. Wenn Du richtig testen willst, mach es ohne das Cache Dirs Plugin. Da ich heute morgen eine Zigbee Steckdose vor meinen Server gesteckt hatte, musste ich einmal komplett runter und wieder hoch fahren. Danach konnte ich den Effekt, wie eigentlich immer, beobachten. Ich nutze keine User-Shares habe sie aber nicht abgeschaltet. Zum testen: 1.) Cache Dirs eleminieren. Einen User-Share in Plex eintragen der über mehrere Platten geht. Server neu starten. Spin-Down aller Platten. Zugriff auf Content - der nicht unbedingt auf der ersten Platte liegt. Alle Platten starten nacheinander. 2.) Cache Dirs eleminieren. Alle Platten des o.g. User-Shares als Disk-Shares in Plex eintragen. Server neu starten. Spin-Down aller Platten. Zugriff auf Content - der nicht unbedingt auf der ersten Platte liegt. Nur die eine Platte startet. Ist bei mir immer so.

Hmm, das ist genau eines der beiden Themen, die mich bisher davon abgehalten haben, den Server auf 6.11 final umzustellen. Dieses Thema ist wohl noch in 6.11 final enthalten. Da ist das Problem mit den Lese-/Schreibzugriffen wenn bestimmte GUI-Seiten geöffnet sind. Sowie das iGPU/AST GPU Problem bei z.B. Supermicro Motherboards. 100%-ig habe ich das Problem noch nicht verstanden, aber es hält mich definitiv vom Update ab.

Alles klar, danke.

Nein, den Server. Beispiel: Ich habe ein Skript welches täglich über alle Platten läuft und prüft ob Plex neue Metadaten (folder, fanart, etc) hat als die, die auf der Platte liegen. Wenn ja, dann wird die Datei ersetzt. Wenn ich das Skript nach einem Reboot des Unraid Servers das erste mal starte, dann wird jede Platte aufgeweckt und durchsucht. Beim zweiten Start des selben Skriptes wird keine Platte mehr aufgeweckt bzw. nur die, auf die etwas geschrieben werden soll. Das meine ich mit gecachten Verzeichnisstrukten bzw. Dateistrukturen. Wenn Du also von einem Klienten aus auf einen User-Share zugreifst (hinter dem sich - sagen wir mal - 4 Platten befinden) und deren Verzeichnis- und Dateistruktur sind nicht gecacht, dann wird Unraid unter Umständen jede Platte nacheinander hochfahren und suchen. Das passiert dann aber i.d.R. nur einmal. Deshalb liegen bei uns in Plex ausschließlich Disk-Shares. Plex ist das egal ob Du 100 Disk-Shares in einer Mediathek hinterlegst. Wenn nun ein Content benötigt wird, dann weckst Du garantiert maximal nur eine einzige Platte auf. Selbst wenn nix gecacht ist.

Ich nehme /tmp - nicht /dev/shm. @mgutt hatte das mit shm mal empfohlen, ich hatte das auch ausprobiert und dabei direkt irgendetwas gehimmelt. Bin dann wieder zurück zu /tmp und alles war wieder gut.

So weit bin ich noch nicht - die sind heute angekommen und ich habe sie direkt an die fetten Verbraucher geklemmt. Muss ich mal ausprobieren. Aber an den aktuellen Geräten nicht. Ich habe aber noch ein paar bestellt, kommen nächste Woche, dann werde ich das mal ausprobieren. Es geht darum, dass die immer ausgeschaltet starten, oder?

Vielen Dank nochmals für Deinen Tipp für diese Modelle. Nach mehrmaligen Versuchen habe ich doch dort kaufen und nach DE schicken lassen können. Die Dinger machen echt einen wertigen Eindruck. Habe sie mal spaßeshalber vor unseren Unraid Server und unsere Klimaanlagen gehangen.

Super. Hätte mich aber auch schwer gewundert. Hier transkodiert Plex seinen Content seit Jahren über /tmp ohne eine einziges Problem. Jedes mal wenn jemand aus der Familie in den Urlaub fliegt werden ganze Serien, Filme, über Plex heruntergeladen (und dabei transkodiert). Und Plex ist nicht der einzige Container. Hier sind alle /tmp Verzeichnisse (z.B. Nextcloud) auf das RAM umgebogen. Das möchte ich nicht mehr missen.

Nein, so pauschal würde ich es nicht sagen. Was aber bei größeren Systemen (viele Platten) bei Zugriff auf /mnt/user/ Shares vorkommen kann: Wenn die Verzeichnisstruktur oder deren Inhalt, aus welchen Gründen auch jmmer, nicht vom OS gecacht ist, dann wird jede Platte in diesem User-Share nacheinander hochgefahren und durchsucht. Das kann dann schon mal bis zu 15 Sekunden pro Platte Verzögerung bewirken. Wenn Du nur 1-4 Platten nutzt (ist keine offizielle Regel sondern nur mal so rausgehauen) dann geh ruhig mit User-Shares. Jetzt kennst Du einige der Gründe und kannst für Dich selbst entscheiden.

Die hat bei uns nicht immer funktioniert. Deshalb wurde sie gelöscht und WebDAV im ohnehin installierten Dateimanager+ eingerichtet. Movies in Nextcloud? Was will man denn damit? Dafür gibt es bessere Lösungen wie Plex und Konsorten. Wir haben den gesamten Content unter den beiden Spezialisten (Nextcloud, Plex) strikt aufgeteilt.

nobody ist der Standard-User unter Unraid. Ok fangen wir vorne an: Ich bin faul, nutze aus verschiedenen Gründen keine User-Shares und weiß was ich mache. Ich übergebe einen Disk-Share an den Container an die selbe Position: Meine existierenden Ordner trage ich in Nextcloud als Externe Speicher ein: Und da wir hier kein Hochsicherheitssystem betreiben nutzen wir den Standard-User nobody ohne Passwort als Zugang. Wer zugreifen darf lösen wir beim Externen Speicher in der Spalte "Verfügbar für": Das ist alles. Das Ergebnis sieht dann unter "Dateien" so aus: Unter Windows oder auch Android nutzen wir WebDAV als Nextcloud Zugang zu den Dateien, Den Link findest Du in Nextcloud unter "Dateien" in den "Einstellungen". Da Nextcloud i.d.R. ohnehin von außen erreichbar gemacht wird, hat das den charmanten Vorteil, dass Du mit jedem Gerät, von überall, auf Deine Nextcloud Instanz zugreifen kannst: Das hat den smarten Vorteil, dass die Dateien Unraid-konform mit dem User "nobody" auf der Platte landen. Es gibt noch einige andere Wege um Nextcloud zu konfigurieren. Wir nutzen es so seit Jahren:

Worauf zeigt "/mnt/share2"? Ist das ein lokaler Pool? Aus Deinem Post ging nicht hervor ob es sich um lokale oder remote Ordner handelt. Die vielen Worte zu SMB und CIFS verleiteten mich in die remote Ecke. Wenn das also lokal ist: nobody kommt dann in die globalen Anmeldeinformationen.

Es gibt verschiedene Wege - hier wie ich es machen würde: 1.) Unraid Plugin "Unassigned Devices", mit diesem werden SMB Zugänge "Unraid-konform" verwaltet. 2.) In den Nextcloud Container diese Zugänge (/mnt/remotes/...) als r/w/slave Path-Mappings aufnehmen. 3.) Diese Zugänge innerhalb Nextcloud als "External Storages" mit "nobody:" aufnehmen. Welcher Container: Ich nutze LSIO - benötige aber auch kein Online Office Tool wie in neueren Containern. Mir reicht das.

Ach so. Dann hatte ich Deine Frage falsch interpretiert. Alles gut.

Die Erkennung über die Fritzbox/Smartphones hatte ich hier aufgeführt. Ich würde gerne einen Helper nehmen - die nehme ich für solche Gruppen eigentlich immer - aber für die Anwesenheit habe ich das nicht lösen können: Ansonsten geht das in den Automatismen ziemlich einfach. Da gibt es einfach keine Grenzen. Da kannst Du dich voll austoben. Hab jetzt nix mit Strommessung - nur Stromproduktion. Läuft aber gleich:

Das meinte ich. Man muss draufklicken bzw. reinzoomen. Bei deCONZ sah die gleiche Installation so aus. Das fand ich besser: