independence

nein, nichts derartiges installiert ok, also possible but not really a solution, just a workaround Maybe I will try that - at first I will check some other dependencies by changing from folder to image.

Heute konnte ich es nachvollziehen am Beispiel "n8n". Folgender Fehler kam beim Update des Containers und danach war er gelöscht und ich musste ihn manuell neu installieren:

Ok, versuche ich mal. Aber ich kann da im Tagesbetrieb keine Einschränkung feststellen und daher ist es mir auch noch nicht aufgefallen. Ich habe vorhin beim Update bemerkt, dass es scheinbar daran liegt, dass das vorherige (alte) Image nicht gelöscht werden kann und dann das Problem auftritt, dass der Container gelöscht wird. Ich habe das Log leider zu schnell geschlossen, aber beim nächsten Mal, mache ich davon noch ein Foto

Danke für eure Hilfe. Docker hab ich bewusst so angelegt. Und die Kommandos trage ich auch manuell nicht ein. Glaube nicht, dass das das Problem ist. Aus meiner Sicht liegt es nicht an einzelnen Containern sondern an der Engine. Das mit den Restarts ist auch kein Problem (außer die Einträge im Log), das funktioniert alles. Es ist einfach für mich derzeit noch nicht nachvollziehbar. Heute lag ein Update von Nexctloud vor, es ist durchgelaufen (jedoch mit einem Fehler) und dann hat unraid nicht einfach den alten Container wiederhergestellt sondern einfach die alte und neue version gelöscht. Nach jedem Update eines Containers schaue ich nun in den Previous Apps nach, ob was drinsteht, dass eigentlich gebraucht wird.

So sieht es heute bei mir eh schon aus, also bis auf die extra Parameter je Container habe ich es ähnlich konfiguriert wie dein Vorschlag ist (der Ordner "Docker" liegt auf dem Cache).

Danke, den Input zum gernerellen Setup setze ich gleich mal um. Folderview: Ja, das ist ein Vorher-Nachher-Bild. Ich habe nur 1 Folder für Nextcloud. DIe Postgres Logs werde ich dann auch mal checken

Heute bzw. gestern ist es wieder passiert. Postgres Update wurde angezeigt und seit dem Update ist der Postgres Container nicht mehr da. Ganz einfach dann re-installiert und es läuft alles wieder aber deswegen war dann meine Nextcloud seit dem Update auch nicht mehr funktionsfähig. Und so wie es aussieht, hat das Update des Containers auch noch nicht einmal funktioniert nas-diagnostics-20251115-0833.zip

Servus zusammen, gerade eben ist es wieder passiert und so langsam kommt es mir sehr komisch vor. Ich habe gerade versucht die WebGUI von Teslamate zu öffnen und diese war nicht erreichbar. Also wollte ich in den Logs nachschauen und dann habe ich gemerkt, dass der Container nicht mehr da ist. In den "Previous Apps" konnte ich ihn natürlich finden und direkt wieder installieren. Heute morgen war der Container noch installiert und ich habe ihn auf keinen Fall aktiv gelöscht. Das ist mir in den vergangenen Wochen schon mehrfach passiert. Einmal war Immich weg und auch mal ne Postgres DB. Ich kann mir nicht erklären wieso das passiert und was der Trigger ist. Ich habe immer selbst bemerkt, dass der Container nicht mehr da ist, aber eben nur, weil ich gerade den Container gebraucht habe. Da kann es dann natürlich schon mal einige Tage sein, dass der Container gelöscht war. Ich bin auf 7.2.0 seit einigen Tagen und halte das System generell immer up-to-date. Ich hoffe, jemand hat eine Idee. Danke vorab

Schließe den Server mal noch ohne die USV direkt an den Strom an. Bei mir war zusätzlich auch noch der Akku vom der USV tot - zeigte zwar was an, aber beim Stromausfall konnte der Akku nichts mehr puffern.

Ein ähnliches Verhalten hab ich bislang noch nicht mit einem Shelly/Nous oder ähnliches bemerkt, aber nicht bei jedem hängt auch ein Gerät dahinter, wo es wirklich kritisch ist, wenn der Strom für 1 Sekunde weg ist. Auf jeden Fall sehr schlecht, denn das macht den Einsatz natürlich unmöglich.

Ich war abends zufällig in dem Raum und hab das Klacken vom Shelly gehört. Dann hab ich mir das im Log von Homeassistant angeschaut und dann mal reproduziert. Aber wieso das passiert weiß ich nach wie vor nicht. Wollte den Shelly von Tasmota dann auf Original zurückflashen und hab das Teil gebrickt. Finde dann die ursache also eh nicht mehr raus.

So, ich konnte das Problem identifizieren. Am Serverschrank hängt noch ein Shelly Plus S (auf Tasmota geflashed) um den Verbrauch zu messen. Dieser hängt auch in Homeassistant und übertragt die Verbräuche dorthin. Warum auch immer schaltet sich der Plug S für einen Bruchteil einer Sekunde aus und wieder an. Hat also tatsächlich nichts mit Unraid zu tun (sehr gut). Daher kann das Thema hier geschlossen werden.

Ich hab den kompletten Server ausgetauscht und nach wie vor tritt das Problem ausschließlich wöchentlich am Freitagabend auf. Ich glaube sowas wie den Taster am Gehäuse können wir recht sicher ausschließen.

Hat sich nun alles etwas verzögert aber ich habe Anfang der Woche die komplette Hardware 1:1 ausgetauscht um Probleme am Netzteil oder was auch immer auszuschließen. Vor paar Minuten ist der Server wieder ohne Eingriff heruntergefahren - die Hardware ist es also nicht. Und das Syslog zeigt wieder überhaupt nichts an zwischen 20 und 21 Uhr und ich bin mir recht sicher das der Shutdown zwischen 20:50 und 21:00 Uhr war.

Hi @BastiKA84, das hab ich versucht im ersten Post zu beschreiben. Hinter der USV hängt der komplette Schrank und es ist keine direkte Verbindung (in dem Fall wäre es USB) zwischen USV und Server vorhanden. Der USV Deamon in Unraid ist daher auch deaktiviert und es findet kein geplantes Herunterfahren statt bei einem Stromausfall. Die USV erfüllt in dem Szenario bei mir also nur den Zweck, dass Lastspitzen und Stromausfälle bis zu 10 Min abgefedert werden (dann ist der Saft der USV leer). Grüße

Werde ich heute mal checken und dann auch so setzen (falls nicht passiert). Was mich da aber auch wundert ist, dass kein anderes Gerät im Serverschrank ausgeht (Router, Modem, APs über PoE, RaspiPi, Switch, usw) -> daher würde ich generell nen Stromausfall ausschließen, da ja auch eine USV vorgeschaltet ist. Zudem treten die Probleme erst seit kurzem auf und das Setup lief vorher unverändert 6 Monate ohne diesen Fehler. Kann natürlich auch ein Hardwaredefekt sein, natürlich nicht auszuschileßen.

Der letzte Shutdown war am Abend vom 21.02., aber ich weiß nicht ganz genau wann, ich hab es einfach irgendwann gemerkt weil paar Dienste nicht erreichbar waren. Die letzten Zeilen im Log waren: Feb 21 17:54:55 NAS emhttpd: read SMART /dev/sdd Feb 21 17:55:10 NAS emhttpd: read SMART /dev/sdb Feb 21 17:55:10 NAS emhttpd: read SMART /dev/sdc Feb 21 18:01:56 NAS emhttpd: read SMART /dev/sdf Feb 21 18:02:01 NAS emhttpd: read SMART /dev/sde Feb 21 18:57:57 NAS emhttpd: spinning down /dev/sdd Feb 21 18:58:40 NAS emhttpd: spinning down /dev/sdb Feb 21 18:58:40 NAS emhttpd: spinning down /dev/sdc Feb 21 19:02:02 NAS emhttpd: spinning down /dev/sdf Feb 21 19:03:12 NAS emhttpd: spinning down /dev/sde Um 20:16 Uhr kann ich in Homeassistant (läuft auf dem Server) den letzten Datenpunkt sehen vom Stromverbrauch, daher gehe ich davon aus, dass da der Shutdown war. Da sich nichts im Log erkennen lässt, sieht es auch nicht nach einem geplanten Shutdown per Befehl aus. S3 Sleep Plugin hatte ich lange installiert, aber vor ca 1,5 Wochen wegen einem anderen Problem deinstalliert. Ist es also vermutlich auch nicht. Wenn ich deinen Befehl ausführe kommt das folgende dabei raus: /etc/X11/app-defaults/XSm:*shutdownButton.label: Shutdown /etc/X11/app-defaults/XSm:*shutdownSave.label: With Checkpoint /etc/X11/app-defaults/XSm:*shutdownDontSave.label: Immediately /etc/bash_completion.d/docker: COMPREPLY=( $( compgen -W "accepted running shutdown" -- "${cur##*=}" ) ) /etc/bash_completion.d/docker: COMPREPLY=( $( compgen -W "accepted running shutdown" -- "${cur##*=}" ) ) /etc/bash_completion.d/docker: COMPREPLY=( $( compgen -W "accepted running shutdown" -- "${cur##*=}" ) ) /etc/modprobe.d/kvm.conf:options kvm ignore_msrs=1 halt_poll_ns=0 /etc/rpc:walld 100008 rwall shutdown /etc/inittab:ca::ctrlaltdel:/sbin/shutdown -t5 -r now /etc/apcupsd/apccontrol:SHUTDOWN=/sbin/shutdown /etc/apcupsd/apccontrol: printf "Continuing with shutdown." | ${WALL} /etc/apcupsd/apccontrol: echo "Battery power exhausted on UPS ${2}. Doing shutdown." | ${WALL} /etc/apcupsd/apccontrol: echo "Battery time limit exceeded on UPS ${2}. Doing shutdown." | ${WALL} /etc/apcupsd/apccontrol: echo "Remaining battery charge below limit on UPS ${2}. Doing shutdown." | ${WALL} /etc/apcupsd/apccontrol: echo "Remaining battery runtime below limit on UPS ${2}. Doing shutdown." | ${WALL} /etc/apcupsd/apccontrol: doshutdown) /etc/apcupsd/apccontrol: ${SHUTDOWN} -h now "apcupsd UPS ${2} initiated shutdown" /etc/php-fpm.d/www.conf:; shutdown functions are being called (registered via register_shutdown_function). /etc/libvirt/qemu/Ubuntu.xml: <on_poweroff>destroy</on_poweroff> /etc/libvirt/qemu/Homeassistant.xml: <on_poweroff>destroy</on_poweroff> /etc/libvirt/qemu/Windows 11.xml: <on_poweroff>destroy</on_poweroff> /etc/slim.conf:halt_cmd /sbin/shutdown -h now /etc/slim.conf:reboot_cmd /sbin/shutdown -r now /etc/slim.conf:shutdown_msg The system is shutting down... /boot/config/disk.cfg:shutdownTimeout="90" /boot/config/plugins-removed/parity.check.tuning.plg: (stops unclean shutdown warnings happening until array started). /boot/config/plugins-removed/parity.check.tuning.plg: the array without doing it via a shutdown or reboot. /boot/config/plugins/dynamix.system.buttons.plg:Dynamix System Buttons - Single click system reboot and system shutdown /boot/config/plugins/user.scripts/scripts/Autoconvert Folder to Dataset/script:vm_forceshutdown_wait="90" # how long to wait for vm to shutdown without force stopping it /boot/config/plugins/user.scripts/scripts/Autoconvert Folder to Dataset/script: virsh shutdown "$vm" /boot/config/plugins/user.scripts/scripts/Autoconvert Folder to Dataset/script: if (( current_time - start_time >= $vm_forceshutdown_wait )); then /boot/config/plugins/user.scripts/scripts/Autoconvert Folder to Dataset/script: echo "VM $vm has not shut down after $vm_forceshutdown_wait seconds. Forcing shutdown now." /boot/config/plugins/dockerMan/templates-user/my-macinabox.xml: <Config Name="CPUARGS" Target="CPUARGS" Default="Skylake-Server,vendor=GenuineIntel,+hypervisor,+invtsc,kvm=on,+fma,+avx,+avx2,+aes,+ssse3,+sse4_2,+popcnt,+sse4a,+bmi1,+bmi2|Penryn,kvm=on,vendor=GenuineIntel,+kvm_pv_unhalt,+kvm_pv_eoi,+hypervisor,+invtsc,+pcid,+ssse3,+sse4.2,+popcnt,+avx,+avx2,+aes,+fma,+fma4,+bmi1,+bmi2,+xsave,+xsaveopt,+rdrand,check|Penryn,vendor=GenuineIntel,+hypervisor,+invtsc,kvm=on,+fma,+avx,+avx2,+aes,+ssse3,+sse4_2,+popcnt,+sse4a,+bmi1,+bmi2|host,vendor=GenuineIntel,+hypervisor,+invtsc,kvm=on,+fma,+avx,+avx2,+aes,+ssse3,+sse4_2,+popcnt,+sse4a,+bmi1,+bmi2" Mode="" Description=" CPU args for VM" Type="Variable" Display="always" Required="true" Mask="false">Skylake-Server,vendor=GenuineIntel,+hypervisor,+invtsc,kvm=on,+fma,+avx,+avx2,+aes,+ssse3,+sse4_2,+popcnt,+sse4a,+bmi1,+bmi2</Config> /boot/config/plugins/open.files.plg:prevent a clean shutdown of the array and lets you kill those /boot/config/domain.cfg:HOSTSHUTDOWN="shutdown" /boot/config/rsyslog.cfg:syslog_shutdown="" /boot/logs/syslog:Feb 21 20:34:28 NAS emhttpd: unclean shutdown detected /boot/logs/syslog-previous:Feb 18 11:20:59 NAS emhttpd: unclean shutdown detected Aber da steht ja auch der letzte "unclean shutdown" drin mit 20:34 Uhr am Freitag.

Hi zusammen, seit ca. 6 Wochen fährt mein Server gegen Freitagabend/Samstagmorgen eigenständig runter. Es lässt sich nicht auf eine exakte Zeit festlegen, es ist mehr oder weniger +/- 12 Stunden. Der Server wurde auch zwischenzeitlich immer mal wieder neu gestartet, sodass es auszuschließen ist, dass der Server nach einer gewissen Laufzeit ausgeht. Leistungsspitzen oder Stromausfälle kann ich auch ausschließen, da der Serverschrank an einer USV hängt (nicht direkt per USB mit dem Server verbunden) Ich habe keine Ahnung wieso, kann auch nichts in den Logs erkennen, habe kein derartiges User Script gesetzt, habe auch nichts in den BIOS Einstellungen gesetzt. Zum ersten Mal ist das im Urlaub passiert, es war also keiner zuhause. Ich hoffe ihr habt ein paar gute Ideen Danke schon mal

Yes, that will absolutely be the problem - the mappings in krusader are: I watched a video as I installed Krusader where these mappings were suggested.

I did what @JorgeB said and it looks like I found the 2 (!) Containers which cause the problem. - Krusader - Synology DSM If those containers are stopped, the array is able to stop, too. Synology is not really necessary for me anymore but I´m using Krusader sometimes. I will try to reinstall Krusader and check if that will help.

@Cannon den Thread hab ich gelesen und die Probleme scheinen identisch zu sein. Bei mir ist es auch der Cache der noch beschäftigt ist und das herunterfahren behindert.. Aber leider kann ich daraus nicht ableiten was ich tun soll um das Problem zu lösen. Ich hab "OpenFiles" installiert und mir wird da auch ne Latte an Prozessen angezeigt aber wenn ich auf "Kill" klicke, passiert auch einfach nichts.

The "Shell Stop" Plugin of Dynamix was already installed. I will try to restart emhttpd

Ok, now I tried what you said: 1. Stopped VM service 2. Stopped Docker service 3. Forced reboot 4. Started the array and DID NOT started VM and docker services 5. Stopping the array was successfull... But I do not know what to do now

Ok, got it - I will try that later and give feedback no, I did not stopped each individual container, I stopped the whole docker service in the settings. I will test it like @JorgeB said.

for my end, I stopped all docker services manually and AFTER that I tried to stop the array without success.