tower-diagnostics-20260926-1140.zip

Hi all, with 20+ tabs currently open trying to find the best way through this and still being pretty green on troubleshooting, figured I'd ask for some help if anyone has time...

Bit of background:

1. Docker services not initializing

2. Delete and reinstall docker vdisk, no help

3. Scrub cache drive, unfixable errors

4. Attempt to stop array, stuck on "Attempting..."

5. Killed as many processes as I could, and unmount drives through CLI, no joy

6. powerdown -r

7. ran 2 x memtest, passed, no errors, still currently running (2x16GB, DDR4)

My question is; I know I'm going to get a parity check on reboot, and I'm assuming the same problem will happen when I try to stop the array again. Is there a best practice to start up and reformat the cache drive (assuming that's what's next)?

Attached the last diagnostics I took before attempting to stop if it's helpful. The drive in question is the EDILOCA.

Thanks again for reading.

Ben

I don't think the cache is the reason Docker won't start, and you may not need to reformat it.

Every time Docker starts, the syslog shows this:

SQUASHFS error: xz decompression failed, data probably corrupt

SQUASHFS error: Failed to read block 0x2db5b84: -5

Right after that, the Docker daemon crashes with a bus error. Unraid runs from files on the flash drive, and part of the OS (the bzfirmware file) can't be read. The Docker program itself is in the part that fails. The same block also failed in your previous boot, so recreating the docker image couldn't fix it.

Fix the flash first:

1. Back up the flash drive: click the flash device on the Main page, then Flash Backup.

2. Recreate the flash drive with the USB tool, then restore only the config folder from the backup.

3. If the SQUASHFS errors come back after that, replace the flash drive.

Cache pool: The scrub errors are real. The pool has checksum errors on file data from before this problem, but they affect only some files, not the filesystem structure, so a reformat is not required:

1. After the flash is fixed, run a scrub on the pool. Then check the syslog: each unfixable error lists the path of the affected file.

2. Delete those files, and restore them from a backup if you have one.

3. Reset the error counters with btrfs dev stats -z /mnt/cache_nvme, then run another scrub. It should finish with no errors.

Also note that the pool is about 85% full, and the appdata/system shares have a 50 GB minimum free space setting. The log already shows share cache full errors for appdata files. Free some space on that pool or lower the minimum free space setting.

Parity check is normal after an unclean shutdown. You can let it run, or cancel it and run a correcting check later.

The array stop probably hung because of the broken OS files. If it happens again after the flash is fixed, get new diagnostics before you reboot.

Awesome thanks for the insight Jorge. I will get to work on that asap and report back.

@JorgeB That did it, flash drive fixed and cache cleaned up, rescrubbed with no errors and sitting at 65% used.

Thanks again for the help, saved me a lot of time chasing ghosts. 🍻