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

2 VMs, an Ubuntu server for pihole and one general purpose Manjaro VM. Haven't tried disabling them. I'm running the official Plex Inc. docker if that matters. Ryzen 1700X for CPU.

I've had a similar issue, and it usually triggers for me also at around 6 days. The crash usually coincides with fast-forwarding or rewinding in Plex.

My binhex-rtorrentvpn container had an error of some kind during an update, and became un-deletable. Created new container to get around the error, different name, no biggie. But the old container still can't be deleted. It doesn't show up when I run "docker images" in the terminal, but I can run "docker inspect" on the container ID given in the Unraid gui. Running "docker rm" on the container ID returns the following error: docker rm 7609238e662c Error response from daemon: container 7609238e662c9c068960494cd69752316ca56c33b968007e77fd357945593d0a: driver "btrfs" failed to remove root filesystem: Recursively walking subvolumes for /var/lib/docker/btrfs/subvolumes failed: error walking subvolumes: lstat /var/lib/docker/btrfs/subvolumes/aa4b5954e6d2c96970f5ce6ab5071d659f8f99cfddc6de6f670b1d4f58ca8eca/usr/share/webapps/rutorrent/plugins/retrackers/lang/es.js: input/output error And the system log shows the following error when I run the "docker rm" command: Feb 13 01:27:08 Tower kernel: BTRFS error (device loop2): bad tree block start 0 347701248 Feb 13 01:27:08 Tower kernel: BTRFS error (device loop2): bad tree block start 0 347701248 I suspected a problem with my cache pool, but scrubbing the cache showed no errors. Any other way to delete the bad container?

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

Same kind of issue happening for me. Haven't messed with DNS at all, but I can't even ping docker.io. Every other URL pings just fine, but none of the Docker addresses will return packets. Haven't been able to update Docker containers since 6.5.2 update.