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