JorgeB

Kingston SA400 have a very low sustained write performance, recommend retrying with just the NVMe device for testing, though using a Mac can also bring other issues, see here for some recommendations:
https://forums.unraid.net/topic/146818-optimal-samba-settings-to-get-better-macos-to-unraid-performance/?do=getNewComment
 
Also recommend that you make the pool an exclusive share, or use the disk share to test.

You formatted the device with UD, hence the warning, UD uses a different option to maintain compatibility if a user formats a pool with v6.13-beta and wants to go back to 6.12, you could have formatted using Unraid, and that would not have happened.
 
P.S. you also need to see what's going on with disk3:
 
May 24 04:22:44 HomeServer emhttpd:   pool: disk3 May 24 04:22:44 HomeServer emhttpd:  state: ONLINE May 24 04:22:44 HomeServer emhttpd: status: One or more devices has experienced an error resulting in data May 24 04:22:44 HomeServer emhttpd: #011corruption.  Applications may be affected. May 24 04:22:44 HomeServer emhttpd: action: Restore the file in question if possible.  Otherwise restore the May 24 04:22:44 HomeServer emhttpd: #011entire pool from backup.  
Having two pools with data corruption, since the cache pool also had some before the format, suggests a hardware issue, like bad RAM
 
 

Unraid always uses the sdX identifiers, since the pool devices are assigned, there's no issue if those change, it will use the new ones.

Btrfs is detecting data corruption in both NVMe devices, that's usually a RAM issue, same for "write time tree block corruption" errors, also note that Ryzen with overclocked RAM like you have is known to corrupt data, so would recommend correcting that, then scrub the pool and if there aren't any uncorrectable errors and reset the pool stats and keep monitoring for more.

Googling Avocent and iDRAC found this:
 
https://gist.github.com/xbb/4fd651c2493ad9284dbcb827dc8886d6
 

 
Pretty sure that's it.
 
 

You need to decrypt the device first, if you do that with the array stated, it will show unmountable, but it should be decrypted.

You can just stop the array, unassign the SATA SSD, and start the array to remove it, need to check the "I want to do this" box.

The syslog in the diags starts over after every boot, you can enable the syslog server and post that if it happens again.

Try recreating the docker image, then check to see if macvlan is still being used:
 
https://docs.unraid.net/unraid-os/manual/docker-management/#re-create-the-docker-image-file
Also see below if you have any custom docker networks:
https://docs.unraid.net/unraid-os/manual/docker-management/#docker-custom-networks

It's possible with pools, only not possible with array disks.

It's logged as a disk error, and SMART is showing some issues, since the extended test passed the disk is OK for now, but most likely you will get more read errors in the near future, and if that happens I would recommend replacing it.

Yes, that's the only option, and SMART looks OK.
 
 

That will happen if writing to multiple disks at the same time, Unraid will disable Turbo write anytime there are writes to more than one array disk.

Everything except docker and VMs should remain working.

Yep, or disable bridging for eth0, containers should keep working as they are.
 
 

Apr 20 17:00:29 Chantry-Server nginx: 2023/04/20 17:00:29 [error] 3815#3815: *99406 limiting requests, excess: 20.142 by zone "authlimit", client: 10.0.0.76, server: , request: "PROPFIND /login HTTP/1.1", host: "chantry-server"  
This looks like the main culprit and it's coming from client: 10.0.0.76
 
 

There was a user having a similar issue that fixed it by 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 please 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.

These suggest a hardware problem.

As long as there are no reasons to suspect parity was invalid before the check, it should still be, so just do a standard replacement, keep the old disk intact for now in case it's needed.

Dashboard page:
 

No shutdown started on those, try doing a shutdown now and see if new diags are created, also watch the monitor and take a photo of where it gests stuck.

Looks OK to me, compress may not help a lot, depending on the data, and if you are using large blocks use -L

See here for how to replace the flash drive:
https://docs.unraid.net/unraid-os/manual/changing-the-flash-device/
 
If you cannot copy the /config from the old one and need help with the device assignments see the end of that page.

Check filesystem on disk11, run it without -n, then reboot to clear the logs and post new diags during a parity check.

Apr 30 19:46:35 Arkham kernel: macvlan_broadcast+0x10a/0x150 [macvlan] Apr 30 19:46:35 Arkham kernel: macvlan_process_broadcast+0xbc/0x12f [macvlan]  
Macvlan call traces will usually end up crashing the server, switching to ipvlan should fix it (Settings -> Docker Settings -> Docker custom network type -> ipvlan (advanced view must be enabled, top right)), then reboot.