alturismo

mWn ist der einzig stabile Weg in der Konstellation, eine pcie USB Karte und diese dann komplett an die VM durchreichen, daran dann die USB devices.

was problemlos gehen sollte ;)

wird nur spannend mit den Laufwerken ... sda-z ;)

ich hoffe mal nicht ;) und wenn ich solche dockers sehe wo die app an sich schon aus 2 dockers besteht ... dann 1x redis und 1x postgis datenbank ist halt einfach design Frage, wenn man stumpf lieber yaml Dateien bearbeiten (noch besser, einfach damit starten will) will und mit compose up starten will ist compose fein, wenn man lieber selber Herr sein will und auch weiß was, wie, wo ... dann ist die single Lösung wahrscheinlich die bessere Lösung, ich persönlich würde für nichts auf compose setzen, aber verstehe das "fire & forget" nach compose up "charmant" ist bei solchen dockers. aber der TE kann sich ja einfach portainer, dockhand, ... installieren, greifen ja stumpf auf den docker sock zu zur Verwaltung, alles gut.

früher habe ich mal damit etwas experimentiert und es hat immer funktioniert, folgenden Eintrag musste ich jedoch als Start Parameter Unraid ergänzen ob es für deinen usecase mehr benötigt kann ich nicht beurteilen, hier war es "Spielerei" mit docker on windows und vgpu Nvidia VM in einer VM, hat alles funktioniert, nutze ich aber alles nicht mehr ;) wenn ich kurz nachlese, ggf. noch folgendes in der VM xml anpassen, cpu mode ich würde aber erstmal nur mit dem nested Eintrag starten. denk dran, backup der vdisk und der xml !!!

ich fang mal vorne an, hierher verschoben da ... Lizenz Datei aus dem /config Ordner vom Stick sichern, den Rest in dem Ordner löschen, starten, alles auf Anfang. Nein, docs lesen ... der Satz hat keinerlei Sinn ... RAM hat nichts mit disks und Parity usw ... by design, es gibt smb / nfs user dann hat dein Stick wohl ein Problem wenn die config nicht bestehen bleibt siehe 1. Rest lasse ich jetzt unkommentiert ;)

ich kann es nicht bestätigen, 4 n100(m) Systeme, alle laufen mit 3200 (32GB), keinerlei Fehler.

und du bist sicher es nicht bereits installiert zu haben und nur nicht aktiviert zu haben ?

Nachtrag, bitte keine support Anfragen wenn es hier mal klemmen sollte, es "komisches" Verhalten gibt, usw ... USB für Array ist halt grenzwärtig, kann gut gehen, oft leider nicht ... ist bekannt und von daher weißt du was du da machst.

getrennt wenn du es splitten willst, dafür keine Redundanz Raid1 wenn du bei einem Ausfall nicht damit leben kannst erst nach Backup einspielen wieder alles verfügbar wäre Backups so oder so nicht vergessen !!! Ich nutze keine Raid pools, aber "Glaubensfrage" Docker Dienst stoppen appdata verschieben auf den ssd pool appdata Share umstellen auf primary ssd pool, secondary none Docker Dienst starten immer davon ausgehend du hast nichts manuell verstellt und alles steht auf /mnt/user/... ansonsten Docker ggf. korrekt einrichten wenn du nicht /mnt/user/appdata nutzen solltest, ebenso die einzelnen Dockers falls du da was manuell umgestellt hattest.

naja, außer "geht nicht" steht da nicht viel in deinem Post ;) der nicht benannte docker hat logs, paperless hat auch log Daten, diese mal anschauen was für Meldungen kommen wenn es "hängt" Damit dann mit einer Beschreibung was, wann, ... passiert im passenden support Thread oder im git von paperless mal anfragen wäre ein Ansatz.

naja, dann geh retour, tools, update OS, previous version ... das deutet auf DNS Probleme hin ja, das ist keine gute Idee, du hast dir die Frage ja selbst beantwortet ;) wurde auch oft thematisiert und es wird nie empfohlen den Server hinter einen adblocker zu setzen, schon gar nicht wenn dieser auf dem Server läuft ...

müssen, Nein, entweder am Ende nochmals schauen ob Filme, Serien, was auch immer du meinst dann doch noch auf den "alten" gelandet sind und dann halt nochmals die paar Sachen dann verschieben, oder ggf. vorher rausnehmen aus den jeweiligen Shares.

was du da siehst ist "eigentlich" die Automatik das wenn der "Host" Container neu startet die "Client Docker/s" sich automatisch rebuilden ... sprich, da solltest du nichts mehr manuell machen müssen (früher war es normal das man da Hand anlegen musste). normal sollte ein rebuild auch nicht nötig sein sondern simpel, docker stop ... docker start ... (D2) oder docker restart D2 ;) probier es mal aus.

mal vorne angefangen hier ist zumindest keine "pool" (cache) disk vorhanden ... und was wäre der Inhalt von /mnt/disks ... sind da deine array disks zumindest drin ? und ist das array überhaupt gestartet ? Fehlermeldungen deuten auf den ersten Blick auf ntfs hin, ist die "neue" Platte nicht formatiert worden ?

das ist die Restore on Power (loss) Funktion schätze mal bei dem Board das Setting hier sprich, sowie Strom kommt (nach Trennung), Power ON.

gerade gesehen ;) ja ... vorher darunter den Haken setzen "vdisk löschen" und unten bestätigen ,,, dann ist erstmal clean und auch die erste Frage beantwortet. also kurz, es ist alles da und es steht auch da ;) und fast alle Felder haben sogar eine Hilfe, mouse over ... Text, dann geht oft ein ? auf, dann click ...

Hop ... wenn STOP, dann nochmal ... in dem screen ist es an, aber ich schalte hier keine services aus nur um ...

dort wo du den Service stoppst ... dort wo du den Service stoppst ... nachdem du auf Verzeichnis (directory) umgestellt hast geht auch ein Pfad mach mal Service stop, schalte advanced view an, zeig mal einen screenshot

@_alo_ hat es ja fein auseinander gedröselt ... kurz, ein compose ist gewachsen aus "stacks", sprich, dockers (apps) welche auf andere dockers (apps) angewiesen sind oder sogar in Reihenfolge abhängig sind, um nicht diese jeweils einzeln zu starten, anlegen, ... nutzt man compose um beispielsweise die diversen dockers "in einem Rutsch" durchzustarten ... viele nutzen es weil man "meint" es wäre einfacher, ich persönlich sehe da nicht wirklich einen Vorteil bei einem System was bereits einen eigenen Docker Manger mitbringt und man auch die Reihenfolge bestimmen kann, Versatz einrichten kann, usw ... aber das muss jeder für sich entscheiden. Das "Ergebnis" ist am Ende das Gleiche, compose nutzt in der Regel ein compose file was ich händisch anpasse und beispielsweise mit dem compose plugin starte (compose up), im "Standard" nutze ich die vorgefertigten Images und richte die zueinander passend an wenn Bedarf,es sind am Ende die gleichen Dockers, nur werden die Start Parameter anders konfiguriert (compose vs docker run). Und warum nicht die "bedingten" apps in einem Docker vereinen ... das gibt es ja auch, widerspricht am etwas dem docker "spirit", jede App an sich im eigenen Docker ... beispielsweise redis, sql's, ... könnte man auch in den jeweiligen docker ja migrieren, aber wie erwähnt ... Glaubensfrage und daher werden gerade die officials immer separiert betrieben.

Standard sind es 20 GB, du hast es wohl vergrößert ;) Kurz, Docker Service Stop, Image löschen, Größe definieren, Docker Service Start, Dockers wieder installieren ;) und selbst 17 sind schon was, was hast du denn so alles am Laufen ?

zuviel KI ... ? da gibt es nichts zu machen, schon gar nicht per nano an irgendwelchen config files "schrauben" ;) Vorteil, 1 Layer weniger da direkt auf Platte, weniger anfällig bei btrfs ... Nachteil, du merkst Fehler evtl. erst später ... Bsp. falsch konfiguriert schreibt ins "Image" anstelle in appdata, dann kann ein falsch konfigurierter Docker den gesamten "cache" voll schreiben und nicht nur das Image, worst case, System bleibt komplett stehen und nicht nur die Dockers ;) also, Umstellung auf directory, ja, wenn man weiß was man macht und das letzte etwas performance rauskitzeln will, wenn du aktuell bereits 200 GB für ein Docker Image reserviert hast (und brauchst ?) läuft wahrscheinlich eh was falsch ;)

das "Verzeichnis" zu sichern macht mal grundsätzlich 0 Sinn, das nur vorweg ... das Image übrigens auch nicht wirklich, aber das geht zumindest schnell ;) naja, dann hast du aber nicht wirklich geschaut oder gelesen ;) Kurzfassung, Docker Service Stop, Image löschen, Umstellung auf Directory mode, Pfad angeben wenn default nicht gefällt, Docker Service Start. Dann die Dockers einfach wieder installieren ... entweder Docker Tab, unten, add container, oben mittig, dropdown, unterhalb user templates sind deine gespeicherten templates, Alternativ CA Appstore previous apps ... und um es klar zu machen, weder im Image noch im Directory (Verzeichnis) ist etwas persistent relevantes ... sprich, da liegt nur die base ... Start parameter sind auf deinem Stick, die relevanten persistent Konfigurationen usw liegen unter /appdata, diese gilt es zu sichern ... das Directory zu sichern ist wie Windows Laufwerk C:/Windows kopieren (mehrfach, jeder Docker ...) ... dauert ewig, macht bei Dockers wie beschrieben 0 Sinn, aber hey, du lernst was dabei ;) Diese Dateien da drin werden beispielsweise auch bei jedem Update gelöscht und neu erstellt ... es ist schneller das neu zu machen anstelle copy, recover ... beim image geht es ganz flott, aber das "corrupted" gerne mal eher ...

Unraid an sich ist "sehr schlank" aufgestellt, also ja, Absicht ;) wenn man zusätzliche packages installieren will das install package besorgen und auf den stick unter /extra ablegen, dann wird es bei jeden Neustart immer mit installiert, ist in der shell und man muss nichts "basteln"

sorry, but this would be a mix of simple mover (mover tuning) and Media caching ;) so nope, not really planned. what will be included in next release min free space on cache using mediaservers last playback instead FS last access (as zfs is really disturbing here, i knew its not my FS ...) multi Media Server Mode here im still on investigating howto handle last played states and cleanup ... i really wouldnt like to build sep. lists for each Media Server currently it will end into a race condition when multiply Mediaservers are included more flexible source setup, so also zfs pools (again) are handled but as mentioned, no extra free space options ...