sylinen

Further investigating, memtest86 shows memory errors. However, my config is 2 sticks of 16GB DDR4 ECC. Both sticks showed errors in memtest86, both individually and in pairs, and in all slots, which makes me think the memory isn't actually the problem. The odds of 2 sticks failing simultaneously seem very small to me. I've ordered a new stick of ECC DDR4 to try, but I'm starting to think this is a CPU or motherboard issue.

Some other things I've noticed in testing: SSH connections are being refused, and the following code block shows up in the log around the same time as I lose connection to the server: Jan 14 22:14:46 Tower kernel: veth1cd4618: renamed from eth0 Jan 14 22:14:46 Tower kernel: docker0: port 2(veth6436d01) entered disabled state Jan 14 22:14:47 Tower kernel: docker0: port 2(veth6436d01) entered disabled state Jan 14 22:14:47 Tower kernel: device veth6436d01 left promiscuous mode Jan 14 22:14:47 Tower kernel: docker0: port 2(veth6436d01) entered disabled state Jan 14 22:15:01 Tower kernel: docker0: port 2(veth6c69648) entered blocking state Jan 14 22:15:01 Tower kernel: docker0: port 2(veth6c69648) entered disabled state Jan 14 22:15:01 Tower kernel: device veth6c69648 entered promiscuous mode Jan 14 22:15:01 Tower kernel: docker0: port 2(veth6c69648) entered blocking state Jan 14 22:15:01 Tower kernel: docker0: port 2(veth6c69648) entered forwarding state Jan 14 22:15:01 Tower kernel: docker0: port 2(veth6c69648) entered disabled state Jan 14 22:15:15 Tower kernel: eth0: renamed from veth29ff5eb Jan 14 22:15:15 Tower kernel: IPv6: ADDRCONF(NETDEV_CHANGE): veth6c69648: link becomes ready Jan 14 22:15:15 Tower kernel: docker0: port 2(veth6c69648) entered blocking state Jan 14 22:15:15 Tower kernel: docker0: port 2(veth6c69648) entered forwarding state

I think in the log I posted the most recent occurrence was in the last 10 minutes. The only log entry that I don't ever recall seeing before this problem happened is "Tower monitor: Stop running nchan processes".

Those containers being out-of-date existed before the problem occurred. I updated the containers anyway, no change.

Having some weird networking behavior on Unraid 6.12.6. I'm periodically losing access to the management GUI and SMB shares on my server. The loss of access seems to be for 30 seconds to 3 minutes in duration. Curiously, the Docker containers I have running remain accessible during these outages (both those using custom IP and bridging) and I can still ping the server's IP. I've done the usual reboots, tried disabling bonding, tried only having one NIC connected, tried a BIOS update. Other devices I have that are connected to the same network are not having similar issues. tower-diagnostics-20240113-1351.zip

Yes, I know, which I why I chose SMB in the drop down when I tried to mount the drive. So, is SMB broken in UD right now? EDIT: got it to work. Unraid or UD didn't like using the hostname, so I tried using the IP address. That got it to mount. Should've tried that earlier.

But it isn't. I can mount it as a network drive on other Windows machines on my network.

Trying to add a remote SMB share from my Windows desktop. UD finds the share just fine, and it shows up in the UD section on the main Unraid screen, but I can't mount the share. The mount button is grayed out. I don't think it's a security problem, as I've tried all the permutations of security settings in UD settings. tower-diagnostics-20180930-1452.zip