JorgeB

I forgot to mention, once you can, I would recommend resyncing parity with the default partition layout, so that you don't get stuck if a disk actually fails. There would still be some options to recover but would be more complicated, like copying/moving the data from the emulated disk first. To make sure the default layout is used, you could do this: stop array unassign parity start array stop array type wipefs -a /dev/sdX (replace X with the correct parity disk identifier) re-assign parity start array to begin parity sync The data disks would still remain using 1 MiB alignment partitions, but as long as parity is 4 KiB aligned, that should no longer be a problem, even with the 4Kn parity; at least it's not according to my tests.

Check/replace cables for disk1, then run another correcting check and post new diags

You can use this https://forums.unraid.net/topic/198440-73xx-version-moving-boot-drive-nvmessd-to-another-drive-nvmessd/#findComment-1619744

I don't see a cause for the problem; in safe model plugins, it should not make any difference, but maybe there's a config problem somewhere, my suggestion would be to first upgrade to 7.3.1, if the issues persists there, try redoing the flash drive, backup the current one first and then recreate it using the USB tool and just restore the bare minimum, like the key, super.dat and the pools folder for the assignments, also copy the docker user templates folder (\config\plugins\dockerMan\templates-user), if all works you can then reconfigure the server or try restoring a few config files at a time from the backup to see if you can find the culprit.

btrfs is detecting data corruption; start by running memtest.

Yep, nothing else logged, I'm afraid there may be an issue with the pool, a device, or it's hitting some btrfs raid5 bug. My recommendation would be to back up and recreate the pool, and if you still want raid5, use zfs raidz i nstead, btrfs raid5/6 is still considered experimental.

It can be that one.

You can use this: https://forums.unraid.net/topic/198440-73xx-version-moving-boot-drive-nvmessd-to-another-drive-nvmessd/#findComment-1619744

Check to see if their templates exist on the flash drive (\config\plugins\dockerMan\templates-user)

That, to me confirms the upgrade wasn't the issue, if multiple clients are still failing to access the shares, I suspect a config problem.

See if this shows anything more: dmesg | grep -i btrfs | tail -n 10 Also post the output from btrfs device stats /mnt/cache

The error suggests an i/o error with one of the remaining pool devices, but I don't see anything logged. If you try the command again, does it show the same error?

Jun 16 13:41:34 Unraid kernel: mt7925e 0000:03:00.0: Message 00020016 (seq 9) timeout Jun 16 13:41:34 Unraid kernel: mt7925e 0000:03:00.0: HW/SW Version: 0x8a108a10, Build Time: 20260414153001a Jun 16 13:41:34 Unraid kernel: Jun 16 13:41:34 Unraid kernel: mt7925e 0000:03:00.0: WM Firmware Version: ____000000, Build Time: 20260414153105 Jun 16 13:41:35 Unraid dhcpcd[2634]: wlan0: carrier lost Same issue as before, possibly a hardware or firmware issue

Hmm, will need to do some testing, but it looks like there's also a bug with the parity swap, and not only because of the 4Kn disk, but there's another one because of that , so possibly two separate but related bugs. Since this may take some time for LT to fix, my recommendation would be to re-enable the disk (assuming that disk is still intact). If you copied any data to disk1 after it got disabled you will need to copy that first, then do a new config, reassign all the disks to their original slots, if you haven't been using the array with the disabled disk, parity should be mostly valid, so you can use it and then just run a correcting check Tools -> New Config -> Preserve current assignments: All -> Apply Raising disk1 and parity as they were origianlly Check "parity is already valid" if that is the case Start the array Run a correcting check.

It does not, boot in safe mode and start a new check from the GUI, if that still fails, please post new diags.

hmm, post new diags or just the syslog after running that command

Try upgrading again and post the diagnostics after that (before rebooting)

It is also odd to me, but I think it may be related to having pool activity with such a large pool, try to avoid new reads and writes as much as possible, and it should again continue the resilvering. At least I don't see anything that would suggest a slow disk or disks, downgrading the resilver speed.

Since the device is already missing, the esay way is to remove it using the CLI, then reimport the pool with the 4 remianig devices: With the array started type btrfs device remove missing /mnt/cache Once that's done, stop the array and reimport the pool on main click on the first device for that pool and then "remove pool" back on main, create a new pool with the same name and 4 slots now assign the 4 current pool devices, leave the filesystem set to auto start the array to import the pool

Pool was imported degraded; I assume you still want to remove that device?

The problem is that since the pool is encrypted, you will need to decrypt it first to see the current status. You can do this; it won't damage the pool if it's cannot import it: add a new pool with the same name and 5 slots Assign the 5 devices, leave the filesystem set to auto start the array and post new diags

It's typically (and by default) saved on a pool, but if that is the Docker image, not the cache filesystem, you can just recreate it: https://docs.unraid.net/unraid-os/troubleshooting/common-issues/docker-troubleshooting/#re-creating-the-docker-image-file Then: https://docs.unraid.net/unraid-os/troubleshooting/common-issues/docker-troubleshooting/#reinstalling-docker-applications Also see below if you have any custom docker networks: https://docs.unraid.net/unraid-os/troubleshooting/common-issues/docker-troubleshooting/#restoring-docker-custom-networks

Not really, haven't seen anyone else with similar issues, and assuming you upgraded from 7.2.x, Samba is the same version, so there shouldn't be any issues. That procedure is quite simple to do, at least the initial part to confirm if it's a config problem, you can also downgrade to the previous release to confirm if the upodate is reallythe problem.

You should never use those, a SATA plug should never be split into more than two max.

Btrfs user-space utility ran out of RAM and crashed, reboot and post new diags after array start.