alturismo

ja ... jetzt aber nochmal "ernsthaft" ... du installierst dir parity check tuning, du setzt Temp Werte wann es pausieren soll ...
 
das ist per default aus, sprich, du hast das eingerichtet .... (ich nutze das auch bei Temp X)
 

 
oder es sind andere settings aus dem plugin ... (ich lasse den auch in increments laufen)
 

 
und wunderst dich jetzt warum das dauernd pausiert ?
 
wenn dich das stört, deaktiviere es ... oder deinstallier das plugin wenn du das nicht willst, macht ja keinen Sinn

Alternative falls deine "Apps" sich nicht auf einem smb Share installieren lassen sollten, du kannst auch eine 2. vdisk (== 2. HDD im System) erstellen und in der VM einbinden, da dann deine "Apps" installieren ... das entspricht deinem früheren setup (die 2. vdisk kann natürlich im Array liegen auf der HDD).
 
das alles kannst du so machen wie es Dir gefällt

ganz sicher nicht
 
du hast "wahrscheinlich" mal aus Versehen den Share angelegt indem du den Pfad beim Docker hinterlegt hattest, dann Docker gestartet (jetzt werden die Ordner angelegt) ... und erst dann den Share auf "cache only" umgestellt hast ... von Haus aus gab es den Share nicht.
 
wenn deine Docker alle laufen (im cache only Betrieb) ... dann im Unraid Terminal
 
rm -r /mnt/disk1/docker  
das entfernt den Ordner samt Inhalt auf disk1 komplett ...

oder du hast auch das mover tuning plugin installiert und Regeln eingestellt das erst ab xy % sich was bewegt ...

beim Start springen immer alle Platten erstmal an ... dann einfach spindown einstellen, dann gehen die Platten nach dem Setting ohne Aktivität in den spindown und gehen erst wieder an bei Bedarf ...
 

 
wenn das eingestellt ist (was es per default nicht ist) und deine Platten nicht ausgehen sollten, lies dich bitte ein ... es gibt einige Threads zum Thema spindown und meistens sind es falsch konfigurierte Shares wo dazu führen ... 

du wirst wahrscheinlich die m3u umschreiben müssen ... m3u8 sind halt "Wundertüten"
 
Beispiel nach einer google Suche mit Jellyfin obs livetv
 
 

wie in dem Link beschrieben, Docker Tab, Add Container, oben das dropdown unterhalb "user templates" (da sind deine Voreinstellungen deiner bisher installierten Docker mit deinen Einstellungen zu dem jeweiligen Docker), installieren, fertig.
 

 
schon klar, war auch nur ein Beispiel zur Lösung wie man einen Docker installiert und die Erklärung dass diese dann wieder da sind ohne Datenverlust, selbst wenn man den Docker selbst löscht ... und ja, das verlinkte Topic war nur ein Beispiel, die Antwort aber zutreffend zu deiner Frage.
 
Überhaupt mal angeschaut ?
 
Abschließend solltest du schauen warum das passiert ist, wenn deine Docker auf einmal weg sind hat das meist einen Grund, Beispiel defektes Docker Image (btrfs) und dann sind wir auch bei Image löschen, Docker wieder hinzufügen ohne Datenverlust ...

liegt ja bei 64 % Speicherplatzbelegung
 
wenn du uns jetzt noch verraten würdest wie dein Docker eingestellt wäre ... könnte man ggf eine Aussage treffen ...
Docker Image (Größe ?), Docker Directory ... (Laufwerksgröße und Belegung wo das Directory liegt ?) ...
 
wenn (ich spekuliere jetzt) das Image wächst kann es sein dass einer (oder mehrere) Docker Daten innerhlab schreiben anstelle in Ihr appdata ...
entweder falsch konfiguriert (Pfade im mapping ODER innerhalb der App) ... oder einfach weil die entsprechende App das macht ...
 
die Auslastung hat nichts mit RAM zu tun, sprich, egal wieviel Ram du oder er hat, die 64 % sind die Belegung "auf der Platte",
abhängig davon jetzt wie dein Docker eingerichtet ist ... kurz, der Vergleich ist irrelevant
und gleiche Anzahl Docker hat ja auch nichts zu heißen, siehst ja selbst wie stark das abweichen kann ...
 
können weg, das sind "orphan" Images welche nicht mehr in Benutzung sind ... kommen in der Regel durch "wilde" Repo Wechsel (manuell ...)
 
Zusammengefasst, du wirst auch einiges hierzu finden wenn du im Forum danach suchst, auch wie schnell sowas passieren kann durch falsche Konfiguration, am Ende bleibt meist nur ein Löschen (Image, Directory), Reinstall und dann beobachten welcher Docker wirklich verantwortlich ist sofern es bei Dir überhaupt ein echtes Problem ist, siehe erste Antwort ... je nach Setup ... um es banal zu machen, bei Docker Directory wird da immer die Auslastung der Platte stehen,  Beispiel cache Drive ...

Nein
 
auch Nein, es liegt irgendwo an einer falschen Einstellung, sei es innerhalb der App oder an einem Mountpoint welcher nicht existiert auf dem Host.
 
Beispiel, wenn du in einer App einen Pfad als Ziel eingibst welcher nicht existiert ... dann schreibt die App innerhalb des Images Daten anstelle des gewünschten Pfades ... und das kann jetzt alles Mögliche sein ...
 
da bleibt nur, Docker für Docker prüfen und schauen ... aufpassen beim Einrichten und auch innerhalb der Apps aufpassen was da gesetzt ist ...
Beispiel, Mediathek Downloader ... findest du auch recht aktuell einen Beitrag hierzu.
 
Auch nach "orphan images" geschaut, oben rechts, advanced aktivieren, nach unten scrollen ob orphan images existieren ... diese dann auch löschen, sind standardmäßig ausgeblendet ...
 
ist hierfür komplett irrelevant ...

sorry, aber das bitte dort diskutieren ... custum Kernel ...
 
ARC support kommt übrigens jetzt mit der 6.13, für deine Mellanox Karte hätte ich zum Start eher ein Feature Request aufgemacht anstelle mich auch custom einzustellen, hat bei mir damals auch schnell geklappt wo der Treiber meiner 10G Karte nicht unterstützt war ... das nur am Rand, wird aber nur supported mit official und nichts custom.

Neustarts, sprich, Server startet wirklich neu durch ... dann ist es sehr sicher ein Hardware Thema .... Unraid an sich freezt wenn es Software Themen sind.
 
1. Ansatz, alle Stromsparmaßnahmen raus, sei es BIOS, sei es powertop, sei es ... (unwahrscheinlich, aber zum Ausschluss)
2. memtest (ist im Unraid Boot menu integriert) um den Speicher (RAM) zu testen und auszuschließen ... (schon wahrscheinlich)
3. Hardware Step by Step ... da bleibt nicht viel übrig ... außer Netzteil, Mainboard, RAM, ... sorry ... (etwas davon würde es dann sein)
 
"Hot" Reboots ohne Zutun ... ist halt (leider) sehr sehr sicher Hardware ... du könntest noch syslog zu flash aktivieren zum debuggen, da kommen mehr Meldungen an, aber wenn die kiste wirklich hart neu startet bringt das (leider) auch nicht viel bis gar nichts wahrscheinlich ... aber zum Test ...

da fehlt ja jetzt noch die Router Konfiguration, aber egal ...
 
im Grunde ist es ja simpel, extern 80 > 192.168.1.103 Port 280, extern 443 > 192.168.1.103 Port 2443
 
Anmerkungen generell
 
aber wenn ich das da oben sehe ... du solltest dich mal entscheiden oder zumindest überlegen was du machst
 
Host, br0 (alte Version ?), bridge, proxynet ... was auch immer du da bezweckst ... das wird irgendwann ... unübersichtlich
 
dann noch Konflikte wo auftreten wenn die parallel starten ... Beispiel

 
usw usw usw ... Port forwarding Plex ? soll der nicht hinter dem RP laufen ? ... egal  wird seine Gründe haben, nur lies dich mal etwas dazu ein und meine Empfehlung, entscheide dich und räum etwas auf ...
 

naja, einfach gesagt
 
RAID 5 nutzt striping, sprich die Daten werden verteilt auf alle Platten gleichzeitig geschrieben ... bei deiner 5+1 Konstellation auf 5 HDD's verteilt
UNRaid (man beachte das UN) ist kein "striping" Raid ... die Daten werden nicht verteilt und jede Datei liegt für sich auf einer HDD, in dem Fall schreibst du jeweils eine Datei immer nur auf eine Platte und die Datei wird nicht "in Stripes" auf die Platten verteilt ...
 
ein Raid ist immer schneller, aber bei einem bösen Crash ist immer alles weg ... bei Unraid liegen die Daten jeweils in Gänze auf einer Platte ...
nehmen wir worst case Szenario, 2 disks gehen in dem Szenario parallel kaputt ...
Raid5 == alles weg ...
Unraid == die Daten der 2 disks sind weg, Rest ist noch komplett vorhanden ...
 
das zum Grundverständnis UNRaid <> Raid5 (Qnap oder wo auch immer)
 
daher auch die cache Thematik um 1/ schnellere Transfers zu ermöglichen und 2/ die HDD's zu schonen und nicht permanent im Dauerfeuer betreiben zu müssen ... auch hier liegt ein großer Unterschied ... bei dem benannten Raid5 laufen immer alle Platten, egal ob lesend oder schreibend, bei UNRaid muss das nicht sein ... entweder noch auf dem cache, oder auf diskX ... und beim lesen läuft auch NUR diese diskX und schreibend nur diskX + Parity disk ...
 
hoffe das ist grob verständlich zum Unterschied ...
 
abschließend hierzu, Nein, kannst du in dem Fall nicht  daher auch die Anmerkung "Unterschiede ..."
 
 
zu deiner Problematik, das sind anscheinend 5400 rpm CMR HDD's, die sollten schon etwas mehr können ... aber sind auch keine "Rennwagen"
 
hier auch mal zum Grundsatz, deine Platten haben einen internen RAM cache ... der wird immer zuerst befüllt, wie du siehst schiebt Unraid da Vollgas rein ... dann geht es innerhalb der HDD physisch auf die Platten ... und erst jetzt wird tatsächlich auf die Platte "geschrieben", sprich, dieses Verhalten ist normal ...
ist Hardware und überall gleich, hat auch nichts (und kann auch nicht) vom OS gesteuert werden ...
 
du hättest jetzt beispielsweise die Option das grundsätzliche Verhalten etwas zu ändern, zu Lasten der Energieeffizienz ...
stell das um auf "reconstruct" ... früher auch "turbo" genannt ...
 

 
hierzu einfach etwas einlesen ... hättest du übrigens auch mit der Suche oben rechts gefunden ...  "array langsam" ... gab es schon häufig
 
da bei dir anscheinend eh alle Platten laufen (kein spindown aktiv) ist es egal, nur dass dieser mode doch um einiges schneller läuft ...
 
Infos dazu, Suche oben rechts
 
zu deiner Hardware an sich, dein Board hat 4 SATA Controller wenn ich das richtig sehe, warum 3x extern am Controller angeschlossen sind wird seine Gründe haben, auch der sollte etwas mehr leisten können ... kann dir aber so niemand wirklich beantworten ... und ist vielleicht auch die Ursache ...
 
ggf. zum Ausschluss (da du eh am Anfang stehst), wäre mein erster Ansatz mit 3 + 1 Parity ohne den Controller direkt am Board zu testen und schauen was dann anliegt ... dann wenn ich mir noch deine HDD Temps anschaue 50+ Grad ... ja ... sollten die aushalten ... mögen ... sicher nicht ...
 
Array only Shares, empfehle ich beispielsweise zur "Erstbefüllung", da macht es Sinn nicht alles durch die cache SSD zu jagen ...
bei array only Shares dann mit der Array Geschwindigkeit leben (wie auch immer die jetzt effektiv ist) oder aktiv cache nutzen (und mover seinen Job machen lassen), lesend sollte es zumindest ja um einiges schneller laufen da die Parity außen vor ist ...

ich schätze Grafana lief nicht dabei, sprich, du hast einen Prozess der bereits auf Port 3000 listened ... auf dem Host ...
 
also einer deiner Docker welche im Host mode laufen ... und Nein, in der Docker Übersicht siehst du nur die exposed Ports ... können aber auch noch mehr sein ...
oder du hast noch ein plugin laufen wo das auslöst ...
 
du kannst jetzt noch folgendes machen
 
readlink -f /proc/13833/exe  
dann hast du noch zusätzlichen einen Pfad des ausführenden Prozesses ...

wie oben erwähnt, btrfs bin ich raus ... ist mir einfach zu "Problembehaftet" ...
 
wenn ich jetzt du wäre, würde ich alles wegsichern was sont noch auf dem cache liegt (2. cache solange Parity läuft), platt machen und neu formatieren, neu starten mit Docker ... und ja, ich nutze docker directory ... aber ... es muss klar sein, wenn etwas falsch konfiguriert ist bei docker directory schreibt es die ganze Platte voll und nicht nur das image, nur als Hinweis ...

wie @hawihoney erwähnte, database im Eimer ... entweder backup nutzen (das Plex native, ein exhtes backup, ..) oder wirklich neu aufsetzen wenn eh alles im Eimer ist
 
sofern aktiv, hier liegen backups seitens plex ... 
 

 
ein Versuch wäre noch wenn nicht eh bereits alles kapuut ist  plex docker stop, ...library.db raus, eine backup umbenennen (datum hinten weg), plex starten und hoffen ... mit etwas Glück .... geht es wieder

dann siehe meine Empfehlung oben ... docker Dienst aus, einmal image/directory ex, docker Dienst neu starten, dabei wird das Image/Directory neu erstellt.
 
Worst Case, das Ganze liegt auch noch auf einem btrfs volume, wenn das o.g. nicht hilft, cache räumen (weg kopieren was wichtig ist), cache formatieren und retour spielen, Docker Dienst neu starten und auch neu erstellen lassen, btrfs ... wirst du einiges dazu finden.

oder dem user nicht die ip maske frei gegeben ... bei mariadb ein Muss ... und die interne docker ip ... kann man machen ... die kann sich aber auch ändern
daher nicht unbedingt die beste Idee ...
 
Beispiel in der mariadb CLI einen user zu adden mit % als Maske (passt immer), wenn die mariadb NICHT nach außen offen ist (extern ...)
 
mysql -u root -p CREATE DATABASE nextcloud; ### OR ### CREATE DATABASE IF NOT EXISTS nextcloud; CREATE USER 'nextclouduser'@'%' IDENTIFIED BY 'new_password_here'; GRANT ALL ON nextcloud.* TO 'nextclouduser'@'%' IDENTIFIED BY 'user_password_here' WITH GRANT OPTION; FLUSH PRIVILEGES; EXIT;  

nur geschätzt ... einer deiner Docker restartet permanent ... ist ein gern genommenes flag in extra parameters was bei vielen Dockern standardmäßig hinterlegt ist, sprich, die App crasht weil beispielsweise falsch konfiguriert, der Docker startet neu ...
 
Docker für Docker prüfen indem man das jeweilige log Fenster öffnet und schaut was darin so passiert (oder ob sich das Fenster einfach schließt, auch restart )
 
Nein ... ich versuche es mal simpel
 
das mapping ... stell es dir vor wie ein Post forwarding an deinem Router, wenn du jetzt den internen Post einfach auf etwas anderes setzt ... läuft der halt ins Leere weil die App Ihren listening Port ja dadurch nicht ändert ... in deinen Beispielen die "webserver" die auf den Port 8080 listenen ... extern kann man den Port halt nur 1x vergeben, wie an deinem Router ... intern müssen die aber passen ... nur das mapping ändern ist halt "murks", wenn dann müsste man auch den listen Port der App mit ändern (sofern das überhaupt unterstützt wird von der jeweiligen App).
 
Hoffe das war verständlich ...

wie @ich777 bereits erwähnt hat, 1:1, wie mein Beispiel oben, hier die ausführliche Version
 
Name ist natürlich egal ...
 

Settings, Scheduler ... Mover ... einstellen wann er moven soll ...
 
Mover Tuning Plugin ... Anleitung im eng. Thread lesen, einstellen, ... enjoy

die "cache" Platte wo auch das docker image / directory liegt ?
 
wenn eh alles weg ist, vielleicht mal so ...
 
 

ganz sicher sogar ... im passenden Thread Seite 1 lesen und einfach entsprechend umsetzen ...
 
Seite 1, Post 2, unten ... sogar mit Bilder ...
 
 
sinnvoller wäre es zu beschreiben woran es hängt oder was du nicht verstehst ... mit einer kleinen Auflistung dessen was du gemacht hast ... oder welche Hardware du nutzt ... welcher Docker ...  oder screens deiner Config ... oder oder oder ...  dann könnte man ggf. eher die Richtung weisen ...

ich schätze das wird von den meisten Usern genutzt ... inkl. mir (NC sogar NUR für Foto Sync ...), Lösungsansatz, Schauen warum das bei Dir so mies war ...
 
 
einfach dein setup so belassen (foldersync > unraid ... smb ?) und dein script in Unraid ausführen (umschreiben ... dann in userscripts ausführen lassen)

ich kenne jetzt den workflow nicht, aber ich denke mich mal ein ...
 
Auslöser ist, du nimmst dem Docker die "Festplatte" hart weg indem du dein NAS unter der Woche ausschaltest, dein NAS ist in UAD eingebunden, indem du das NAS offline legst verliert der Docker die Platte, jetzt sucht der Duplicati Docker halt nicht mehr danach und bindet diese neu ein nachdem dein NAS wieder online gekommen ist und UAD diese wieder eingebunden hat.
 
Das nur als Erläuterung was da passiert (wenn ich dein setup richtig verstanden hab)
 
Beispiel
Backup soll Sonntags um 04.00 Uhr starten
NAS wird um 03.30 Uhr aufgeweckt
UAD hat um ca. 03.35 Uhr wieder alles in Unraid eingebunden
 
dann würde ich um 03.45 Uhr einfach den Docker automatisiert neu starten, dazu gäbe es jetzt mehrere Wege, aber wir halten es mal simpel.
 
plugin user script (Suche oben rechts ...) ist dafür da um zu gewissenen Anlässen (array start, stop, ...) oder zu gewissen Zeiten (cron job) etwas zu machen.
 
Beispiele

 
jetzt füge ich einfach ein script hinzu, gib dem Kind einen Namen, Beispiel Duplicati_Restart
 

 
editiere dieses script welches bis auf den bin/bash Eintrag leer ist und füge hinzu was das script machen soll, Beispiel
 

 
dabei sehe ich auch oben link, What is Cron ... klicke darauf und lese mich ein  das ist die Teitsteuerung welche dann gesetzt wird, kommt gleich
 
jetzt ist das script erstmal vorhanden und wir könnten es mal testen indem wir Run Script klicken, dabei öffnet sich auch ein Fenster
 

 
bei mir kommt da sicherlich ein Fehler da ich Duplicati nicht nutze

 
bei Dir sollte dann dein duplicati Container einfach neu starten, sprich, das was du von Hand machst übernimmt das script ...
das würde ich jetzt einfach mal "trocken" testen, sprich, Alles an machen, schauen ob alles passt, dann NAS offline nehmen, onlien nehmen, script ausführen, schauen ob alles passt ... wenn ja, kommen wir zu "cron"
 

 
bei dem Link wird es Dir sicher einfach fallen cron zu verstehen, dies tragen wir jetzt bei "custom ein"
 

 
und jetzt passiert das einfach so jeden Sonntag um 03.45 Uhr