Two apparently random crashes occurred several days apart after no recent changes that I can recall. I restarted the system both times without remembering to check logs. After the second crash, some docker containers failed to start after the array came back up, and the containers which were running began to behave erratically with delays and write errors. I got an error stating "unable to write to docker image" (the image is stored on my array, with appdata on a cache pool). At this point I figured it was just a transient glitch which might be resolved by a clean restart.

Following the restart, the array stuck at mounting the first disk. I'd read some posts that indicated that it might take several hours to repair an error, so I left it overnight. It was still stuck on mounting in the morning. Syslogs indicated a kernel panic (I don't remember the exact error and failed to download it), so I restarted and ran memtest86+ from the boot menu, and received consistent failures on core 14 of the CPU. I tested with a new motherboard, and got fewer errors. Swapped RAM and passed memtest with no errors.

Now, any time I attempt to start the array I consistently get kernel panic from the subject line of the post: "zfs: removing nonexistent segment from range tree." I found some other posts indicating that people encountered this on their cache pools, but mine are btfs, not zfs; the array is zfs.

I've tried removing disk 1 from the array slot and emulating the contents from parity, but it still throws the same kernel panic even if the slot is unassigned. After the panic occurs, I can't pull diags (they appear to start but never finish, and I don't see them in the logs folder) but can get syslogs. Diagnostics from a reboot with array unstarted and two syslogs (prior to reboot) attached, along with screenshot of current stopped state.

Here's what I think to be the most relevant section of the syslog leading up to the panic:

May 27 21:27:46 BOX emhttpd: Mounting disks...
May 27 21:27:46 BOX emhttpd: mounting /mnt/disk1
May 27 21:27:46 BOX emhttpd: shcmd (116): mkdir -m 0666 -p /mnt/disk1
May 27 21:27:46 BOX emhttpd: /sbin/blkid /dev/md1p1 2>&1
May 27 21:27:46 BOX emhttpd: /dev/md1p1: LABEL="disk1" UUID="15892579240466101688" UUID_SUB="12227931845957003973" BLOCK_SIZE="4096" TYPE="zfs_member"
May 27 21:27:46 BOX emhttpd: shcmd (117): /usr/sbin/zpool import -f -m -N -o autoexpand=on -d /dev/md1p1 15892579240466101688 disk1
May 27 21:27:52 BOX sysDrivers: SysDrivers Build Complete
May 27 21:27:54 BOX kernel: PANIC: zfs: removing nonexistent segment from range tree (offset=9068b4b3000 size=4000)
May 27 21:27:54 BOX kernel: Showing stack for process 6253
May 27 21:27:54 BOX kernel: CPU: 0 UID: 0 PID: 6253 Comm: z_wr_iss Tainted: P O 6.12.24-Unraid #1
May 27 21:27:54 BOX kernel: Tainted: [P]=PROPRIETARY_MODULE, [O]=OOT_MODULE
May 27 21:27:54 BOX kernel: Hardware name: Micro-Star International Co., Ltd. MS-7D54/MAG X570S TOMAHAWK MAX WIFI (MS-7D54), BIOS 1.B0 04/08/2025

I'm concerned that a hardware failure may have corrupted my array data, and I've managed to make it unrecoverable during my attempts to resolve the issue.

Apologies if this duplicates any previously-resolved issues, but I didn't see anything which resolved my current situation; any assistance would be greatly appreciated.

box-diagnostics-20250527-1418.zip box-syslog-20250528-0229.zip box-syslog-20250528-0208.zip

Stop the array, change disk1 filesystem to a different one, start the array, disk1 won't mount, don't format it, then see if mounts in read-only mode using the CLI: zpool import -o readonly=on disk1

If it works, the GUI will still show unmountable, but the data should be under /mnt/disk1, copy it to other disk(s) or a pool, then reformat the disk.

Changing the filesystem to enable the array to start seems to have been what I was missing; I'm in the process of copying files now. Thanks!