mgutt

In Linux gibt es zwar keine Vererbung der Rechte von einem oberen Ordner, aber um die Unterordner erreichen zu können, braucht man mindestens das Ausführungsrecht (x):
https://unix.stackexchange.com/questions/13858/do-the-parent-directorys-permissions-matter-when-accessing-a-subdirectory
 
Die Standardrechte von /mnt sind diese:

 
Der User root hat also "rwx". Also lesen/schreiben/ausführen. Dann folgt die Gruppe mit "r-x", dh die Gruppe root darf lesen/ausführen und dann folgt "r-x" für alle anderen. Demnach darf jeder User jeder Gruppe alle Unterordner in /mnt einsehen.
 
Bei dir sehen die Rechte von /mnt aber so aus:
drwxrwx--- 6 nobody users  
Mit "rwx" darf der User "nobody" alles und die Gruppe "users" ebenfalls. Aber der Rest der Welt darf bei dir wegen "---" nichts.
 
Die simple Frage ist nun: Warum sind deine Rechte von /mnt kaputt?
 
/mnt wird beim Booten erst erstellt. Es muss also etwas sein, was nachträglich die Rechte ändert. Teste vielleicht mal ohne Plugins zu booten (Boot-Menü).

Dann:
- ist der neue Pool leer? Wenn da jetzt Misch-Masch ist, bekommt man ein Problem. Wenn leer:
- die Shares system, appdata und Domains den Pool "Cache" wählen und die Methode "Ja"
- VM und Docker auf Nein
- Mover starten
- die shares werden nun auf das Array verschoben
- prüfen ob der Cache Pool leer ist (Ordner-Symbol), wenn leer:
- nun bei den Shares den Cache Pool auf "Docker" ändern und die Methode "Prefer"
- Array Stop
- Array Start
- Mover starten
- jetzt werden die betroffenen Shares auf den Pool "Docker" verschoben
- prüfen ob das Array, was die Shares anbelangt, leer ist, wenn leer:
- Docker und VM auf Ja
 
Wegen dem Befehl: Du hast nicht gefragt ob "docker" groß oder klein geschrieben wird. Wäre es groß, würde mit deinem Befehl alles im RAM landen (und beim ersten Kommando sogar die Ordnerstruktur zerlegt), der Server crasht und die Dateien sind weg. Noch eine Problematik ist, dass du davon ausgehen, dass er garantiert das Terminal offen lässt bzw garantiert eine bestehende Netzwerkverbindung zum Server hat. Unterbricht das Kommando, dann stehst du nämlich mit partiellen Dateien da. Es hat schon seinen Grund warum ich immer wieder vorbete die integrierten Funktionen von unRAID zu verwenden.

Die erste GPU ist die primäre Karte. Die nimmt sich unRAID. Die zweite Karte wird von gar nichts genommen. Die ist also im Betriebsmodus und wartet darauf, dass sie per Treiber angesprochen wird. Daher die zweite an VFIO binden und dann zb an eine Ubuntu VM binden und diese starten. Ohne VM ist die GPU wieder heimatlos und dreht auf. 

Ich werde ehrlich gesagt nie verstehen warum New Permissions überhaupt auf appdata angewendet werden darf.
 
Unnötig.
 
Verstehst du falsch. Das docker.img ist absolut unwichtig und enthält keine Nutzerdaten. Darin enthalten sind die heruntergeladen Containerdaten und die installierten Container. Klingt wichtig, ist es aber nicht, denn Container sind extra so aufgebaut, dass Betriebsystem/Apps und Nutzerdaten streng getrennt sind. Sogar bei einem simplen Update eines Containers wird dieser komplett neu installiert. Auch wenn du etwas an den Container Einstellungen änderst wird der Container neu installiert.
 
Du musst dir das so vorstellen als würdest du Windows zurücksetzen, aber alle deine Dokumente behalten (nur bei Windows geht es nicht so cool wie bei Docker, dass danach auch die installierten Programme und deren Einstellungen erhalten bleiben).
 
Daher solltest du "System" nicht sichern und natürlich auch nicht nach appdata verschieben. Mein Share heißt übrigens plump "docker" und ich nutze die Verzeichnismethode. Dann hat man niemals Probleme mit einem wachsenden Docker Image und auch weniger Write Amplification.
 
Siehe auch:
 
https://forums.unraid.net/topic/99393-häufig-gestellte-fragen/?do=findComment&comment=1010632
 
 
https://forums.unraid.net/topic/112617-ssd-abnutzung-maßgeblich-reduzieren/
 
 

Siehe Fritz!Box. Du hast in den Netzwerk-Einstellungen einen DHCP Bereich:

 
In meinem Fall wäre alles unter .30 und alles über .208 außerhalb des DHCP Bereichs. 
 
Das hat aber nichts mit deinem 1G Problem zu tun. Ist nur damit du saubere feste IP-Adressen verwendest. Der Grund ist, dass die Fritz!Box irgendeinem anderen Client in deinem Netzwerk die .31 oder .55 geben kann und du mit deinem Server die aber auch haben willst. Solche Konflikte vermeidet man, in dem man außerhalb des DHCP Bereichs bleibt.
 
Sorry, ja ist ja auch logisch, weil Du die .1.55 vergeben hast. Die befindet sich im Netz der Fritz!Box. Wie gesagt muss die direkte 10G Verbindung eine IP aus einem anderen Adressbereich erhalten, ansonsten wird alles über die Fritz!Box geroutet. zB 192.168.2.55
 
Wobei ich gerade nicht weiß welche IP-Adressbereiche die Fritz!Box alles verwendet. Die hat ja eigentlich 192.168.178.x und dann noch 192.168.179.x für Gäste. Warum hast du überhaupt 192.168.1.x?

Ja:
https://quickbox.io/knowledge-base/setting-up-cloudflare-and-plex-cdn/
 
Vom Prinzip ändert sich dadurch ja nichts außer dass man bei seiner Domain einen anderen Nameserver einstellt (den von Cloudflare).
 
Das Problem wurde damit übrigens tatsächlich gelöst. Irgendwie scheint die Plex Samsung TV App immer eine sichere Verbindung aufbauen zu wollen, wenn transcodiert wird (egal ob man unsichere  in den Einstellungen gesetzt hat) und das schlägt dann offensicht bei Let's Encrypt fehl.
 
Ich muss mir jetzt nur noch was basteln, dass meine öffentliche IP bei Cloudflare automatisch im DNS landet. Aktuell habe ich die nur manuell eingetragen.
 

Nein, aber Unraid hat einen unlösbaren Bug, der beim Verschieben die Dateien nicht auf einen anderen Datenträger verschiebt, sondern diese auf dem ursprünglichen belässt. Dadurch greift die Cache "No" Geschichte leider nicht.
 
Um dein Ziel zu erreichen wäre daher "Yes" besser. Also verschieben.. Bug greift und dank "Yes" verschiebt der Mover dann aufs Array.
 
 
Oder du verschiebst nicht von /mnt/user/share_prefer nach /mnt/user/share_no, sondern von /mnt/cache/share_prefer nach /mnt/diskX/share_no. Der Bug existiert nämlich nur im Pfad /mnt/user.
 
Ursache für den Bug ist, dass für Linux selbst nicht bekannt ist, dass hinter /mnt/user mehrere Datenträger stecken können.
 
Und damit du das auch gleich weißt: Es gibt noch einen unlösbaren Bug. Hast du zB die Datei /mnt/share_prefer/datei.txt und verschiebst sie nach /mnt/cache/datei.txt, dann löschst du die Datei, weil Quelle und Ziel identisch sind. Daher niemals zwischen Share-Pfaden (/mnt/user) und Disk-Pfaden /mnt/poolname oder /mnt/diskX) Dateien transferieren.
 

fd Adressen sind lokalen IPv6. Da müsste man mal das Script anschauen und bei mehreren IPv6 entsprechend rausfiltern. Es können übrigens noch mehr als zwei sein.