JorgeB

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.

Yep

That should work.

Jun 14 13:35:33 floresNAS-N40L kernel: sd 4:3:0:0: [sdi] tag#0 timing out command, waited 60s Jun 14 15:34:36 floresNAS-N40L kernel: sd 4:1:0:0: [sdg] tag#22 timing out command, waited 60s Jun 15 00:15:04 floresNAS-N40L kernel: sd 4:3:0:0: [sdi] tag#5 timing out command, waited 60s There are errors with multiple disks Check/replace cables for both, then try again.

Post new diags with the disks assigned for the parity swap.

Delete /boot/config/pools/cache.cfg on the flash drive, reboot and the GUI should be back, you will need to reimport the pool, can post the steps for that if you need them.

You can get the boot device from the syslog; though probably there's a better place, but I don't know.

I assume that is the cache pool, so unrelated to the rebuild, but post new diagnostics.

My only thought is some config issue creating problems, this assuming multiple clients still cannot login. You can 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.

cat /var/local/emhttp/var.ini | grep GUID It will show one or both, if availble, and also which one is being used. As for the boot device, not sure how to get that from a file. One possible way would be to check the boot device partitions; if there are 4, it's internal boot.

After a new config, yes.

Yes, and you would need to at least leave one of them connected; if you removed both, the vdev would be unavailable (meaning the whole pool could not be imported) Correct, it's only about the assignments, and if you do that in the order mentioned, it will avoid you having to reassign the remaining pool devices, which would be a pain with so many.

What if you make a share public? Also make sure to delete the credentials from Credential Manager in Windows (and the equivalent on Mac)

Licenses can only be TPM or flash drive-based, not internal boot One easy way to tell is if they start with 01- they are TPM based, if they start with 4 characters (XXXX-) they are tied to a flash drive

I think part or most of the performance issues may be related to just how big the pool is, and it's not something I have experience with or can test. This may be worth a shot; I'm not sure if the removal performance will also be affected by the pool size, but I would test with one first to see. It will better redistribute the data to the empty vdevs, and then adding one or more new mirrored vdevs is basically instantaneous. Just keep in mind that the GUI doesn't support removing a vdev, but you can do it using the CLI, e.g.: zpool remove space mirror-30 Once one or more mirrors have been removed, you need to reimport the pool. stop the array unassign the devices for the removed mirror(s) Tools - New config - Preserve all assignments - Apply start the array to reimport the pool

Not really, but if that works, it means SMB is not totally broke. Try removing the following files from the flash drive config folder: "passwd", "secrets.tdb", "shadow", "smbpasswd", you can move them somewhere else instead of deleting them just in case, after that, reboot the server and retest, also note that you will need to recreate the users if you have some, but you should only need to set the name and password, the permissions on the shares should be retained in the shares config files.