Lefro

For those that jump straight to the comments for answers. For me, I was able to recover my WebUI through /etc/rc.d/rc.nginx reload Best of luck!

When trying to open my WebUI, it goes unresponsive/infinite load/some partial loads. When trying to get logs it is filled with kernel: Code: Unable to access opcode bytes at 0xffffffffffffffd6. nginx: 2025/05/05 19:23:04 [alert] 14315#14315: worker process 1991285 exited on signal 11 kernel: nginx[1991301]: segfault at 0 ip 0000000000000000 sp 00007ffd10cf3748 error 14 in nginx[400000+24000] likely on CPU 22 (core 38, socket 0) kernel: Code: Unable to access opcode bytes at 0xffffffffffffffd6. nginx: 2025/05/05 19:23:05 [alert] 14315#14315: worker process 1991301 exited on signal 11 kernel: nginx[1991386]: segfault at 0 ip 0000000000000000 sp 00007ffd10cf3798 error 14 in nginx[400000+24000] likely on CPU 19 (core 35, socket 0) kernel: Code: Unable to access opcode bytes at 0xffffffffffffffd6. nginx: 2025/05/05 19:23:05 [alert] 14315#14315: worker process 1991386 exited on signal 11 kernel: nginx[1991387]: segfault at 0 ip 0000000000000000 sp 00007ffd10cf3748 error 14 in nginx[400000+24000] likely on CPU 14 (core 28, socket 0) kernel: Code: Unable to access opcode bytes at 0xffffffffffffffd6. nginx: 2025/05/05 19:23:06 [alert] 14315#14315: worker process 1991387 exited on signal 11 kernel: nginx[1991458]: segfault at 0 ip 0000000000000000 sp 00007ffd10cf3798 error 14 in nginx[400000+24000] likely on CPU 20 (core 36, socket 0) kernel: Code: Unable to access opcode bytes at 0xffffffffffffffd6. nginx: 2025/05/05 19:23:06 [alert] 14315#14315: worker process 1991458 exited on signal 11 kernel: nginx[1991459]: segfault at 0 ip 0000000000000000 sp 00007ffd10cf3798 error 14 in nginx[400000+24000] likely on CPU 4 (core 8, socket 0) kernel: Code: Unable to access opcode bytes at 0xffffffffffffffd6. nginx: 2025/05/05 19:23:07 [alert] 14315#14315: worker process 1991459 exited on signal 11 nginx: 2025/05/05 19:23:07 [alert] 14315#14315: worker process 1991542 exited on signal 11 kernel: show_signal_msg: 1 callbacks suppressed kernel: nginx[1991552]: segfault at 0 ip 0000000000000000 sp 00007ffd10cf3798 error 14 in nginx[400000+24000] likely on CPU 1 (core 0, socket 0) kernel: Code: Unable to access opcode bytes at 0xffffffffffffffd6. nginx: 2025/05/05 19:23:08 [alert] 14315#14315: worker process 1991552 exited on signal 11 kernel: nginx[1991562]: segfault at 0 ip 0000000000000000 sp 00007ffd10cf3748 error 14 in nginx[400000+24000] likely on CPU 4 (core 8, socket 0) kernel: Code: Unable to access opcode bytes at 0xffffffffffffffd6. nginx: 2025/05/05 19:23:09 [alert] 14315#14315: worker process 1991562 exited on signal 11 kernel: nginx[1991631]: segfault at 0 ip 0000000000000000 sp 00007ffd10cf3798 error 14 in nginx[400000+24000] likely on CPU 18 (core 34, socket 0) kernel: Code: Unable to access opcode bytes at 0xffffffffffffffd6. nginx: 2025/05/05 19:23:09 [alert] 14315#14315: worker process 1991631 exited on signal 11 kernel: nginx[1991636]: segfault at 0 ip 0000000000000000 sp 00007ffd10cf3748 error 14 in nginx[400000+24000] likely on CPU 10 (core 20, socket 0) kernel: Code: Unable to access opcode bytes at 0xffffffffffffffd6. nginx: 2025/05/05 19:23:10 [alert] 14315#14315: worker process 1991636 exited on signal 11 kernel: nginx[1991724]: segfault at 0 ip 0000000000000000 sp 00007ffd10cf3798 error 14 in nginx[400000+24000] likely on CPU 2 (core 4, socket 0) kernel: Code: Unable to access opcode bytes at 0xffffffffffffffd6. nginx: 2025/05/05 19:23:10 [alert] 14315#14315: worker process 1991724 exited on signal 11 rc.nginx: Reloading Nginx server daemon... kernel: nginx[1991725]: segfault at 0 ip 0000000000000000 sp 00007ffd10cf3748 error 14 in nginx[400000+24000] likely on CPU 6 (core 12, socket 0) kernel: Code: Unable to access opcode bytes at 0xffffffffffffffd6. nginx: 2025/05/05 19:23:11 [alert] 14315#14315: worker process 1991725 exited on signal 11 kernel: nginx[1991801]: segfault at 0 ip 0000000000000000 sp 00007ffd10cf3798 error 14 in nginx[400000+24000] likely on CPU 22 (core 38, socket 0) kernel: Code: Unable to access opcode bytes at 0xffffffffffffffd6. I have attached diagnostics. They didn't want to download correctly (stalled with `.crdownload` extension. I checked at least syslog and it looked good). You can ignore disk sdk actively failing. I have been moving data off that dying drive the last 2 days. I was able to resolve this through going to the physical server and using the terminal entering: /etc/rc.d/rc.nginx reload And I expect it had to do with me having WebUI pages open not closing properly (seen that as a common bug). But am open to it being something else. Sharing so hopefully someone else with this can see. etemenanki-diagnostics-20250505-1937.zip

"or better yet, IMO, change to an image." I moved over to this after my image randomly got wiped and wanting to try something new because if you got burned with one thing, why do it again. If the general consensus from everyone is .img is better, why have this as a (non-experimental) option at all? Asking generally - I know moderators != developers.

I am trying to stop my array. My docker service is already stopped. And I repeatedly have this error. I have already gone through the following forum topics without luck zpool/zfs related note: Recently UNRAID completely wiped my docker.img on reboot and I decided to move to docker folders at that time (and also got some 300+ datasets under /mnt/cache marked "legacy"). I have attached diagnostics. etemenanki-diagnostics-20250503-1759.zip

Bummer, same thing just happened to me as a generic +1 Was doing a server reboot before installing a new disk and poof, docker.img reports as empty after reboot

Fair, I missed the section this was in. I just got here from trying to google how to stop mover as it was one of the top results and the kill commands worked but poorly for newer versions. If still using unraid older than V5 then ignore my comment.

The correct command to stop the mover process mover stop to avoid improperly killed processes hanging or the WebUI not reporting it stopped by trying to kill them directly.

The correct and proper command now is mover stop to avoid improperly killed processes hanging.

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