W0nderW0lf

Also ich scheine das Problem jetzt doch selbst gelöst zu haben. 🫠 Ich habe den Server 3x runterfahren müssen. Visuell inspiziert und konnte keine lockeren oder schiefen kabel feststellen. Beim 2. Versuch hab ich mir dann die disk logs angesehen um zu erfahren welche der Festplatten streikt. Nochmal runtergefahren und geguckt ob bei der möglich defekten festplatte die Kabel nicht richtig sitzen. 1 PSU-Kabel verlängerung sieht etwas unschön geknickt aus, macht aber trotzdem noch einen funktionalen Eindruck. Das SATA Kabel saß ein mü schief, aber sollte eigentlich nicht wirklich die funktionalität beinträchtigen. Also alles nochmal rein gedrückt und geguckt das auch alles sitzt. Leider hatte das nichts geholfen. Beim starten des parity checks hat es instant angefangen zu "bremsen". Nochmal runtergefahren, aber diesmal habe ich beide Kabel durch andere ersetzt. Keine geräusche mehr. Parity check wieder bei der normalen Zeit.

Ich habe scheinbar doch schnell meinen schuldigen gefunden, aber mich wundert das, weil die 2. parity hdd nicht mal halb so alt is wie die 1. Wie würdet ihr die Meldung interpretieren und deckt sich das mit den SMART values?? May 9 11:30:52 NASty kernel: ata5: hard resetting link May 9 11:30:58 NASty kernel: ata5: link is slow to respond, please be patient (ready=0) May 9 11:31:00 NASty kernel: ata5: SATA link up 1.5 Gbps (SStatus 113 SControl 310) May 9 11:31:00 NASty kernel: ata5.00: configured for UDMA/33 May 9 11:31:00 NASty kernel: ata5: EH complete May 9 11:31:00 NASty kernel: ata5.00: exception Emask 0x10 SAct 0xf1000c SErr 0x48c0000 action 0xe frozen May 9 11:31:00 NASty kernel: ata5.00: irq_stat 0x04000040, connection status changed May 9 11:31:00 NASty kernel: ata5: SError: { CommWake 10B8B LinkSeq DevExch } May 9 11:31:00 NASty kernel: ata5.00: failed command: READ FPDMA QUEUED May 9 11:31:00 NASty kernel: ata5.00: cmd 60/40:10:00:65:01/05:00:00:00:00/40 tag 2 ncq dma 688128 in May 9 11:31:00 NASty kernel: ata5.00: status: { DRDY } May 9 11:31:00 NASty kernel: ata5.00: failed command: READ FPDMA QUEUED May 9 11:31:00 NASty kernel: ata5.00: cmd 60/08:18:40:6a:01/00:00:00:00:00/40 tag 3 ncq dma 4096 in May 9 11:31:00 NASty kernel: ata5.00: status: { DRDY } May 9 11:31:00 NASty kernel: ata5.00: failed command: READ FPDMA QUEUED May 9 11:31:00 NASty kernel: ata5.00: cmd 60/40:80:48:6a:01/05:00:00:00:00/40 tag 16 ncq dma 688128 in May 9 11:31:00 NASty kernel: ata5.00: status: { DRDY } May 9 11:31:00 NASty kernel: ata5.00: failed command: READ FPDMA QUEUED May 9 11:31:00 NASty kernel: ata5.00: cmd 60/40:a0:88:6f:01/05:00:00:00:00/40 tag 20 ncq dma 688128 in May 9 11:31:00 NASty kernel: ata5.00: status: { DRDY } May 9 11:31:00 NASty kernel: ata5.00: failed command: READ FPDMA QUEUED May 9 11:31:00 NASty kernel: ata5.00: cmd 60/40:a8:c8:74:01/05:00:00:00:00/40 tag 21 ncq dma 688128 in May 9 11:31:00 NASty kernel: ata5.00: status: { DRDY } May 9 11:31:00 NASty kernel: ata5.00: failed command: READ FPDMA QUEUED May 9 11:31:00 NASty kernel: ata5.00: cmd 60/78:b0:08:7a:01/00:00:00:00:00/40 tag 22 ncq dma 61440 in May 9 11:31:00 NASty kernel: ata5.00: status: { DRDY } May 9 11:31:00 NASty kernel: ata5.00: failed command: READ FPDMA QUEUED May 9 11:31:00 NASty kernel: ata5.00: cmd 60/40:b8:80:7a:01/05:00:00:00:00/40 tag 23 ncq dma 688128 in May 9 11:31:00 NASty kernel: ata5.00: status: { DRDY } May 9 11:31:00 NASty kernel: ata5: hard resetting link May 9 11:31:06 NASty kernel: ata5: link is slow to respond, please be patient (ready=0) May 9 11:31:07 NASty kernel: ata5: SATA link up 1.5 Gbps (SStatus 113 SControl 310) May 9 11:31:07 NASty kernel: ata5.00: configured for UDMA/33 May 9 11:31:07 NASty kernel: ata5: EH complete

Hi all, mir ist vor kurzem aufgefallen, dass eine meiner Festplatten wohl langsam das zeitliche segnen könnte. Ich höre bei einem parity check immer ein unschönes, sich alle 20 sekunden wiederholendes, geräusch. Höre hier gegen Ende: PXL_20260509_090334838.mp4 Allgemein fällt mir nichts während der Benutzung auf. Der letzte parity check ist ein paar Tage her und auch da hatte ich das geräusch aber das ging nach einer Weile wieder weg. Mittlerweile gehts ja gar nicht mehr weg. Ich vermute eine der HDD's hat bei einem Sektor schwierigkeiten und kann nicht fortfahren solange er das nicht vollständig gelesen hat. Leider finde ich die SMART values nicht wirklich aussagekräftig, weil bei mir alle als "healthy" deklariert werden. Ich habe noch eine Ersatzfestplatte da, aber ich weiß ja leider gar nicht mal welche ich austauschen muss. Beim normalen spin-up haben die platten kein problem. Kennt ihr tricks wie man schnell den schuldigen findet?

Got it! I stopped the array, set the timeout to 190 seconds and rebooted. No more "crash"

Currently it's set to 90 seconds. I haven't stopped my array yet. So in terms of a safe shutdown it's better to have a longer timeout to make sure the whole array had enough time to stop, right? Do I have to track the time myself or is the time to stop the array displayed on the GUI? And Thanks for the quick help.

Hi everyone, I just noticed that when I clean shutdown my system, either via button or GUI, the server starts a parity check after my maintenance. I see the following notifications: I already had this twice in the past but never found time to check this. The server runs for weeks without reboot or issues. Now I want to find the reason for this unclean shutdown. nasty-diagnostics-20260414-1941.zip Do you guys have any special tool's to analyze the diagnostics.zip, or do you analyze it file by file with an IDE? I like analyzing it myself, but I have no clue where to look first and I don't have that much time if I have no idea to what I could look first. If there would be a intellij or vscode plugin that could make a small report out of that log, that would be awesome. I appreciate every help.

Forgot this topic existed. It turned out that I ran a hytale server and that it can cause random memory leaks on high load, causing unraid to hiccup. I had to adjust the max rendering distance in the config.json from hytale. No more issues So potentially for you guys maybe could also have some service running that randomly increases ram usage and exhaust the server.

I think I found my suspect. Seems like hytale server is pretty resource hungry and causes memory leaks. I don't experience lags or performance issues when we play on the server and it just recently started to "crash", but never made it to check the logs if that happens. I now lowered the maxrendering distance. I discovered this because I wondered why my Fan's randomly start to spin faster in safe mode. But only when the hytale server runs. I have 16GB of RAM, because I only have 2 slots available and DDR4 prices are insane rn. Looking at the processes I saw that the hytale java process consumed almost 50% RAM in idle. For now I will observe that and will try to fine tune things to prevent further crashes.

okay... I think the CPU is not faulty. CPU stress passed switched cpu - same problems with unraid. But today I encountered a different behaviour. While playing with my son, we got thrown out of our hytale server again. Unraid wasn't responding for maybe 4 minutes and came back. Couple of minutes later we got thrown out again. If that happens I am unable to connect to the server, but I might be able to use JetKVM to access the console. Unfortunately as soon as I enter the username and hit enter, I receive a timeout after 60 seconds, but I can repeat it over and over.. Just like here: When I pressed the power button, the server shutdown as if nothing happened. Today after being thrown out of my server again, the Server struggled to end processes. Like if something held unraid up and didn't wanted to stop its job. This is the log I captured from the first timeout encounter to the last before I pressed the power button. Feb 9 16:00:11 NASty move: No new files will be moved/synced from primary to secondary Feb 9 16:00:11 NASty move: No new files will be moved/synced from secondary to primary Feb 9 16:00:11 NASty move: Action started at: 16:00:11 Feb 9 16:00:11 NASty move: Cleaning lock and stop files Feb 9 16:00:11 NASty move: Action ended at: 16:00:11 Feb 9 16:00:11 NASty move: Elapsed time: 0 sec Feb 9 16:00:11 NASty move: ****************************************************************** WE ARE DONE ! **************************************************************** Feb 9 16:00:19 NASty php-fpm[11243]: [WARNING] [pool www] server reached max_children setting (50), consider raising it Feb 9 16:05:07 NASty php-fpm[11243]: [WARNING] [pool www] child 1123945 exited on signal 9 (SIGKILL) after 288.839758 seconds from start Feb 9 16:06:04 NASty php-fpm[11243]: [WARNING] [pool www] child 1123946 exited on signal 9 (SIGKILL) after 312.984302 seconds from start Feb 9 16:08:57 NASty php-fpm[11243]: [WARNING] [pool www] child 1123947 exited on signal 9 (SIGKILL) after 391.020086 seconds from start Feb 9 16:08:58 NASty sshd-session[1138551]: Connection from 192.168.1.100 port 47624 on 192.168.200.2 port 8908 rdomain "" Feb 9 16:08:59 NASty php-fpm[11243]: [WARNING] [pool www] child 1123948 exited on signal 9 (SIGKILL) after 520.342596 seconds from start Feb 9 16:09:05 NASty emhttpd: spinning down /dev/sdd Feb 9 16:09:08 NASty emhttpd: read SMART /dev/sdd Feb 9 16:09:14 NASty php-fpm[11243]: [WARNING] [pool www] child 1123959 exited on signal 9 (SIGKILL) after 535.502147 seconds from start Feb 9 16:09:16 NASty sshd-session[1138551]: Postponed keyboard-interactive for root from 192.168.1.100 port 47624 ssh2 [preauth] Feb 9 16:09:16 NASty sshd-session[1138551]: Postponed keyboard-interactive/pam for root from 192.168.1.100 port 47624 ssh2 [preauth] Feb 9 16:09:16 NASty sshd-session[1138551]: Accepted keyboard-interactive/pam for root from 192.168.1.100 port 47624 ssh2 Feb 9 16:09:16 NASty sshd-session[1138551]: pam_unix(sshd:session): session opened for user root(uid=0) by (uid=0) Feb 9 16:09:16 NASty sshd-session[1138551]: User child is on pid 1139417 Feb 9 16:09:16 NASty sshd-session[1139417]: Starting session: shell on pts/0 for root from 192.168.1.100 port 47624 id 0 Feb 9 16:24:10 NASty emhttpd: spinning down /dev/sdh Feb 9 16:24:10 NASty emhttpd: spinning down /dev/sdg Feb 9 16:24:11 NASty emhttpd: spinning down /dev/sdd Feb 9 16:24:11 NASty emhttpd: spinning down /dev/sdf Feb 9 16:24:19 NASty emhttpd: spinning down /dev/sdc Feb 9 16:31:53 NASty emhttpd: read SMART /dev/sdf Feb 9 16:47:00 NASty emhttpd: spinning down /dev/sdf Feb 9 16:48:29 NASty php-fpm[11243]: [WARNING] [pool www] child 1123954 exited on signal 9 (SIGKILL) after 2890.598371 seconds from start Feb 9 16:48:29 NASty emhttpd: read SMART /dev/sdg Feb 9 16:48:29 NASty emhttpd: read SMART /dev/sdc Feb 9 16:48:36 NASty emhttpd: read SMART /dev/sdh Feb 9 16:48:43 NASty emhttpd: read SMART /dev/sdf Feb 9 16:52:33 NASty php-fpm[11243]: [WARNING] [pool www] child 1123955 exited on signal 9 (SIGKILL) after 3133.934713 seconds from start Feb 9 16:52:34 NASty php-fpm[11243]: [WARNING] [pool www] child 1123957 exited on signal 9 (SIGKILL) after 3135.573704 seconds from start Feb 9 16:53:34 NASty php-fpm[11243]: [WARNING] [pool www] child 1123956 exited on signal 9 (SIGKILL) after 3195.051690 seconds from start Feb 9 16:54:12 NASty emhttpd: read SMART /dev/sdd Feb 9 16:54:54 NASty php-fpm[11243]: [WARNING] [pool www] child 1123960 exited on signal 9 (SIGKILL) after 3274.926191 seconds from start Feb 9 16:54:55 NASty php-fpm[11243]: [WARNING] [pool www] child 1123961 exited on signal 9 (SIGKILL) after 3276.808240 seconds from start Feb 9 16:55:09 NASty php-fpm[11243]: [WARNING] [pool www] child 1123962 exited on signal 9 (SIGKILL) after 3289.948800 seconds from start Feb 9 16:55:22 NASty php-fpm[11243]: [WARNING] [pool www] child 1124182 exited on signal 9 (SIGKILL) after 3287.654819 seconds from start Feb 9 16:55:28 NASty php-fpm[11243]: [WARNING] [pool www] child 1138320 exited on signal 9 (SIGKILL) after 2949.016911 seconds from start Feb 9 16:55:32 NASty php-fpm[11243]: [WARNING] [pool www] child 1139340 exited on signal 9 (SIGKILL) after 2777.326532 seconds from start Feb 9 16:55:39 NASty php-fpm[11243]: [WARNING] [pool www] child 1139405 exited on signal 9 (SIGKILL) after 2779.985190 seconds from start After pressing the power button: I am currently trying to run the server in safe mode with my containers on but plugins off. One of both might be interfering.

Just experienced that today: Feb 9 16:00:19 NASty php-fpm[11243]: [WARNING] [pool www] server reached max_children setting (50), consider raising it Feb 9 16:05:07 NASty php-fpm[11243]: [WARNING] [pool www] child 1123945 exited on signal 9 (SIGKILL) after 288.839758 seconds from start Feb 9 16:06:04 NASty php-fpm[11243]: [WARNING] [pool www] child 1123946 exited on signal 9 (SIGKILL) after 312.984302 seconds from start Feb 9 16:08:57 NASty php-fpm[11243]: [WARNING] [pool www] child 1123947 exited on signal 9 (SIGKILL) after 391.020086 seconds from startDont know if it might be a bug or issues with the hardware, because I struggle in another topic with strange behaving unraid.

Ignore what I said... I just rebooted the server and switched components. Maybe it was a caching issue, because I have some technical difficulties with the server. It works now.

Well, seems like the forum changed the format, because that's how I created the rules. In individual lines. seperated by return. But the return gets also removed. Just like so: 192.168.1.100(rw,all_squash,anonuid=99,anongid=100) 192.168.1.20(rw,all_squash,anonuid=99,anongid=100)

Hi @ll, I wanted to add a list of multiple hosts to an nfs share. As I found out, we can limit NFS shares by adding a rule in a way like this: 192.168.1.100(rw,all_squash,anonuid=99,anongid=100) 192.168.1.20(rw,all_squash,anonuid=99,anongid=100)But as soon as I hit apply, the whitespace disappears and saves it like that: 192.168.1.100(rw,all_squash,anonuid=99,anongid=100)192.168.1.20(rw,all_squash,anonuid=99,anongid=100)The rule is not working and forcing me to remove the second host part and leave it enabled for the whole subnet. Is this a bug or a feature? Is this even possible to set via WebUI? This is not

I am not sure, but I have the suspicion that it could be the CPU. Might it be possible to stress test the CPU with cpufreq? The RAM recently passed the test.

It happened again. This is all I could find, but its more than yesterday. I also noticed that the WebUI becomes slower over time. Feb 8 09:00:20 NASty move: Elapsed time: 0 sec Feb 8 09:00:20 NASty move: ****************************************************************** WE ARE DONE ! **************************************************************** Feb 8 09:04:01 NASty emhttpd: read SMART /dev/sdc Feb 8 09:06:47 NASty ntpd[2516]: RATE KoD from 62.108.36.235 poll 1024 Feb 8 09:10:59 NASty winbindd[120300]: [2026/02/08 09:10:58.481800, 0, traceid=1919] ../../source3/winbindd/winbindd_samr.c:71(open_internal_samr_conn) Feb 8 09:10:59 NASty winbindd[120300]: open_internal_samr_conn: Could not connect to samr pipe: NT_STATUS_CONNECTION_DISCONNECTED Feb 8 09:11:12 NASty winbindd[120298]: [2026/02/08 09:11:02.461850, 0, traceid=1919] ../../source3/winbindd/winbindd.c:820(winbind_client_processed) Feb 8 09:11:12 NASty winbindd[120298]: winbind_client_processed: request took 60.391927 seconds Feb 8 09:11:14 NASty winbindd[120298]: [struct process_request_state] ../../source3/winbindd/winbindd.c:439 [2026/02/08 09:10:01.507533] ../../source3/winbindd/winbindd.c:620 [2026/02/08 09:11:01.899460] [60.391927] -> TEVENT_REQ_DONE (2 0)) Feb 8 09:11:14 NASty winbindd[120298]: [struct winbindd_getgroups_state] ../../source3/winbindd/winbindd_getgroups.c:55 [2026/02/08 09:10:01.507540] ../../source3/winbindd/winbindd_getgroups.c:172 [2026/02/08 09:11:01.899340] [60.391800] -> TEVENT_REQ_USER_ERROR (3 10483072397370982924)) Feb 8 09:11:14 NASty winbindd[120298]: [struct wb_parent_idmap_setup_state] ../../source3/winbindd/winbindd_idmap.c:163 [2026/02/08 09:10:01.507542] ../../source3/winbindd/winbindd_idmap.c:175 [2026/02/08 09:10:01.507542] [0.000000] -> TEVENT_REQ_DONE (2 0)) Feb 8 09:11:14 NASty winbindd[120298]: [struct dcerpc_wbint_NormalizeNameUnmap_state] librpc/gen_ndr/ndr_winbind_c.c:6696 [2026/02/08 09:10:01.535567] librpc/gen_ndr/ndr_winbind_c.c:6759 [2026/02/08 09:10:02.135655] [0.600088] -> TEVENT_REQ_DONE (2 0)) Feb 8 09:11:14 NASty winbindd[120298]: [struct dcerpc_wbint_NormalizeNameUnmap_r_state] librpc/gen_ndr/ndr_winbind_c.c:6611 [2026/02/08 09:10:01.583392] librpc/gen_ndr/ndr_winbind_c.c:6646 [2026/02/08 09:10:02.135653] [0.552261] -> TEVENT_REQ_DONE (2 0)) Feb 8 09:11:14 NASty winbindd[120298]: [struct dcerpc_binding_handle_call_state] ../../librpc/rpc/binding_handle.c:414 [2026/02/08 09:10:01.631425] ../../librpc/rpc/binding_handle.c:564 [2026/02/08 09:10:02.135645] [0.504220] -> TEVENT_REQ_DONE (2 0)) Feb 8 09:11:14 NASty winbindd[120298]: [struct dcerpc_binding_handle_raw_call_state] ../../librpc/rpc/binding_handle.c:192 [2026/02/08 09:10:01.796834] ../../librpc/rpc/binding_handle.c:247 [2026/02/08 09:10:02.135640] [0.338806] -> TEVENT_REQ_DONE (2 0)) Feb 8 09:11:14 NASty winbindd[120298]: [struct wbint_bh_raw_call_state] ../../source3/winbindd/winbindd_dual_ndr.c:102 [2026/02/08 09:10:01.796840] ../../source3/winbindd/winbindd_dual_ndr.c:179 [2026/02/08 09:10:02.135630] [0.338790] -> TEVENT_REQ_DONE (2 0)) Feb 8 09:11:14 NASty winbindd[120298]: [struct wb_child_request_state] ../../source3/winbindd/winbindd_dual.c:203 [2026/02/08 09:10:01.796855] ../../source3/winbindd/winbindd_dual.c:306 [2026/02/08 09:10:02.135627] [0.338772] -> TEVENT_REQ_DONE (2 0)) Feb 8 09:11:14 NASty winbindd[120298]: [struct tevent_queue_wait_state] ../../tevent_queue.c:408 [2026/02/08 09:10:01.796859] ../../tevent_queue.c:429 [2026/02/08 09:10:01.796877] [0.000018] -> TEVENT_REQ_DONE (2 0)) Feb 8 09:11:14 NASty winbindd[120298]: [struct wb_simple_trans_state] ../../nsswitch/wb_reqtrans.c:375 [2026/02/08 09:10:01.796892] ../../nsswitch/wb_reqtrans.c:432 [2026/02/08 09:10:02.135621] [0.338729] -> TEVENT_REQ_DONE (2 0)) Feb 8 09:11:14 NASty winbindd[120298]: [struct req_write_state] ../../nsswitch/wb_reqtrans.c:158 [2026/02/08 09:10:01.796893] ../../nsswitch/wb_reqtrans.c:194 [2026/02/08 09:10:01.797089] [0.000196] -> TEVENT_REQ_DONE (2 0)) Feb 8 09:11:14 NASty winbindd[120298]: [struct writev_state] ../../lib/async_req/async_sock.c:361 [2026/02/08 09:10:01.796895] ../../lib/async_req/async_sock.c:483 [2026/02/08 09:10:01.797087] [0.000192] -> TEVENT_REQ_DONE (2 0)) Feb 8 09:11:14 NASty winbindd[120298]: [struct resp_read_state] ../../nsswitch/wb_reqtrans.c:222 [2026/02/08 09:10:01.797091] ../../nsswitch/wb_reqtrans.c:275 [2026/02/08 09:10:02.135620] [0.338529] -> TEVENT_REQ_DONE (2 0)) Feb 8 09:11:14 NASty winbindd[120298]: [struct read_packet_state] ../../lib/async_req/async_sock.c:578 [2026/02/08 09:10:01.797092] ../../lib/async_req/async_sock.c:713 [2026/02/08 09:10:02.135616] [0.338524] -> TEVENT_REQ_DONE (2 0)) Feb 8 09:11:14 NASty winbindd[120298]: [struct wb_lookupname_state] ../../source3/winbindd/wb_lookupname.c:47 [2026/02/08 09:10:02.165638] ../../source3/winbindd/wb_lookupname.c:99 [2026/02/08 09:11:01.899336] [59.733698] -> TEVENT_REQ_USER_ERROR (3 10483072397370982924)) Feb 8 09:11:14 NASty winbindd[120298]: [struct dcerpc_wbint_LookupName_state] librpc/gen_ndr/ndr_winbind_c.c:795 [2026/02/08 09:10:02.247415] librpc/gen_ndr/ndr_winbind_c.c:862 [2026/02/08 09:11:01.899300] [59.651885] -> TEVENT_REQ_DONE (2 0)) Feb 8 09:11:14 NASty winbindd[120298]: [struct dcerpc_wbint_LookupName_r_state] librpc/gen_ndr/ndr_winbind_c.c:707 [2026/02/08 09:10:02.247422] librpc/gen_ndr/ndr_winbind_c.c:742 [2026/02/08 09:11:01.899294] [59.651872] -> TEVENT_REQ_DONE (2 0)) Feb 8 09:11:14 NASty winbindd[120298]: [struct dcerpc_binding_handle_call_state] ../../librpc/rpc/binding_handle.c:414 [2026/02/08 09:10:02.247424] ../../librpc/rpc/binding_handle.c:564 [2026/02/08 09:11:01.427627] [59.180203] -> TEVENT_REQ_DONE (2 0)) Feb 8 09:11:14 NASty winbindd[120298]: [struct dcerpc_binding_handle_raw_call_state] ../../librpc/rpc/binding_handle.c:192 [2026/02/08 09:10:02.247438] ../../librpc/rpc/binding_handle.c:247 [2026/02/08 09:11:01.358035] [59.110597] -> TEVENT_REQ_DONE (2 0)) Feb 8 09:11:14 NASty winbindd[120298]: [struct wbint_bh_raw_call_state] ../../source3/winbindd/winbindd_dual_ndr.c:102 [2026/02/08 09:10:02.247441] ../../source3/winbindd/winbindd_dual_ndr.c:223 [2026/02/08 09:11:01.057226] [58.809785] -> TEVENT_REQ_DONE (2 0)) Feb 8 09:11:14 NASty winbindd[120298]: [struct wb_domain_request_state] ../../source3/winbindd/winbindd_dual.c:523 [2026/02/08 09:10:02.293029] ../../source3/winbindd/winbindd_dual.c:769 [2026/02/08 09:11:01.015370] [58.722341] -> TEVENT_REQ_DONE (2 0)) Feb 8 09:11:14 NASty winbindd[120298]: [struct wb_child_request_state] ../../source3/winbindd/winbindd_dual.c:203 [2026/02/08 09:10:02.293058] ../../source3/winbindd/winbindd_dual.c:306 [2026/02/08 09:11:01.015367] [58.722309] -> TEVENT_REQ_DONE (2 0)) Feb 8 09:11:14 NASty winbindd[120298]: [struct tevent_queue_wait_state] ../../tevent_queue.c:408 [2026/02/08 09:10:02.293059] ../../tevent_queue.c:429 [2026/02/08 09:10:02.293060] [0.000001] -> TEVENT_REQ_DONE (2 0)) Feb 8 09:11:14 NASty winbindd[120298]: [struct wb_simple_trans_state] ../../nsswitch/wb_reqtrans.c:375 [2026/02/08 09:10:02.293062] ../../nsswitch/wb_reqtrans.c:432 [2026/02/08 09:11:01.015358] [58.722296] -> TEVENT_REQ_DONE (2 0)) Feb 8 09:11:14 NASty winbindd[120298]: [struct req_write_state] ../../nsswitch/wb_reqtrans.c:158 [2026/02/08 09:10:02.293062] ../../nsswitch/wb_reqtrans.c:194 [2026/02/08 09:10:02.293086] [0.000024] -> TEVENT_REQ_DONE (2 0)) Feb 8 09:11:14 NASty winbindd[120298]: [struct writev_state] ../../lib/async_req/async_sock.c:361 [2026/02/08 09:10:02.293062] ../../lib/async_req/async_sock.c:483 [2026/02/08 09:10:02.293086] [0.000024] -> TEVENT_REQ_DONE (2 0)) Feb 8 09:11:14 NASty winbindd[120298]: [struct resp_read_state] ../../nsswitch/wb_reqtrans.c:222 [2026/02/08 09:10:02.293087] ../../nsswitch/wb_reqtrans.c:275 [2026/02/08 09:11:01.015357] [58.722270] -> TEVENT_REQ_DONE (2 0)) Feb 8 09:11:14 NASty winbindd[120298]: [struct read_packet_state] ../../lib/async_req/async_sock.c:578 [2026/02/08 09:10:02.293087] ../../lib/async_req/async_sock.c:713 [2026/02/08 09:11:01.015346] [58.722259] -> TEVENT_REQ_DONE (2 0)) Feb 8 09:11:14 NASty winbindd[120298]: [struct resp_write_state] ../../nsswitch/wb_reqtrans.c:307 [2026/02/08 09:11:01.899377] ../../nsswitch/wb_reqtrans.c:344 [2026/02/08 09:11:01.899457] [0.000080] -> TEVENT_REQ_DONE (2 0)) Feb 8 09:11:14 NASty winbindd[120298]: [struct writev_state] ../../lib/async_req/async_sock.c:361 [2026/02/08 09:11:01.899380] ../../lib/async_req/async_sock.c:483 [2026/02/08 09:11:01.899421] [0.000041] -> TEVENT_REQ_DONE (2 0)) Feb 8 09:11:49 NASty emhttpd: read SMART /dev/sdd

So over an hour ago, the server randomly disappeared again. We noticed this while playing hytale and got thrown out of the server. WebUI, HDMI, and power button where not responding. After I killed the server, the log doesn't seem to trace anything useful. Is there a way add a debugging log level? The Server crashed at 18:20. Feb 7 17:52:51 NASty emhttpd: spinning down /dev/sdb Feb 7 17:54:50 NASty winbindd[2703]: [2026/02/07 17:54:49.500070, 0, traceid=21888] ../../source3/winbindd/winbindd_samr.c:71(open_internal_samr_conn) Feb 7 17:54:50 NASty winbindd[2703]: open_internal_samr_conn: Could not connect to samr pipe: NT_STATUS_CONNECTION_DISCONNECTED Feb 7 18:09:17 NASty emhttpd: read SMART /dev/sdd Feb 7 18:34:29 NASty rc.rsyslogd: Syslog server daemon... Started. Feb 7 18:34:29 NASty enhanced.log: Enabling Syslog filter... edit: just checked the syslog-previous log at /boot/logs/syslog-previous and found this interesting: Feb 7 18:09:17 NASty emhttpd: read SMART /dev/sdd Feb 7 18:20:01 NASty webgui: curl error: Recv failure: Connection reset by peer endpoint: wlan0 Feb 7 18:24:37 NASty init: Switching to runlevel: 0

I've set remote syslog server to 127.0.0.1... now it created a file. Gonna have to bring back that old server in the near future. I will reply back if another crash happen.

Hmm... well... seems like something not rly working. I had to take the syslog server offline a couple of days ago, but that should nethertheless write it locally if enabled, right?

It is and I thought it would have been added to the diagnostics. Where is it usually being stored? I have also set 'write to flash: true'

hi all, I for a couple of days now experience freezes when I am trying to interact with maybe radarr or overseer.. I also had this when I was starting a VM. Just before the Windows boot logo disappeared, the Server and UI froze. I am unable to SSH into the server if that happens, so I painfully have to hard kill the server. I tried to close tabs and wait for a while, but it didn't came back. Is my rig dying or just the stick having hickups? II found these lines interesting. Feb 4 19:04:53 NASty move: Action ended at: 19:04:53 Feb 4 19:04:53 NASty move: Elapsed time: 0 sec Feb 4 19:04:53 NASty move: ****************************************************************** WE ARE DONE ! **************************************************************** Feb 4 19:10:16 NASty emhttpd: read SMART /dev/sdh Feb 4 19:10:16 NASty emhttpd: read SMART /dev/sdg Feb 4 19:10:16 NASty emhttpd: read SMART /dev/sdd Feb 4 19:10:16 NASty emhttpd: read SMART /dev/sdf Feb 4 19:18:13 NASty winbindd[2704]: [2026/02/04 19:18:11.659256, 0, traceid=6164] ../../source3/winbindd/winbindd_samr.c:71(open_internal_samr_conn) Feb 4 19:18:13 NASty winbindd[2704]: open_internal_samr_conn: Could not connect to samr pipe: NT_STATUS_CONNECTION_DISCONNECTED Feb 4 19:31:45 NASty emhttpd: spinning down /dev/sdh Feb 4 19:33:35 NASty emhttpd: spinning down /dev/sdg Feb 4 19:35:08 NASty winbindd[2704]: [2026/02/04 19:35:08.248834, 0, traceid=6200] ../../source3/winbindd/winbindd_samr.c:71(open_internal_samr_conn) Feb 4 19:35:08 NASty winbindd[2704]: open_internal_samr_conn: Could not connect to samr pipe: NT_STATUS_CONNECTION_DISCONNECTED Feb 4 19:35:42 NASty emhttpd: spinning down /dev/sdd Feb 4 19:42:24 NASty sshd-session[3014530]: Connection from 192.168.1.100 port 38368 on 192.168.200.2 port 8908 rdomain "" Feb 4 19:42:48 NASty init: Switching to runlevel: 0 Feb 4 19:42:49 NASty shutdown[3014738]: shutting down for system haltU can check the full log here: nasty-diagnostics-20260204-2105.zip

Ich bin nicht so aktuell was HW angeht aber sind die Xeon's nicht eigentlich strom hungrige server cpu's? Noch transkodiere ich nicht viel, aber ich rechne damit das die Last höher wird sobald ich den Nutzerkreis in der Family erhöhe.. Da plane ich lieber mehr ein und mach mir weniger sorgen um die Leistung.

Vielen Dank erstmal für euren Input. Ich nutze primär Plex und wollte den Server auch mit der Family teilen und bin mir bei meinen 16 containern, eventuellen 1-2 4k streams immer etwas unsicher ob ich da gut transcoden und ne VM parallel betreiben könnte. Aktuell habe ich ein ITX mit einer i9-11900 und habe gestern erst wieder nen server crash beim starten einer VM erlebt. (Weiß nicht ob's am RAM, der VM config oder der CPU lag) aber ich hatte gehofft mit einer GPU nimmt man der CPU eine gewisse Last weg. Ich bin auch unsicher ob eine GPU wirklich dauerhaft aktiv ist, oder ebenfalls in D3cold wechseln könnte und nur bei bedarf vom Plex bzw. einer VM aufgeweckt wird. Wenn die im idle oder schlaf vllt 5-6w verbraucht, wäre das ja noch zu verkraften. Aber ja unter 20w käme man damit bestimmt schwer. Ich habe auch eben erst gelesen, dass die Intel Arc Karten nicht wirklich effizient im idle sind. Aber ich denke GraKa's die es sind, wären nicht bestimmt nicht billig. Die Intel Arc Karten bekommt man gebraucht hinterher geworfen. Die 10G wären für mich eher optional, solange die Allgemeine Systemleistung stimmt. Ich könnte auch mit 2.5G leben, aber wenn ich schon ein board und die slots hab, wäre das ein nice to have. Nutzt ihr ECC Ram? Könntet Ihr da was empfehlen? Ich gedenke mir einen eigenen Tower ausm 3D Drucker zu basteln. Hab bereits einen für mein ITX und liebe es. Würde die Kühlung mit rein konstruieren.

Moin moin, ich bin auf der Jagd nach dem besten Kompromiss in Sachen Leistung und Sparsamkeit. Eigentlich bevorzuge ich ITX builds wegen des Formfaktors, aber ich bin dazu geneigt mir ein mATX Build zu zulegen. Was bereits an Hardware habe: 6x4TB Seagate Ironwolf (mit Luft nach oben) 1-2 NVME's 1-2TB Samsung's 2x 8GB Gskill DDR4 Ram (Idealerweise ein board was die auch supported... will keinen neuen gebrauchten RAM kaufen :D ) Was ich gerne erreichen würde: Ich würde gerne unter die 20 Watt kommen. (Idealerweise mit c10 sogar auf um die 10w wenn's möglich wäre) Ich hätte gerne eine günstige sparsame GPU (wäre da Intel Arc ne gute Wahl?) 10Gb NIC Docker + 1 VM parallel betreiben (ja wenn VM läuft verbraucht der mehr, aber ich will sie nur im Bedarfsfall einschalten) Ist Ryzen immer noch so ein Stromfresser, oder hat sich das mittlerweile gelegt? Könntet Ihr da was empfehlen?

Also ich hab gestern mal zum test linux mint auf einem Stick betrieben und bin ein bischen schlauer, habe aber noch keine Lösung. Über Powertop konnte ich alle tunables auf good setzen. Habe dann manuell alle platten runter gefahren. Nur die NVME lies sich nach wie vor nicht beeinflussen. Erstaunlich fand ich das das mint im idle C2 (94%) erreicht hat und 20Wverbraucht, wohingegen Unraid nur auf C2 (54%) kommt und 26W verbraucht. Da frage ich mich widerum, warum verbraucht unraid so viel fürs fast nix tun? Ich habe keine permanent laufenden cronjobs und das gleiche Ergebnis liefert unraid wenn ich alle container beende. vm ist generell nie an. Ich habe mal ein Ticket bei gigabyte eröffnet und möchte von denen erfahren warum das BIOS / Mainboard nicht mit der SSD harmoniert. Z.B. gab es im proxmox forum das gegenteilige problem, dass die user nicht von D3cold (spar modus) in D0 (high usage) wechseln konnten. Somit würde die SSD tiefere sleep-states supporten. Zusammengefasst: ASPM Native und power management platform sind beide enabled. c-states bis 10 sind aktiv. ERP (on/off) bringt keine Änderung.. (Turbo Energy efficient / turbo mode / turbo max 3.0 (on-off)) macht auch keine Änderung. ASPM ist supported und funktioniert für alle geräte die sich abschalten lassen. [ 1.327682] acpi PNP0A08:00: _OSC: OS supports [ExtendedConfig ASPM ClockPM Segments MSI HPX-Type3]Autotweak settings: 07:00.0 Non-Volatile memory controller: Samsung Electronics Co Ltd NVMe SSD Controller S4LV008[Pascal] (prog-if 02 [NVM Express]) Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 NoSoftRst+ PME-Enable- DSel=0 DScale=0 PME- Capabilities: Port #0, Speed 16GT/s, Width x4, ASPM L1, Exit Latency L1 <64us Settings: ASPM L1 Enabled; RCB 64 bytes, LnkDisable- CommClk+ Status: Speed 8GT/s (downgraded), Width x4 ASPM Capabilities: PCI-PM_L1.2+ PCI-PM_L1.1+ ASPM_L1.2+ ASPM_L1.1+ L1_PM_Substates+ ASPM Settings: PCI-PM_L1.2+ PCI-PM_L1.1+ ASPM_L1.2+ ASPM_L1.1+Klar zu erkennen ist hier D0 (high usage mode) und PME-Enable(-) was so viel heißt wie "power management events disabled". Das APST wiederum, was die virtuellen power states anbelangt, kommt ohne probleme weiterhin bis in power state 4 (sparsamste stufe mit 0,005w) was sich aber nicht mit der anzeige in der WebUI mit 0,01w deckt.

Bezüglich testen... Ne Ahnung ob ich mit einem live USB (anderes OS als Unraid) die ASPM bzw. c-state Fähigkeit testen kann? Dachte an sowas wie mint oder windoof mit energiespar settings. Schon mal Erfahrung damit gesammelt? Würde gerne ausschließen das es an unraid liegt.