JorgeB

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.

Also, and just for competition, partition #4 always exists, even for a dedicated pool, but in those cases it will be very small, around 1MB. I believe this was done mostly for code simplification.

Alternatively, you can mount each disk with UD in read-only mode to look for it, the advantage of that is that parity would remain valid.

You can use the link above to recover the assignments; after that, you should be able to access the backup.

If it happens again, make sure you save the diags.

Older versions would not require a partition layout to exist, but since 7.2 it's required. Parity should still be 100% valid, assuming it was before, but it may be good to run a check when you can, or at least just the first couple of GBs to confirm.

Partition #1 is used for legacy (BIOS) boot, the smaller #2 is the EFI system partition.

If the containers are working fine it should be OK, but you can also recreate the Docker image to correct that.

I would change one or both to use different ports or cables, then do a new config and check "parity is already valid", then run a correcting parity check.

Sounds good, you can also keep all the assignments when doing the new config, the missing disks won't show

You need to rebuild to resolve that, see the link above.