mgutt

Wie oft probiert UD den auto mount laut Logs? Ist das regelmäßig der Fall? Du könntest auch testweise ein Script mit User Scripts erstellen, dass alle 60 Sekunden einen Ping absetzt und dann lässt du es mal den ganzen Tag laufen und sichtest die Logs von dem Script um evtl Fehler zu erkennen. while true; do ping -c1 192.168.178.48; ping -c1 DISKSTATION; sleep 60; done

Dann nutzt der Container vermutlich die log-Dateien - warum auch immer - um überhaupt funktionieren zu können. Du könntest die Dateien manuell in das RAM-Disk Verzeichnis kopieren, aber schlussendlich ist das vergebene Lebensmühe, denn sobald der Server neu startet, wird ja /tmp geleert und der Container würde nicht mehr gehen. Du merkst selbst, dass /var/log auch für "statische" Dinge gedacht sein kann. Was du mal testen könntest. Start den Container, öffne dessen Konsole und schau mal welche es Unterordner darin gibt: ls -la /var/log Ist es zB nur dieses rabbitmq, dann könntest du mal im Ziel deiner RAM-Disk diesen Ordner erstellen: mkdir -p /tmp/onlyoffice/var/log/rabbitmq Und dann verlinkst du /var/log mit /tmp/onlyoffice/var/log Wenn es noch mehr Unterordner in /var/log gibt, erstellst du auch die mal. Vielleicht will der Container wirklich nur die Existenz des Unterordners und nicht die log-Datei als solches. Nein völlig egal. Ich hätte es auch so machen können: Das wirkliche Ziel von /var/log kennt der Container nicht. Für ihn existiert nur /var/log. Man darf nur nicht hingehen und Pfade überschneiden lassen: In dem Fall würde der Container im Pfad /data/logs sonst den Unterordner "bob" mit dem Inhalt von /var/log sehen.

Du hast also bei DuckDNS eine IPv6. Von welchem Client ist die? Ruf sie bitte über den Browser auf: http://[1234:1234...:fe3d]/ Oder über die Kommandozeile (eckige Klammern sind wichtig): curl -6 http://[1234:1234...:fe3d]/ Was man schon sehen kann ist, dass sie nicht vom Unraid Server ist, denn der endet ja laut deiner Port-Freigabe auf f05f und die bei DuckDNS auf fe3d. Ich tippe darauf, dass das die öffentliche IPv6 der Fritz!Box selbst ist. Mit der kannst du aber nichts anfangen, denn du willst ja nicht die Fritz!Box sehen, sondern Unraid bzw den Container, der über die IPv6 erreichbar sein soll. In welchem Netzwerk läuft der DuckDNS? Mich wundert, dass du überhaupt eine IPv6 im Dashboard hast. Dann fällt mir auf, dass dein Server die IP .46 verwendet. Also keine feste IP, sondern eine vom DHCP Server, die du dann in der Fritz!Box reservierst. Besser ist es, wenn du die Port-Freigaben löschst, die IP von Unraid auf eine unterhalb von .20 stellst (siehe Fritz!Box > Netzwerk-Einstellungen > IPv4 Einstellungen), damit der Unraid Server wirklich eine feste IP hat und nicht abhängig vom DHCP Server ist. Wenn du das machst, geh am besten hin und entferne danach das LAN Kabel, warte 2 Minuten und lösch alle Offline-Clients in der Netzwerk-Übersicht der Fritz!Box. Die merkt sich sonst evtl die falsche Kombination aus alter und neuer IPv4/v6. Und wie gesagt muss die IPv4 bei DuckDNS weg. Das ist eine lokale IPv4, die man nicht von außen erreichen kann, aber die Clients, die die DuckDNS Domain auflösen, könnten die IPv4 bevorzugen und landen dann im Nirgendwo. Was soweit ja kein Problem ist, weil du ja eine öffentliche IPv6 hast, die man über 6tunnel dann erreichen kann.

Einfach so denke ich nicht: https://askubuntu.com/a/130614/227119

Ich habe in der Anleitung auch noch diese Erfahrung verlinkt: https://forums.unraid.net/bug-reports/stable-releases/683-unnecessary-overwriting-of-json-files-in-dockerimg-every-5-seconds-r1079/page/2/?tab=comments#comment-15674 Und zwar als Warnung, dass man wirklich nur "/tmp" eines Containers in eine RAM-Disk packt. Dieser User "hat nicht gehört" und hat "/run/postgresql" in eine RAM-Disk gepackt und damit eine Datenbank in einem Container zerschossen.

Was heißt "nur". Also nicht Audio Device oder meinst du was anderes?

Einfach und gar nicht supportintensiv 😅 Ich mein klar, wäre schon bequem sich eine ISO von Unraid selbst bauen zu lassen, aber wer soll das bei Limetech umsetzen und supporten. Alleine die Abhängigkeiten machen das zu einem Job auf Lebenszeit und bezahlen tun wir bekanntlich einmalig für die unRAID Lizenz. Die Nutzer erwarten dann auch, dass die ISOs/VMs perfekt funktionieren. Das ist gefährlich für die Reputation. Ich würde das wenn eher auf die Community auslagern. Also so wie den App Store. Aber wer vertraut schon der ISO eines Dritten. Da müsste man sich erstmal ein Prüfungsverfahren ausdenken. Ich mein drei Zeilen Code und die Windows VM schickt jede Minute Screenshots vom Desktop in die Hütte im Wald. 📨 Ich glaube ich würde nicht mal den ISOs vertrauen, die Unraid erstellt. 🙈

Nein, der Befehl ist nun universell. Zwei finde ich nicht (eingerahmt), aber den Rest schon: Wann wird denn "volumes" erstellt? Hast du einen Container, der bei den Pfaden ein "Volume" einbindet? Und das mit dem Daemon weiß ich auch nicht. Ist das evtl ein Gerät? Du könntest so nach Dateien suchen, die "11ad4a..." enthalten: grep -rnw '/var/lib/docker' -e '11ad4a2d8c58a' Sag bescheid was du findest, dann kann ich das evtl in den Befehl integrieren.

Correct.

Und hier auch die WD Blue: https://arstechnica.com/gadgets/2021/08/silent-changes-to-western-digitals-budget-ssd-may-lower-speeds-by-up-to-50/?amp=1

Exakt. HDDs im Array und eine NVMe als Cache Pool. Von der mache ich dann regelmäßig Backups aufs Array.

Er heißt "/tmp" wie in der Ausgabe des "find"-Kommandos zu sehen. Ich habe die Anleitung übrigens in großen Teilen umformuliert und mehr Screenshots / Erklärungen ergänzt. Es sollte jetzt denke ich besser zu verstehen sein. Lies insbesondere bei Gegenmaßnahmen noch mal Punkt 4. Auch das steht jetzt in der Anleitung. merged und diff gehören nicht zum Container, sondern zum Docker-Dienst und diese muss man sich daher wegdenken. Alles was nach "merged/" steht, ist die Root-Ebene des Containers. Vergleiche:

My script covers only /docker/containers. Everything what happens inside the container isn't covered as its in the /docker/overlay2 or /docker/image/brtfs path. So yes, it was a good step to add a RAM disk path for the /tmp folder of Nextcloud. This is something which I would not touch. PostgreSQL is a database. It contains important data which shouldn't be in tbe RAM. Note: if you link a container's /tmp path to a RAM Disk, all data inside this path will be deleted on server reboot. Note: Using /tmp as a RAM disk is the default behavior of Unraid, Debian and Ubuntu. It seems not to be the default for Alpine, but as such popular distributions use RAM disks for /tmp, I think the application developers do not store important data in /tmp.

Einfach tauschen. Die alte gilt dann als "defekt" und die neue baut neu auf. Das macht jeder wie er will. Ich habe zb nur eine NVMe und da liegen die VDisks der VMs drauf (also mehrere). Andere schleifen einen Datenträger pro als PCIe Hardware durch und wieder andere nutzen "/dev/by-id..." als Pfad, was auch eine Art durchschleifen darstellt, aber über einen speziellen Treiber läuft. Auch hier dann eine VM pro Datenträger.

unRAID vergibt nur einen Namen. Um weitere nutzen zu können, muss man einen Proxy installieren. Die beliebtesten sind SWAG und Nginx Proxy Manager.

Ja das ist das was im Guide unter 5.) beschrieben ist. Du musst den Container ermitteln und bei diesem dann einen neuen Path hinzufügen Container: /tmp und Host: /tmp/containername. Dadurch schreibt der Container nicht mehr auf das /tmp Verzeichnis was auf der SSD liegt, sondern das was im RAM liegt. Nenn gerne die Container, wenn du sie gefunden hast. Dann melden wir das an den Maintainer, dass er das direkt ins Template übernimmt.

Samsung hat die Evo Plus heimlich verschlechtert. Ab 04:44 sieht man, dass man bei einem vollen SLC Cache kein 10G Netzwerk mehr auslasten kann: Einfach nur noch nervig was auf dem Markt passiert.

Na dann passt das ja.

Yes. Execute this command multiple times and check which files are updated frequently: find /var/lib/docker -type f -print0 | xargs -0 stat --format '%Y :%y %n' | sort -nr | cut -d: -f2- | head -n30 Execute this to find out which folder name belongs to which container: csv="CONTAINER ID;NAME;SUBVOLUME\n"; for f in /var/lib/docker/image/*/layerdb/mounts/*/mount-id; do sub=$(cat $f); id=$(dirname $f | xargs basename | cut -c 1-12); csv+="$id;" csv+=$(docker ps --format "{{.Names}}" -f "id=$id")";" csv+="/var/lib/docker/.../$sub\n"; done; echo -e $csv | column -t -s';' Please post them (and the time when the pool stopped working).

Hier habe ich was dazu gefunden: https://wiki.archlinux.org/title/Solid_state_drive/NVMe#Troubleshooting Für mich sieht das so aus als würde die dann immer auf Vollgas laufen?! Im letzten Abschnitt gibt es dann noch eine Lösung wo man nur bestimmte Stufen von APST abschaltet. Müsste man mal mit den verschiedenen Einstellungen den Verbrauch messen.

Freu dich nicht zu früh. Wie warm ist sie nun und was sagt der Stromverbrauch? Das heißt nämlich, dass die NVMe nicht mehr schlafen geht, wobei @ich777 hier meinte, dass es evtl nur der tiefste Schlafzustand ist, der dadurch verloren geht: https://forums.unraid.net/topic/104317-kingston-a2000-macht-probleme-in-linux/?do=findComment&comment=963419

Ah ok. Ja den Test könnte man trotzdem machen.

Yes, this drove me crazy as well. Don't ask me why, but because one path mounts to the other, both return the same activity results from the RAM-Disk although I would expect that /mnt/cache reflects the SSD content?! The only way to see the real traffic on the SSD, is to mount the parent dir: mkdir /var/lib/docker_test mount --bind /var/lib/docker /var/lib/docker_test Now you can monitor /var/lib/docker_test and you see the difference. That's why I needed to use the same trick to create a backup every 30 minutes. It took multiple days to find that out 😅 Screenshot: If you use the docker.img it is easier. It has the correct timestamp every 30 minutes. 🤷‍♂️ PS: You can see the higher write activity on your SSD in the Main tab if you wait for 30 minute backup (xx:00 and xx:30). Unmount and remove the test dir, when you finished your tests: umount /var/lib/docker_test rmdir /var/lib/docker_test

Da gab es doch diese Download Method in den Container-Einstellungen. Da habe ich schon öfter gelesen, dass man die auf 2 oder so ändern soll. Probiere das mal. Taucht eigentlich auch immer wieder in den Youtube Kommentaren auf.

Ok, dann liegt es daran schon mal nicht. Es gibt nämlich USB Platten, die antworten dann mit einer Fehlermeldung und wachen einfach auf. Aber das ist in jedem Fall reproduzierbar? Also ist jetzt kein Zufall? Wenn du darauf Bock hast, kannst du die von mir modifizierten Pakete von hdparm und smartctl installieren, die immer 1 Sekunde warten, bevor ein Kommando ausgeführt wird: hdparm-9.58-sleep1.txz smartmontools-7.2-sleep1.txz Also zB in einen Share hochladen und das ausführen: upgradepkg --install-new /mnt/user/sharename/*.txz Du kannst nun hingehen und hdparm/smartctl wie folgt überwachen (das geht normalerweise nicht, weil die Kommandos zu schnell ausgeführt werden): while true; do for pid in $(pgrep -f 'smartctl|hdparm'); do if [[ $lastcmd != $cmd ]] || [[ $lastpid != $pid ]]; then cmd=$(ps -p "$pid" -o args); echo $cmd "($pid)"; lastpid=$pid; lastcmd=$cmd; fi; done; done Am besten gehst du nun hin und weckst alle Platten vom Array auf, denn sonst spammt dir Unraid das Terminals zu (Unraid prüft mit hdparm im Sekundentakt ob eine schlafende Platte noch im Standby ist). Also nur die USB Platte soll schlafen. Ist sie wach, dann schick sie manuell schlafen: hdparm -S0 /dev/sdX Nun mach die Aktion, wodurch Nextcloud die USB Platte weckt. War die Ursache hdparm oder smartctl und wenn ja welches Kommando? Wenn nein: Dann hätten wir das schon mal als Fehlerquelle ausgeschlossen. Starte einfach den Server neu um die Original hdparm und smartctl Pakete wiederzubekommen.