JorgeB

You can try rebooting, but the issue will likely reoccur.
 
Yes.
 

FYI it's this issue:
 
https://forums.unraid.net/bug-reports/stable-releases/683-shfs-error-results-in-lost-mntuser-r939/
 

When the rebuild is done update the LSI firmware to latest, it's using an ancient version.

Yes, that's it.

It is, either use a different tool to copy, like for example windows explorer, or temporarily change the split level to split all.

You likely had a user script checking the btrfs pool for errors, since now it's xfs it fails.

See here:
https://forums.unraid.net/bug-reports/stable-releases/crashes-since-updating-to-v611x-for-qbittorrent-and-deluge-users-r2153/?do=getNewComment&d=2&id=2153
 
Also btrfs is detecting data corruption, so run memtest and then scrub the pool.

It's a known issue, use a different browser, or don't click the resend box, I believe that it will work if don't do that.

Start by running the new permission tool on that share only.

Both devices connected to the Marvell controller dropped offline, note that we do not recommend using them with Unraid, one of the the common issues with them is disks being dropped without a reason.

For this kind of error best bet is to backup and re-format the pool.

Unassign disk5, start array, stop array, now you can use the disk to replace disk1.

This won't work with Unraid, it requires a unique ID for all devices.

You can use midnight commander (mc on the console) then browse to /recovertemp on the left side and /mnt/disk6/share_name on the right.

Rebooting will bring them back.

Since it only happens with that Seagate model in either controller it suggests they are not liking something in the newer kernel, look for a firmware update for the drives, failing that you'll probably will need to wait for some kind of fix in a future kernel.

This sometimes happens, specially with WD drives, they are "false positives", a full disk write should get rid of them if you want.

Now stop array, unassign both cache devices, start array, stop array, re-assign both caches devices, start array, pool should mount, if yes run a balance to raid1, only after the balance finishes remove the drive you want, if it doesn't mount post new diags, but I'm about to go offline, so likely can only continue tomorrow if no one else helps before.
 
 
 
 

If it's a fresh install you should do a new config (Tools -> New config)

Not necessarily, it's been known to cause unexpected showdowns/crashes.

If USB is the only option try a different USB port/controller is available, or using a different USB bridge, some are better than others.

Press the format button next to array stop button.

Shares will need to be recreated, just copying old cfgs won't work, you can copy them after that to use the same settings, plugins I would just reinstall, for the docker containers you can copy the user-templates then install them so they will have the same settings. 

Like suspected it's showing the wrong values:
 
241 Total_LBAs_Written ------ 100 253 000 - 16039330064 242 Total_LBAs_Read ------ 100 253 000 - 33785959168  
Logical sector size is 512 bytes, total LBAs written is the raw number x the logical sector size, so total writes are currently 8.2TB, diskspeed is multiplying by the physical sector size (4096 bytes), so you need to divide by 8 to get correct values.

It's a problem with the onboard SATA controller:
Jun 24 23:08:02 QuantumBreak kernel: ahci 0000:02:00.1: Event logged [IO_PAGE_FAULT domain=0x0000 address=0x44c2b16d89f81e00 flags=0x0010] Jun 24 23:08:02 QuantumBreak kernel: ahci 0000:02:00.1: Event logged [IO_PAGE_FAULT domain=0x0000 address=0x44c2b16d89f81e80 flags=0x0010] This is quite common with Ryzen servers and there are reports that upgrading to v6.9-beta helps because of the newer kernel.