mgutt

Are you using IPv6? This could cause an issue if your provider assigns you a new IPv6 prefix while your br0 config contains the old IPv6. I never tested IPv6 and br0 again after it causes this problems. Thats why you find on the first page a "IPv6 Setup" tutorial by using the host network.

Meiner Ansicht nach fehlt in Unraid ein Einstellung, dass bei einem Shutdown jegliche Prozesse, die zB nach 5 Minuten noch auf den Shares hängen, einfach gekillt werden. Denn wenn eine leere USV dafür sorgt, dass der Server hart abschaltet, hat man ja auch nichts gewonnen.

Setz den Shutdown mit Zeit ab. Dh das Skript ist durch, das NAS sendet die E-Mail und ca 1 Minute später startet erst der Shutdown. zB: shutdown +5 Dann fährt der erst nach 5 Minuten herunter.

Ich mache das so bzw in dem Thread sind noch weitere Lösungsvorschläge:

Da sonst nichts vorhanden ist, würde ich den Kernel Fehler als Ursache sehen. TDARR hat denke ich einen inotifywait auf bestimmte Verzeichnisse laufen, damit der Dateiänderungen mitbekommt und dieses Verzeichnis löst dann irgendwas aus. Vielleicht ein Dateisystem-Fehler. ich würde mal die betroffenen Festplatten reparieren. Das sollte man bei Crashes sowieso machen. Kann man bei TDARR diese automatische Überwachung deaktivieren? Dann das mal ausprobieren, ob er dadurch nicht mehr abstürzt. Also erst mal nur um sich dem Problem zu nähern. Wenn das dann klar ist, sollte man prüfen auf welche Art TDARR das Verzeichnis überwacht. Also ist das ein 1:1 Pfad, der durchgeschliffen wird an den Container oder ein Mount auf einen anderen Server oder ein Hauptpfad von Unraid und evtl gibt es dadurch einen Konflikt, den man mit mit Slave oder Shared lösen kann?!

Fährt er denn sauber runter oder geht abrupt aus? Wenn er sauber herunterfährt, dann kann es ja nur ein Befehl sein. Sicher, dass du kein entsprechendes Plugin installiert hast zB das S3 Sleep Plugin? Ansonsten lass den Server mal im Safemode laufen, so dass er ohne Plugins läuft. Ansonsten hätte ich im Dateisystem nach Dateien gesucht, die das Kommando enthalten: grep -rI -e poweroff -e shutdown -e halt /etc /boot | grep -vP ":[[:space:]]*(#|-)" Mein Ergebnis mal zum Vergleich: /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... /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/inittab:ca::ctrlaltdel:/sbin/shutdown -t5 -r now /etc/rpc:walld 100008 rwall shutdown /etc/modprobe.d/kvm.conf:options kvm ignore_msrs=1 halt_poll_ns=0 /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/rc.d/rc.6:echo "Running shutdown script $0:" /etc/rc.d/rc.6: shutdown_command="halt" /etc/rc.d/rc.6: shutdown_command=reboot /etc/rc.d/rc.6:if [ -x /etc/rc.d/rc.local_shutdown ]; then /etc/rc.d/rc.6: /etc/rc.d/rc.local_shutdown stop /etc/rc.d/rc.6:[[ -r $CFG ]] && COPY=$(/bin/grep -Pom1 '^syslog_shutdown="\K[^"]+' $CFG) /etc/rc.d/rc.6:$shutdown_command -w /etc/rc.d/rc.6: echo "Clean shutdown" /etc/rc.d/rc.6: echo "Unclean shutdown - Cannot stop md/unraid driver" /etc/rc.d/rc.6:if [ "$shutdown_command" = "reboot" ]; then /etc/rc.d/rc.6: /sbin/poweroff /etc/rc.d/rc.K:if [ -x /etc/rc.d/rc.local_shutdown ]; then /etc/rc.d/rc.K: /etc/rc.d/rc.local_shutdown stop /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 /boot/config/domain.cfg:HOSTSHUTDOWN="shutdown" /boot/config/disk.cfg:shutdownTimeout="90" Also taucht bei dir ein Skript oder ähnliches auf, wo das Kommando drin stecken könnte?

Ist nach wie vor kaputt. Hier ein Test-Skript: #!/bin/bash # timestamping logs exec &> >(stdbuf -o0 sed 's/%/%%/g' | xargs -d '\n' -I {} date '+%F %T {}') echo "Start of script" # long running command tar -cv /mnt/disk1 | pv >/dev/null echo "End of script" Damit wird so getan als würde man was von Platte 1 woanders hin kopieren. Nun starte des Skript im Hintergrund. Dann breche ab. Im Dashboard siehst du nach wie vor, dass der mit voller Geschwindigkeit auf die Platte zugreift. So kann man dann manuell stoppen: pkill -xcf "tar -cv /mnt/disk1" Das User Scripts Plugin hat auch einen Bug, dass wenn das Skript sehr lange läuft, dass es das gar nicht mehr anzeigt. Oder anders gesagt. PHP startet ja das Skript, läuft dann aber selbst irgendwann in ein Timeout. Das hat den ekligen Nebeneffekt, dass besonders lange laufende Skripte gerne mal mehrfach parallel laufen.

As far as I know C7 was the best in my tests, but I'm not sure if I tested without the HBA card. Finally the X8X4X4 bifurcation riser should not influence the C-States as it is a passive card without any controller. So it should only depend on the used cards and/or motherboard bios how this influences the C-States. Not really. I gave up after they repeatedly asked if the 8TB NVMe SSD is working in a different system, although I already answered it. I don't think the 1st level support really understood my questions or wanted to answer them. But I think this is simply a general incompatibilty of the C246 chipset as the IronWolf 510 SSD had exactly the same problem: https://www.computerbase.de/forum/threads/selbstbau-nas-im-10-zoll-rack.1932675/page-13#post-25193006

Jo, so verstehe ich das auch. Unraid selbst sollte rein gar nichts loggen, wenn man sich mit dem rsync server container verbindet, da das zwei völlig unterschiedliche Betriebssysteme sind. Hier frage ich mich, warum der Port quasi doppelt angegeben wird. Ist das der richtige Syntax? Und das hier ist natürlich quatsch, weil der rsync server kein Passwort hat, sondern ausschließlich SSH Schlüssel akzeptiert: Wurde der ssh-key in OMV überhaupt mit dem Nutzer "root" erstellt oder mit einem anderen User? Hast du überhaupt einen SSH Key in OMV erzeugt? Das hier wird übrigens auch nicht gehen: Wenn du das machst: Du greifst damit auf den Pfad /mnt/user/arno zu, der nicht im Container existiert. Dort existiert zwar ein Pfad /mnt/user, aber der verweist auf /mnt/user/omv-rsync. Pushst du nun also Dateien nach /mnt/user/arno, dann landen sie in Unraid im Pfad /mnt/user/omv-rsync/arno, außer dass ist genau das was du willst. Fänd ich persönlich nur unnötig kompliziert nachzuvollziehen. Ich würde die Pfade einfach 1:1 übergeben. Dann muss man nich ständig um die Ecke denken.

Auf dem Client? Und der Public Key ist auch vom Client, von dem du dich verbindest? Du kannst auch direkt eine SSH Verbindung versuchen und die Ausgabe mit -v erweitern: ssh -v -p 5533 root@tower Er zeigt dir dann an welche lokale Schüsseldatei er verwendet hat, um sich mit dem Server zu verbinden. Ich habe zB gerade ganz frisch den Container installiert und einen SSH Key auf meinem Windows Client erzeugt. Auch das ging problemlos, um mich mit dem rsync server zu verbinden.

The older ASM controllers have the same problem as JMB controllers as far as I know. And if you want to use only 4 ports, the ASM1166 gives you better performance. So I would go with the ASM1166.

Enable websockets. This adds exactly these lines you mentioned.

Was it possible to receive an SSL cert? It yes, then maybe npm is not able to reach the Plex IP / Port. Different networks? Copying the config from someone else is no guarantee that it works as there are many different IP/port/network settings possible. My config as an example (npm runs on host network and Plex on bridge):

Did you already disable healthcheck? Maybe this stops those writes. You have to add --no-healthcheck to extra parameters:

I have been using a Seasonic SPX650 (I need a small source for Jonsbo n3) Now I have a Corsair RM750X out of the box and so far it has been running for two hours without any crashes Ok, this is a rare issue, but some power supplies switch off, if the power consumption falls under a specific value. For this case some BIOS have a setting to artificially raise the power consumption (but nobody really wants that).

Not sure why it differs without powertop, but finally it seems to be something with your hardware. Did you try to remove all additional components, so you only test board+ram+cpu?

As you said it crashes without powertop autotune, this shouldn't be necessary, but after 1-2 hours not crashing I would try it with powertop, too.

I have tried a new 14500 and same problem here, it keeps hanging when enabling C7 in the bios (after about an hour) Can you please try it with Ubuntu? Booting without installing from USB should be sufficient.

This is strange. Are you able to login through local display / keyboard if it hangs (so "only" Network is dead) or is it really frozen? Are you able to test the CPU on a different Mainboard?

Kernel errors can happen much further. Two hints: 1.) Install this: https://forums.unraid.net/topic/121039-syslog-notify-create-notifications-if-specific-words-occur-in-the-logs/ 2.) If it becomes unresponsive and does not restart: Connect a monitor and disable monitor sleep. When a crash happens, the monitor writes the kernel error to the display.

Did you check your logs? Maybe it is something completely different. Or an Unraid 7 bug?! Did you try a downgrade?

As this controller was released in 2021 it shouldn't be the I226V, but finally it could be still an issue with this controller or anything else on the board or... Did you update the firmware of the ASM1166? Older firmware versions had problems with deep sleeps states, but usually they didn't cause a system crash, "only" disconnected disks.

I still don't understand what you mean by "public". Are you talking about the SMB settings? SMB has nothing to do with local paths. I think it is because some paths in unraid are mounts. In this case it could be necessary to change the specific container path from "read" to "read shared" or "read slave".

I think this is pretty normal. Plex is not finished determining the intro / outro or maybe you even enabled thumbnail creation. I would wait.

Can you explain exactly which setting you changed?