alturismo

ich würde eher hier mein Problem schildern (englischer Thread) und du hast auch das plugin installiert für sr iov ?

Oder auf die 7.3 wechseln mit SSD boot wenn du keine USB Lösung mehr möchtest.

Das sieht nach einem ständigen Absturz eines containers aus. Schau dir mal die uptimes der container in der docker Übersicht an. Wenn klar ist welcher, richtig konfigurieren 😉

erstmal nichts ;) nur solltest du /mnt <> /mnt machen und nicht /mnt <> /mnt/user (container Pfad) ... geh da mal tiefer rein was da drin ist. und du hast luckybackup auch gestartet nachdem die remotes eingerichtet und mountet waren ?

sicherlich auch kein Schaden, aber ich schätze eher du hast zu viele Versionen übersprungen ... Nextcloud ist da bekanntermaßen "empfindlich", daher auch mein vorheriger Hinweis da du an sich nicht tief in der Materie bist würde ich eher vorschlagen entweder 1/ retour gehen auf die funktionierende Version, anstelle :latest den tag zu nehmen deiner Version, tag anpassen auf 30.0.5, danach release für release versuchen zu updaten 2/ alles nochmals neu aufsetzen und ab jetzt regelmäßig updaten, sauberer Start ... Hinweis, mariadb sollte bei einer konfigurierten Instanz immer laufen den "Step by Step" Weg usw, vielleicht im regulären Forum mal nach Unterstützung anfragen, hier im Anleitung Thread sollte das nicht behandelt werden.

das ist auch korrekt so, hast du update mal geprüft ? docker tab, linke maus click auf das icon, update ... bis ~ v27 waren die Updates "manuell" im Docker, seither ganz normal über das normale Update das letzte kam vor 2 Tagen

repository schauen, du hast wenn du keine automatische update Meldungen bekommst da "fixiert", zeig mal einen screen davon von den docker/s.

nun ja, das hört sich eher nach einem Hardware Problem an. würde auch bedeuten dass die Platte nicht in den spindown geht. Ich würde mal testen wie sich das verhält wenn die Platte direkt an einem der 2 Anschlüsse am Mainboard hängt anstelle an dem HBA Controller (sofern noch nicht getestet) Sicher das du 100 MB/S nicht mit 100 mbit/s verwechselst ? mal abgesehen das ein bond weg kann mit einer Netzwerkkarte, steht da mal zumindest die Standard 1G, was ca. 100 MB/s ++ Transfergeschwindigkeit wäre.

das wurde vor langem umgestellt und man updated den docker ;) da wird nichts mehr im docker als update ausgeführt. aber du weißt ja auf welcher Version du bist, kannst ja einfach wieder retour, sicherheitshalber backup des /appdata/nextcloud und des /data Verzeichnisses (je nachdem wie du es mountet hast) erstellen, dann kannst du wieder retour wenn was schief gehen sollte. Anmerkung, gerade Nextcloud und Updates auszusetzen ... keine gute Idee, das jetzt was schief geht ist eher möglich als wenn man regelmäßig updated.

wenn du das machst was dir oben gesagt wurde, dann siehst du ja den docker run, und ja ... den text kann man auch markieren und kopieren ... das muss kein screenshot sein Beispiel (als screenshot mit markiertem text) Beispiel als Text kopiert ...

einmal den btrfs pool wegsichern (beispielsweise auf das array), den pool in zfs neu aufsetzen, Sicherung retour spielen. den Ordner /mnt/cache/system/docker kannst du dir sparen, das wird alles neu erstellt wenn die Dockers wieder installiert werden inklusive der passenden Parameter, Start Settings liegen auf dem Stick, persistent Daten eh unter /appdata.

da sieht man in den aktuellen logs zumindest keine Issues lxc, nur den von dir benannten "nicht starten" Fehler, ich würde mal schauen was "foreground" effektiv aussagt. Anmerkungen 1/ bond (Netzwerkkarten Verbund) konfiguriert mit nur einer Netzwerkkarte, bei Gelegenheit mal umstellen 2/ deine Einstellungen zu pcie override und co, hatte ich ja schonmal angemerkt, egal 3/ Share settings (Achtung) ./system steht auf "cache yes", da liegt beispielsweise dein Docker Verzeichnis, Daten liegen auch verstreut auf cache und disk1, nicht unbedingt empfehlenswert, fairerweise passt hier zumindest die Share Einstellung in den Docker Settings mit /mnt/user/system/... .lxc steht auch auf "cache yes", da platzierst du beispielsweise dein lxc container usw, Daten liegen auch verstreut auf cache und disk1, nicht unbedingt empfehlenswert, kritisch ist hier jedoch, lxc ist "hart" konfiguriert auf /mnt/disk1/lxc/... abschließend noch, du nutzt einen btrfs cache pool, ich sehe jetzt zwar keine btrfs Fehlermeldungen, muss jedoch sagen das ich da auch nicht mehr groß weiter schaue da btrfs meiner Erfahrunf nach (leider) so oft alle möglichen Themen verursacht und ich da raus bin. Empfehlung, backup die relevanten Daten (sofern nicht vorhanden), setz den pool neu auf (wenn du Redundanz brauchst dann in zfs), richte Docker und LXC sauber ein, sowohl in den jeweiligen Einstellungen als auch die entsprechenden Shares dazu. Ansonsten, vielleicht sieht noch jemand etwas in deinen logs was relevant sein könnte.

wenn da keinerlei Meldung kommt ... mit "kein erfolg" kann man schwer Tipps geben ;) ich gehe mal davon aus du meinst im Docker Tab sind keine Docker ersichtlich ? Lad eher mal eine diagnostics hoch, dann kann jemand mal schauen was man so sieht.

mal versucht dein backup (sofern vorhanden) einzuspielen und dann den lxc zu starten. oder zumindest per cli im foreground mode zu starten was genau der Fehler wäre und was auch immer "docker verschlucken" heißen soll, vielleicht beschreibst du das etwas besser.

erstmal Danke für den workaround deinerseits, nur sollte man wissen das beispielsweise der erste Punkt schon immer so war 3 grundsätzliche settings erstmal (plugin Instructions Seite 1) Punkt 2 kann auch "all" sein, kann nur kritisch werden wenn man mehrere Karten verbaut hat, nur als Tipp. Zum Thema --security-opt seccomp=unconfined hier sollte erwähnt sein das man hiermit einiges an Sicherheit verliert, sollte nur genutzt werden zum debug um den Container sauber zu konfigurieren, beispielsweise mit einer custom_seccomp.json, würde eher sagen das gehört in den github des jeweiligen container maintainers wenn es jetzt Probleme damit geben sollte. Soll nur als Anmerkung dienen.

verständlich, also, folgender Eintrag "xml" damit hast du eine virtuelle Soundkarte die beispielsweise per RDP oder anderen Streaming Diensten normal funktioniert. VNC ist halt die miserabelste Art eine VM zu nutzen, wenn es dann noch noVNC aus Unraid direkt ist ... sicherlich nicht ;) das ist auch eigentlich nur zum Einrichten einer VM gemacht. Wenn du einen nativen VNC Server in der VM hast und dazu einen passenden Client, welche beide auch Audio unterstützen, dann könnte es auch per VNC gehen, ansonsten nimm zumindest RDP.

naja, das user script oben (der Einzeiler) macht ja nur eine Installation, so sieht es zumindest aus. Danach läuft die "Anwendung" jetzt nutzt du den onboard npm package manager, dafür ist das "normal" nicht gemacht, daher die Empfehlung das separat in einem Docker laufen zu lassen, wäre auch parallel der Test ob Unraid an sich da etwas macht oder das von Haus aus so ist.

davon ausgehend das du den Sound nativ an Lautsprecher reichen willst und keine GPU hat, ja, sollte gehen. Besser ist es hier einen kompletten USB pcie Controller an die VM zu geben, rein USB kann gerne zu "krachen" führen, testen ... wie verbindest du dich zur VM ? es gibt auch "virtuelle" Soundkarten wenn es keine hohen Ansprüche sind, sprich, was ist der "usecase" ?

mal abgesehen davon das du dir das erste cd .. sparen kannst ich mir das nicht vorstellen kann, ich schätze eher dass die app an sich da etwas hat (Lizenz Timer) Unraid hat meines Wissens nach keinerlei "Aufräumen" Timer laufen und macht da etwas selbstständig. Grundsätzlich, installier dir besser für so Sachen einen Standard Docker, Beispiel linuxserver ubuntu oder was auch immer, die haben auch eine eingebaute Start script Funktion um diverse Dinge beim startup laufen zu lassen, wäre die gesündere Variante anstelle das auf dem Host laufen zu lassen. So wäre dies in einer isolierten Umgebung und kann auch nichts kaputt machen ;) Ansonsten wäre die user script Variante schon richtig, nur nach 30 Tagen ... schätze mal eher das liegt an der playwright an sich.

das ist virtuell und bringt nichts ;) Fehlermeldung, entweder ist dein docker image voll, defekt, ... Defekt, passiert gerne bei btrfs, voll, meist ein falsch konfigurierter Docker. Das Image mal neu erstellen und die dockers wieder neu installieren, keine Sorge, Startparamter sind auf dem Stick, Konfigurationsdaten liegen in /appdata, ist danach wieder alles beim alten, nur als Info.

bei deinem aktuellen Verbrauch wäre das ernsthaft zu überdenken ;) Intel ist vor allem im idle deutlich effizienter, daher wäre dies auch eher meine Empfehlung 10G LAN, hast du entsprechende Infrastruktur dafür ? wenn nur der Server 10G kann bringt das ja nicht viel ... Fertiglösung oder Selbstbau, Geschmackssache, ich persönlich würde immer Selbstbau nehmen (da weiß ich was ich gemacht habe), aber das ist deine Entscheidung. Beschreibe mal besser den echten usecase, vor allem VM, damit steht und fällt einiges zum Thema Energie Effizienz (mit oder ohne dGPU sinnvoll) ebenso was die Dockers leisten müssen, Emby an sich mit etwas transcoding braucht ja nichts ... Empfehlung, 2. Gerät aufsetzen, wenn es nur Backup ohne Fallback sein soll muss es auch kein Unraid sein, schadet nicht, wäre aber eine zusätzliche Lizenz. Wichtige Daten, allgemeine Empfehlung, 321 Regel, wobei du das ja wahrscheinlich bereits nutzt mit OneDrive. Kurz, neues System rechnet sich sicherlich über den Zeitrsum, du hast jedoch auch sicherlich noch Potenziel dein System etwas effizienter einzurichten, bei dem Idle laufen sicherlich die Platten mit, wenn nicht dann wäre es schon sehr viel ;) Wenn du ein neues System aufbaust, könnte das vorhandene ja direkt als Backup dienen ... oder du verkaufst die Teile und holst ein kleines n100/m als Backup usw ...

entweder den aktuellen nochmals formatieren und die bestehende config aus der Sicherung übernehmen, dann braucht es auch keinen Lizenz "Umzug". Wenn das nicht gehen sollte, dann bleibt ja aktuell nur neuer Stick ;) und ach dem boot die Lizenz übertragen.

kurz, die AIO Lösung ist auch meiner Meinung nach "Kernschrott" ;) aber ich verstehe den Hintergrund, gern gelesen dass das die beste Lösung wäre, dann noch von einem gern genommenen Unraider, absolut verständlich. du hast keine Kontrolle und da werden intern dockers angelegt (wie du auch bei Updates in deinem log siehst), Daten mit allen möglichen Rechten vergeben, usw usw Beispiel, du willst "reset" machen, dazu muss man da dann intern images manuell löschen oder am Besten Docker komplett löschen und alles neu machen, wenn da einmal der Wurm drin ist ... ist es halt kritisch. Ich tippe hier langsam eher auf ein Hardware Problem in irgendeiner Form, sowie da Activity kommt usw crasht dein System leider anscheinend "lautlos". Du hast ne Menge Komponenten verbaut an Controller und co, da nirgends ein echter Fehler kommt ist es leider schwer zu benennen.

es sollte doch onboard sein ... gib mal im terminal inotifywait ein

beschreib mal was du meinst bitte. Server nicht mehr erreichbar ? Dienste nicht mehr erreichbar ? (Dockers, smb, ...) Harte Neustarts aus dem Nichts ? in den logs ist jetzt nicht wirklich was drin wo ganz klar wäre was ... diverses was macht der Client da wieso diese Einträge als Fritz User und ipvlan, wenn da eine andere IP noch läuft ist ipvlan bei Fritz kritisch usw usw, aber sag mal bitte an was genau du meinst mit "crash"