Hi, could you please help me resolve the issue with my Unraid NAS?

It crashes / becomes unresponsive / disconnects from my network on a daily basis. Only reboots help.

Normally, after each reboot it works fine, all docker containers start without any issues, it has network connectivity etc.

It may last for about 15-26 hours (I don't think I ever had uptime longer than 1 day +- a couple of hours) but then crashes.

It disconnects from the network, UniFi web UI shows that it is no longer connected, I can't ssh to it.

After each reboot, I check syslogs, but there's usually nothing useful in there.

Some suspicious log entries that sometimes get recorded:

1. Lots and lots logs like this:

   kernel: docker0: port 4(veth817eac8) entered disabled state

   kernel: veth817eac8 (unregistering): left allmulticast mode

   kernel: veth817eac8 (unregistering): left promiscuous mode

   kernel: docker0: port 4(veth817eac8) entered disabled state

   kernel: docker0: port 3(veth8a8e364) entered disabled state

   kernel: veth04a9b1e: renamed from eth0

   kernel: docker0: port 3(veth8a8e364) entered disabled state

   kernel: veth8a8e364 (unregistering): left allmulticast mode

   kernel: veth8a8e364 (unregistering): left promiscuous mode

   kernel: docker0: port 3(veth8a8e364) entered disabled state

   kernel: docker0: port 3(vetha9e0863) entered blocking state

   kernel: docker0: port 3(vetha9e0863) entered disabled state

   kernel: vetha9e0863: entered allmulticast mode

   kernel: vetha9e0863: entered promiscuous mode

Some say it's perfectly normal and could be ignored, some say it's an issue, it means that docker containers keep restarting, and/or have conflicting IPs/ports. I checked all port allocations and there are no conflicts.

2. Often I see logs related to TimeMachine backups / SAMBA. Time Machine shows that backups work fine, so I suppose those are just occasional disconnects?

smbd[1937180]: smb2_sendfile_send_data: sendfile failed for file Cygnus.sparsebundle/bands/194 (Connection reset by peer) for client PID=1937180,CLIENT=f828ddeb-e6fe-404c-9375-9b8f406a8ef2,channel=0,remote=ipv4:192.168.1.125:63851,local=ipv4:192.168.1.65:445. Terminating

rpcd_mdssvc[2007868]: [2025/12/20 10:53:44.086513, 0] ../../source3/rpc_server/mdssvc/mdssvc.c:1710(mds_init_ctx)

rpcd_mdssvc[2007868]: mds_init_ctx: Unknown backend 1

rpcd_mdssvc[2007868]: [2025/12/20 10:53:44.086547, 0] ../../source3/rpc_server/mdssvc/srv_mdssvc_nt.c:129(_mdssvc_open)

rpcd_mdssvc[2007868]: mdssvcopen: Couldn't create policy handle for timeMachine

3. When it actually crashes, there's nothing suspicious. Below, it crashed at ~12:04 (I checked the time on my gateway), but the only message at that time is "Stop running nchan processes"

   Dec 29 08:24:59 kernel: eth0: renamed from vethb345505

   Dec 29 08:24:59 kernel: docker0: port 6(vethba67d8e) entered blocking state

   Dec 29 08:24:59 kernel: docker0: port 6(vethba67d8e) entered forwarding state

   Dec 29 12:04:17 monitor_nchan: Stop running nchan processes

   Dec 29 14:17:36 rc.rsyslogd: Syslog server daemon... Started.

   Dec 29 14:17:36 root: Delaying execution of fix common problems scan for 10 minutes

   Dec 29 14:17:36 emhttpd: Starting services...

   Dec 29 14:17:36 emhttpd: shcmd (60): /etc/rc.d/rc.samba reload

   Dec 29 14:17:36 emhttpd: shcmd (64): /etc/rc.d/rc.avahidaemon start

4. After each reboot I see these suspicous samba and ntpd logs, but it all works fine afterwards (or so it seems; at least, I don't see any nptd errors after that anymore):

   Dec 29 08:05:55 rc.avahidaemon: Avahi mDNS/DNS-SD daemon... Started.

   Dec 29 08:05:55 rc.samba: Updating Samba server daemon...

   Dec 29 08:05:55 rc.samba: Restarting Samba server daemon...

   Dec 29 08:05:55 rc.samba: Stopping Samba server daemon...

   Dec 29 08:05:55 rc.samba: kill 2672

   Dec 29 08:05:56 avahi-daemon[20313]: Server startup complete. Host name is Melchior.local. Local service cookie is 4190834548.

   Dec 29 08:05:56 rc.samba: killall --ns 20367 smbd nmbd wsdd2 winbindd

   Dec 29 08:05:56 wsdd2[2686]: 'Terminated' signal received.

   Dec 29 08:05:56 winbindd[2690]: [2025/12/29 08:05:56.810846, 0, traceid=1] ../../source3/winbindd/winbindd_dual.c:2013(winbindd_sig_term_handler)

   Dec 29 08:05:56 winbindd[2690]: Got sig[15] terminate (is_parent=1)

   Dec 29 08:05:56 wsdd2[2686]: terminating.

   Dec 29 08:05:57 rc.samba: Samba server daemon... Stopped.

   Dec 29 08:05:57 rc.samba: Starting Samba server daemon...

   Dec 29 08:05:57 rc.samba: /usr/sbin/smbd -D

   Dec 29 08:05:57 rc.samba: /usr/sbin/wsdd2 -d -4 -6

   Dec 29 08:05:57 wsdd2[20841]: starting.

   Dec 29 08:05:57 rc.samba: /usr/sbin/winbindd -D

   Dec 29 08:05:57 rc.samba: Samba server daemon... Started.

   Dec 29 08:06:03 reload_services: execute queued job 9

   Dec 29 08:06:03 rc.ntpd: Updating NTP server daemon...

   Dec 29 08:06:03 ntpd[18873]: ntpd exiting on signal 1 (Hangup)

   Dec 29 08:06:03 ntpd[22092]: ntpd [email protected] Fri Jul 4 19:14:57 UTC 2025 (1): Starting

   Dec 29 08:06:03 ntpd[22092]: Command line: /usr/sbin/ntpd -g -u ntp:ntp

   Dec 29 08:06:03 ntpd[22092]: ----------------------------------------------------

   Dec 29 08:06:03 ntpd[22092]: ntp-4 is maintained by Network Time Foundation,

   Dec 29 08:06:03 ntpd[22092]: Inc. (NTF), a non-profit 501(c)(3) public-benefit

   Dec 29 08:06:03 ntpd[22092]: corporation. Support and training for ntp-4 are

   Dec 29 08:06:03 ntpd[22092]: available at https://www.nwtime.org/support

   Dec 29 08:06:03 ntpd[22092]: ----------------------------------------------------

   Dec 29 08:06:03 ntpd[22092]: DEBUG behavior is enabled - a violation of any diagnostic assertion will cause ntpd to abort

   Dec 29 08:06:03 ntpd[22096]: proto: precision = 0.051 usec (-24)

   Dec 29 08:06:03 ntpd[22096]: basedate set to 2025-06-22

   Dec 29 08:06:03 ntpd[22096]: gps base set to 2025-06-22 (week 2372)

   Dec 29 08:06:03 ntpd[22096]: initial drift restored to 15.108582

   Dec 29 08:06:03 ntpd[22096]: Listen normally on 0 lo 127.0.0.1:123

   Dec 29 08:06:03 ntpd[22096]: Listen normally on 1 br0 192.168.1.65:123

   Dec 29 08:06:03 ntpd[22096]: Listening on routing socket on fd #18 for interface updates

   Dec 29 08:06:03 ntpd[22096]: kernel reports TIME_ERROR: 0x41: Clock Unsynchronized

   Dec 29 08:06:03 ntpd[22096]: kernel reports TIME_ERROR: 0x41: Clock Unsynchronized

And that's it.

Things I've tried so far:

• My mobo has Realtek NIC, so I installed r8125 drivers

• Disabled C-states in BIOS

• Upgraded BIOS

• Disabled ASPM in BIOS

• Tried different SATA cables

• Tried different Ethernet cables

• Disabled TSO (Transmit Segment Offload)

• Moved cache drive from BTRFS to ZFS

• Reduced Ethernet rx/tx buffer size to 256

• Limited max number of parallel tasks in Jellyfin to 8

• Limited all docker containers to 2-8g of memory

• Tried stopping Jellyfin / qBitTorrent / AdGuard-Home etc.

• Switched from MACVLAN to IPVLAN

All docker containers use bridge network, except for AdGuard-Home (br0 with fixed IP), telegraf (host), and arrstack (uses custom "arrstack" network).

NAS has a fixed IP set on my Unifi gateway.

Hardware:

• Mobo: Gigabyte B860I AORUS PRO ICE ITX

• CPU: Intel Core Ultra 5 225 CPU

• RAM: Corsair VENGEANCE RGB 32GB DDR5 (2x16GB)

• SSD: Kingston NV3 1TB M.2 NVMe

• HDDs: Seagate IronWolf

• PSU: Thermaltake Toughpower SFX 750W ATX 3.1 PCIe 5.1 80+ Platinum Fully Modular PSU

• Switch: Unifi Cloud Gateway Fiber

• AP: Unifi U7-Pro-Wall

Software:

• Unraid 7.2.3

• No VMs

• Docker containers:

  • AdGuard-Home

  • bazarr

  • binhex-lidarr

  • binhex-prowlarr

  • binhex-radar

  • binhex-sonarr

  • flaresolverr

  • Grafana

  • Influxdb

  • Jellyfin

  • jellyseerr

  • netdata

  • qBitTorrent

  • Redis

  • SuggestArr

  • telegraf

  • UptimeKuma

  • whisparr

• Plugins:

  • Community Applications

  • Dynamix System Temperature

  • Fix Common Problems

  • GPU Statistics

  • Intel GPU TOP

  • iotop (C Version) for UNRAID

  • ITE IT87 Driver

  • Live Memory Tester for UNRAID

  • Open Files v2

  • Python 3 for UNRAID

  • RTL8125 Drivers

  • Tailscale

  • Tips and Tweaks

  • User Scripts

  • User Scripts Enhanced

melchior-diagnostics-20251229-1451.zip

Edited December 29, 2025Dec 29 by kovrik

Unfortunately, there's nothing relevant logged, this can also be a hardware issue, one thing you can try is to boot the server in safe mode with all docker containers/VMs disabled, let it run as a basic NAS for a few days, if it still crashes it's likely a hardware problem, if it doesn't start turning on the other services one by one, including the individual docker containers.

Additionally, look in the BIOS for a "Global C-States" or similar setting and disable that to retest, it's been known to be a problem with some boards, with both Intel and AMD CPUs, and if you have multiple sticks try using the server with just one, if the same try with a different one, that will basically rule out bad RAM.

@JorgeB So if it is a hardware issue, where do I start with it? I checked all the cables, tried pluggin the flash drive into a different slot, re-plugged RAM etc. Is there anything I can check that would help me identify which hardware is affected?

Re C-states, I have disabled them in BIOS, but will double-check again.

Does Unraid support different log-levels? Like, is there a way to enable DEBUG/TRACE level temporarily to get more logs?

There's no additional logging; some hardware issues just don't log anything, I would recommend doing what I mentioned above first, to rule out a bad container, for example, since those have been known to crash servers.

Regarding the hardware, and because memtest is only definitive if it finds errors, if you have multiple sticks try using the server with just one, if the same try with a different one, that will basically rule out bad RAM, After that, the other components would basically need to be swapped to test, the next suspects would be, in no particular order, the CPU, PSU or board.

Just a minor update, I disabled Docker, and it's been running for 26 hours (and counting) without any issues. So it seems that some docker containers cause the issue?

All my containers have --memory=Xg limits set. So I suppose it's either an issue with the CPU -- should I try pinning? Or they cause network interruptions somehow (what could it be?).

12 hours ago, kovrik said:

So it seems that some docker containers cause the issue?

Let it run a little more to be certain, then I would start half the container; if it issues returns, try the other half, and keep drilling down, to see if it's a specific container.

So far so good. First, I enabled all containers except qBitTorrent (cause I think that's the one causing the issue). It all ran just fine for a day, no issues.

Then, I made sure that all containers had memory limits set, plus I CPU-pinned them all: core 0 I reserved for Unraid, cores 1-2 for Jellyfin, cores 3-9 for all other containers.

Started them all, including qBitTorrent. So far no issues.

Question: is there a solution/plugin/app that would automatically kill/restart rogue Docker containers that consume too much CPU/Memory (like, if qBitTorrent has a memory leak) before they make Unraid unresponsive?

Not that I'm aware of.

I guess I am going to mark it as solved. It’s been 3 days and 20 hours without a single hiccup.

So my solution was to limit memory AND CPU-pin docker containers.

Thanks @JorgeB for your help!