mgutt

Which is useless as it refers to installing MySQL inside an usual OS and not using a container. As I said. I don't think any single additional step is needed, except setting database name, login and password in the container settings and using this information in Kodi to connect to the database.

Ja so. Schon was Neues dazu?

Ja, wenn Docker auf Nein steht, sind diese Dateien nicht in Nutzung. Das ist mir wirklich unverständlich, wenn du nur Cache von prefer auf yes gestellt hast. Aber ist jetzt leider so und es müssen die doppelten Dateien weg, ansonsten wird das nicht mehr sauber laufen. Hatte ich schon angemerkt, dass man zumindest Backups von Appdata auf das Array machen sollte? ^^

I don't think any of these steps are needed. Why should it be needed to use "GRANT"? INSERT, SELECT, UPDATE, etc are default commands which are already granted. And of course the MariaDB Container is already bound with its port to the IP address?! So what is the error message if you use the container as it meant to be?

Bearbeite die XML Dateien auf dem Stick und ersetze überall /mnt/cache_nvme_protected gegen /mnt/user Danach noch mal das Kommando ausführen und schauen, dass du nichts übersehen hast. Das ist erstmal die sicherste Variante, weil er dann die Dateien findet, egal ob sie gerade auf Pool oder Array liegen. Ich weiß allerdings nicht, ob das auch über mehrere Pools hinweg gilt ( @ich777 weißt du das? ). Aber da du Dopplungen hast, musst du die sowieso zuerst lösen. Ja. Prüfe einfach 5 Dateien oder so. Es sollte sich schnell ein Bild ergeben wo die jeweils aktuellere Datei liegt. Wenn du das dann weißt, kannst du die jeweils ältere löschen. Sind das sehr viele? Dann würde ich dir da noch ein Kommando bauen. Sag mir dann nur welche Pfade betroffen sind. So auch für exakte Disknummer.

Wie du siehst, nutzen mehrere Container den SSD Pool direkt. Also starten ist nicht, solange nicht dieser Pool wieder mit seinen Dateien da ist. Welche Dateien von den doppelt vorhandenen, sind denn neuer? Die auf dem Array oder die auf schreibcache?

Jo, einfach Copy & Paste

Ja, wobei die sich überschneiden dürfen. Also evtl gehen auch 50, wenn die Auslastung im Schnitt geringer ist. Ansonsten würde ich auch eher mehr Kerne als mehr Takt favorisieren. Ein Intel der 13ten hätte ja zb auch noch die Effizienzkerne. Ansonsten wäre mir spontan mein W-1290 eingefallen oder analog der i9-10900.

Davon ist auszugehen. Auch das passiert eigentlich nur, wenn man zwischen only/no und yes/prefer im laufenden Betrieb wechselt oder eben die Containerpfade direkt auf /mnt/<poolname> eingestellt hat. Prüfen wir erst mal letzteres. Und zwar so: set -o pipefail while read -r file; do echo -e "\nSearch for non-user paths in $file:" if ! grep -F '/mnt' "$file" | grep -vF '/user' | grep -oE '/mnt/[^<"]+' | sort -u; then echo "Not found." fi done < <(find /boot/config/plugins/dockerMan/templates-user -name '*.xml') Er sollte im Idealfall überall "not found" ausgeben.

ja dann keine Ahnung 🤷😅

Jo, Unraid ist der Unterbau egal Wenn das so wäre, wäre das der Jackpot, denn die Grafikkarte könnte man sogar noch verkaufen. Aber so Recht glaube ich da nicht dran.

Ok, also früher ging es nicht anders.

Ich habe noch mal intensiv gesucht. Es scheint wirklich so zu sein, dass der Vorgänger vom M920q, also dein M910q, doch keinen PCIe Slot hat. Das tut mir echt leid. Ich dachte ich hätte alles genau recherchiert, aber dann bin ich wohl doch über Bilder vom M920q gestolpert. Siehe zB hier: https://www.servethehome.com/lenovo-thinkcentre-m920-and-m920q-tiny-guide-and-review/lenovo-thinkcentre-m920q-tiny-internal-view-wifi-m2/ Demnach scheint von dem alten Modell nur der M910x über den PCIe Slot zu verfügen. Wobei es den komischerweise quasi für das selbe Geld gibt (159 €): https://www.refurbed.de/p/lenovo-thinkcentre-m910x-tiny/ Ich würde daher noch mal durchtauschen.

The Docker Engine is already running or don't you have any dockers? And a container itself does not produce any relevant overhead as processes are executed natively on the host. Which means: It's absolutelly the same running an application inside a container or on the host. But there is a major impact in security. Using the Unraid root login on an external server is kinda risky, not to say dumb. Even if you use SSH public key exchange, you finally allow the external machine to act as root user on your Unraid server. One of the reasons why I'm using the rsync container is to mount any path read-only. By that I'm able to pull all files, without being able to delete/change them, which makes it safe against ransomware attacks. Conclusion: Security > Comfort.

Das Problem ist, dass sie 2x existiert. Das darf gar nicht sein. Entscheide dich welche du behalten willst und lösch die jeweils andere. Warum ist die bitte so groß? Und sonst: Vom Prinzip kannst du das docker.img auch einfach löschen. Also beide Dateien. Das kann jederzeit neu erstellt werden und enthält keine relevanten Daten. Nach Neuerstellung einfach über Docker > Add Container die Container wieder hinzufügen.

Ja. Aber wozu solltest du den Job vom Mover machen. Dafür ist der doch da. Mover logs aktivieren, Mover starten und in Tools > syslog schauen was der Grund ist.

Steht in den Logs von dem Skript evtl etwas von Fehlern? Ich kann mir das nur mit irgendwelchen Berechtigungsfehlern erklären. Gehört die perms.txt auf der Quelle auch dem User root?

Yes heißt nicht, dass der Cache permanent genutzt wird. Also ich denke mal das ist deine Cache Einstellung des Shares.

Nein auf keinen Fall Docker starten. Erst müssen alle Dockerpfade /mnt/user lauten (erweiterte Ansicht aktivieren und alle Pfade aufklappen und sichten). Auch müssen alle Dateien auf das Array. Einfach damit dein aktuelles Problem nicht nachher alle Container zerschießt. Die Container suchen ja laut deiner aktuellen Einstellung die Dateien auf nvme und Array und nicht auf Schreibcache. Das kann böse enden, wenn da plötzlich teilweise Dateien "fehlen".

VMs nicht, weil die ja nicht mehr nutzen können als die vDisk groß ist. Stellt man Shares auf Prefer oder Yes, hat man auch kein Problem, weil dann auf das Array ausgewichen wird. Aber klar, so oder so sollte kein Container nach Docker schreiben. Dann ist halt einfach was falsch eingestellt.

Dann hast du was falsch verstanden. Wenn du Verzeichnis wählst, gibt es keine vDisk, sondern Docker schreibt seine Dateien direkt auf den Datenträger in das besagte Verzeichnis. Und es wird nicht der gesamte Cache vereinnahmt, sondern nur so viel wie die Dateien belegen. Also wenn du nicht gerade irgendwas verbockt hast, sogar weniger als bei der vDisk. Beispiel von meinem Server: # du -hs /mnt/cache/docker 12G /mnt/cache/docker Mein Docker-Verzeichnis belegt also "nur" 12GB statt 20GB. Check ich nicht. Wieso Arbeitsspeicher?! Verzeichnis vs vDisk Was ist nun besser? Natürlich Verzeichnis. Kein Stress mehr mit der Größe, weniger Belegung, weniger Overhead (weil nicht erst eine vDisk gemountet und darin Dateien geschrieben werden müssen) und es kann das Dateisystem in der vDisk nicht kaputt gehen (passiert auch gerne mal), weil es eben keine mehr gibt... Faktisch ist die vDisk also Nonsense. Um genau zu sein weiß ich nicht mal warum man bei Unraid die vDisk früher zum Standard gemacht hat. War eine blöde Idee und gehört meiner Ansicht komplett weg.

Ich denke nicht, dass man bei Folder das Dateisystem ändern kann. Dann gilt einfach das, was der Datenträger selbst hat.

Wie gesagt ist das rein technisch schon nicht möglich, weil das Mover Skript nur zwischen Pool und Array und zurück verschieben kann. Wenn wurde es auf das Array und dann zurück auf die SATA SSD verschoben. Das hätte aber zwei Mover Durchläufe gebraucht. Oder benutzt du irgendein Plugin wie Mover Tuning? Wie auch immer. Wenn appdata jetzt auf "schreibcache" liegt, muss dieser Cache ja auch beim Share appdata ausgewählt worden sein. Also beim Share den Eintrag "Select cache pool". Da sollte bei dir "schreibcache" stehen. Noch eine Möglichkeit wäre. dass du die Container bearbeitet hast und bei den Pfaden direkt /schreibcache hinterlegt ist. Ich habe da zB /cache direkt hinterlegt: Allerdings würde das erst greifen, wenn die Docker laufen und natürlich sollte man niemals versuchen seinen Cache zu leeren, wenn man solche Anpassungen gemacht hat. Siehe auch: https://forums.unraid.net/topic/99393-häufig-gestellte-fragen/#comment-1223263

Das sind vermutlich virtuelle Docker Laufwerke. Ich habe noch mal umgebaut: #!/bin/bash while read -r type size usage free percent path; do if [[ $percent =~ (100|9[0-9])% ]]; then logger -t Devices "Error: $path ($type) uses $usage of $size and only $free ($percent) are left!" fi done < <(df -h -B GB | tr -s ' ' | cut -d ' ' -f 1-6) Wir hatten bisher "type" ausgegeben. Für dich relevanter ist aber "path". Beispiel nun von mir: Error: /mnt/disk1 uses 17160GB of 17999GB and only 839GB (96%) are left! Error: /mnt/disk2 uses 17057GB of 17999GB and only 942GB (95%) are left! Error: /mnt/disk3 uses 16824GB of 17999GB and only 1175GB (94%) are left! Error: /mnt/disk4 uses 17232GB of 17999GB and only 767GB (96%) are left!

Wenn du alle in den selben Ordner sicherst, kann das auch nicht funktionieren. Das Skript sucht ja in dem Ordner nach dem letzten Backup. Das letzte Backup ist dann zB zufällig das vom /boot Verzeichnis. Du sicherst aber gerade irgendeinen anderen Share. Er findet nichts in dem letzten Backup was dazu passt und erstellt es komplett neu. Fazit: Die Zielverzeichnisse müssen pro Quellverzeichnis unterschiedlich sein.