Lefro

Ever since updating to 6.12, for months now, I've had an issue every 5-50 days at random intervals where Unraid itself will lose all network access, but all the dockers are fine. This is the first solution that worked for me other than fully restarting the server, thank you.

Here is the current official guidance on how to shrink your array: https://docs.unraid.net/legacy/FAQ/shrink-array/ Our Current Scenario: There are 2 options when it comes to removing drives, and both are very involved with multiple (9 or 17 steps + 5 subnotes) steps and involves updating your disk configuration list manually which risks data loss if the user mistakenly swaps a data disk as parity, or puts a pool drive in the wrong slot. Additionally, this FORCES the user to start the array with it warning them if they messed up, they risk data loss (without knowing necessarily if they messed up before the array starts). Request: I would want a simple "disk removal" button in the instance there are 0 reachable files on the disk (no shares data). I, as a user, can manually move all my files off of the disk to be removed, and once complete, I can stop the array and remove the disk via. the GUI. As simple as: Move all files from the disk you wish to remove to other disks in the array Once all files are removed, and looking at the disk content shows 0 files or shares, stop the array Click the "remove disk" button next to the disk in the array" Start the array Where the user does not have to be concerned with disk configurations or risking assigning a disk incorrectly resulting in data loss. Request (Stretch Goal) I, as an UNRAID user, would want the ability to mark a disk from the array as "to be removed", where UNRAID will automatically move files off of that disk. Once there are 0 files remaining on the disk, UNRAID would (Option 1): Automatically remove the disk and populate it as an unassigned device while the array is still running (Option 2): When the array is shut down, check the contents of the marked disk and if there are 0 share files, move it to an unassigned device. (Unsure on backend technical limitations for removing a disk from the array while in a non-stopped state or checking the folder structure of a disk while in a stopped state). ------------------------------------------------- (In case the link updates, current instructions on how to clear array): 1. The "Remove Drives Then Rebuild Parity" Method 2. The "Clear Drive Then Remove Drive" Method

After installing NIC and disabling the ethernet port on my motherboard the issue was resolved. Was a pure hardware problem it seems

After more testing I have gone to the conclusion of hardware problem, which seeing as I got all my hardware outdated and used makes sense. Using a USB dongle for Ethernet seems to have resolved the issue (though added the new one of the ip address changing). Ordered a NIC for a permanent solution

While now the ping is stable (consistently 1 ms and not jumping arund nearly as much), there is still the occasional drop out for 10+ seconds like 4/24/2023 7:18:18 PM - Request timed out. 4/24/2023 7:18:20 PM - Reply from 192.168.0.139: Destination host unreachable. 4/24/2023 7:18:24 PM - Request timed out. 4/24/2023 7:18:29 PM - Request timed out. 4/24/2023 7:18:32 PM - Reply from 192.168.0.139: Destination host unreachable. 4/24/2023 7:18:35 PM - Reply from 192.168.0.139: Destination host unreachable. 4/24/2023 7:18:39 PM - Request timed out. 4/24/2023 7:18:41 PM - Reply from 192.168.0.139: Destination host unreachable. 4/24/2023 7:18:45 PM - Request timed out. 4/24/2023 7:18:50 PM - Request timed out. 4/24/2023 7:18:55 PM - Request timed out. 4/24/2023 7:19:00 PM - Request timed out. 4/24/2023 7:19:05 PM - Request timed out. 4/24/2023 7:19:10 PM - Request timed out. 4/24/2023 7:19:15 PM - Request timed out. 4/24/2023 7:19:20 PM - Request timed out. 4/24/2023 7:19:22 PM - Reply from 192.168.0.139: Destination host unreachable. 4/24/2023 7:19:26 PM - Request timed out. 4/24/2023 7:19:31 PM - Request timed out. 4/24/2023 7:19:36 PM - Request timed out. 4/24/2023 7:19:38 PM - Reply from 192.168.0.183: bytes=32 time=1000ms TTL=64 4/24/2023 7:19:38 PM - Reply from 192.168.0.183: bytes=32 time<1ms TTL=64 4/24/2023 7:19:43 PM - Request timed out. 4/24/2023 7:19:44 PM - Reply from 192.168.0.183: bytes=32 time<1ms TTL=64 4/24/2023 7:19:49 PM - Request timed out. 4/24/2023 7:19:54 PM - Request timed out. 4/24/2023 7:19:55 PM - Reply from 192.168.0.183: bytes=32 time<1ms TTL=64 4/24/2023 7:19:56 PM - Reply from 192.168.0.183: bytes=32 time<1ms TTL=64 4/24/2023 7:19:57 PM - Reply from 192.168.0.183: bytes=32 time<1ms TTL=64 4/24/2023 7:19:58 PM - Reply from 192.168.0.183: bytes=32 time<1ms TTL=64 4/24/2023 7:19:59 PM - Reply from 192.168.0.183: bytes=32 time<1ms TTL=64 4/24/2023 7:20:00 PM - Reply from 192.168.0.183: bytes=32 time<1ms TTL=64 4/24/2023 7:20:05 PM - Request timed out. 4/24/2023 7:20:10 PM - Request timed out. 4/24/2023 7:20:15 PM - Request timed out. 4/24/2023 7:20:20 PM - Request timed out.

From debugging: The problem relates to my use of the shinobi-pro-cctv docker container I can't explain why, but the second I stop this container all network issues stop as well. The container was mapped to a 4 tb unassigned drive. Leaving this up in case there's any people looking that see it but will start trying to investigate why shinobi causes this issue and if I should go to an alternative security camera hosting container.

I started hosting a game server for some friends when part way through we realized that the server would randomly time out and kick us off. When running a `ping server -t` command from my Windows computer, the output looks like: Reply from 192.168.0.183: bytes=32 time<1ms TTL=64 Reply from 192.168.0.183: bytes=32 time=9ms TTL=64 Reply from 192.168.0.183: bytes=32 time<1ms TTL=64 Request timed out. Reply from 192.168.0.183: bytes=32 time=13ms TTL=64 Reply from 192.168.0.183: bytes=32 time=30ms TTL=64 Reply from 192.168.0.183: bytes=32 time<1ms TTL=64 Request timed out. Reply from 192.168.0.183: bytes=32 time=9ms TTL=64 Reply from 192.168.0.183: bytes=32 time=23ms TTL=64 Reply from 192.168.0.183: bytes=32 time<1ms TTL=64 Request timed out. Reply from 192.168.0.183: bytes=32 time=3ms TTL=64 Reply from 192.168.0.183: bytes=32 time=23ms TTL=64 Reply from 192.168.0.183: bytes=32 time=1ms TTL=64 Reply from 192.168.0.183: bytes=32 time=23ms TTL=64 Reply from 192.168.0.183: bytes=32 time<1ms TTL=64 Request timed out. Reply from 192.168.0.183: bytes=32 time<1ms TTL=64 Reply from 192.168.0.183: bytes=32 time=21ms TTL=64 Reply from 192.168.0.183: bytes=32 time<1ms TTL=64 Reply from 192.168.0.183: bytes=32 time=17ms TTL=64 Reply from 192.168.0.183: bytes=32 time<1ms TTL=64 Request timed out. Eventually it would end up looking like: Ping statistics for 192.168.0.183: Packets: Sent = 5584, Received = 5369, Lost = 215 (3% loss), Approximate round trip times in milli-seconds: Minimum = 0ms, Maximum = 55ms, Average = 15ms With a mix of single time outs and clustered time outs (but still, there should be 0) However when I run the same command pinging from my Windows computer to my rapsberry Pi on the same network switch, not a single packet is lost over 1,000+ pings. I have attached my server logs and an overnight ping command run from my raspberry Pi -> my server (ping_output.txt) to show 1. The issue persists outside of the client making the call 2. Just to show that the time outs are documentable. It seems to show less than on my Windows but you can see multiple 10+ second gaps from ping 1 to ping 2 before it could get a response This server is using older hardware, an Intel® Core™ i7-4770K on a Gigabyte Technology Co., Ltd. Z87MX-D3H-CF motherboard. Right now my gut feeling is there is something wrong with the onboard Ethernet for the Motherboard. I tried the obvious solutions like swapping around cables and the ports it used on the switch. The next items I was going to look at would be if I need to update BIOS, if I need ot update the Ethernet chipset in any way, or if buying a NIC could potentially resolve this issue. I'd appreciate any help in troubleshooting. etemenanki-diagnostics-20230424-1358.zip ping_output.txt