JorgeB

Unraid driver crashed, try updating to v6.10-rc2

It's a known btrfs issue, it happens when there's an odd number of devices in raid1.

Check filesystem on disk2, then you can re-sync parities.

This is the Unraid default for disks, parity partition starts on sector 2048, it means it was partitioned outside Unraid, recently Unraid started supporting that starting sector for SSDs so it doesn't complain, but because of that there are a few less sectors available, to resolve this you'd need to wipe that partition then let Unraid repartition it and re-sync parity.
 
 

Parity can't help with filesystem corruption, the rebuilt disk would look the same.
 
Filesystem corruption can be the result of for example an unclean shutdown or some hardware issue, like bad RAM, or just a bit flip in the wrong place, it's important to always have backups of anything important.

You try the below, if it doesn't help look for a BIOS update or try using different PCIe slots if possible.
 
 

LSI is on a very old firmware, try updating, you can check if the disks are being detected in the HBA BIOS during boot, CTRL + C

Macvlan call traces are usually the result of having dockers with a custom IP address, upgrading to v6.10 and switching to ipvlan might fix it (Settings -> Docker Settings -> Docker custom network type -> ipvlan (advanced view must be enable, top right)), or see below for more info.
https://forums.unraid.net/topic/70529-650-call-traces-when-assigning-ip-address-to-docker-containers/
See also here:
https://forums.unraid.net/bug-reports/stable-releases/690691-kernel-panic-due-to-netfilter-nf_nat_setup_info-docker-static-ip-macvlan-r1356/

That look like a bug, since you're not using encryption set default filesystem to xfs (Settings -> Disk Settings)

Jan 3 01:13:42 Tower kernel: macvlan_broadcast+0x10e/0x13c [macvlan] Jan 3 01:13:42 Tower kernel: macvlan_process_broadcast+0xf8/0x143 [macvlan] Macvlan call traces are usually the result of having dockers with a custom IP address, upgrading to v6.10 and switching to ipvlan might fix it (Settings -> Docker Settings -> Docker custom network type -> ipvlan (advanced view must be enable, top right)), or see below for more info.
https://forums.unraid.net/topic/70529-650-call-traces-when-assigning-ip-address-to-docker-containers/
See also here:
https://forums.unraid.net/bug-reports/stable-releases/690691-kernel-panic-due-to-netfilter-nf_nat_setup_info-docker-static-ip-macvlan-r1356/

Dec 23 13:23:14 Togetic emhttpd: unclean shutdown detected  
Some sync errors are normal after an unclean shutdown
 
 
That's normal, it's only the type of attribute.

Yes, test failed, disk should be replaced.

Start by running memtest.

Dec 31 17:38:45 Tower kernel: attempt to access beyond end of device Dec 31 17:38:45 Tower kernel: md12: rw=4096, want=7814037064, limit=7814034952 Dec 31 17:38:45 Tower kernel: XFS (md12): last sector read failed  
This suggests you used a slightly smaller 4TB disk in this position, maybe this one:
 
Model Family: Western Digital Red Device Model: WDC WD40EFRX-68WT0N0 Serial Number: WD-WCC4E1826444 User Capacity: 4,000,785,948,160 bytes [4.00 TB]  
Notice that it's slightly smaller than the other ones:
 
User Capacity: 4,000,787,030,016 bytes [4.00 TB]  
Maybe a shucked disk?

Sorry, missed that those were from the flash drive.
 
You need to increase the shutdown timeout, it's set at 90 seconds and Unraid was still in the middle of umonting the disks at that time, with the array running normally press stop and time how long it takes, add 30 seconds and set that as the new shutdown timeout, or just try setting to like 150secs or similar, should be enough.

These mean data corruption is being detected, most often due to RAM issues, in your case and since you're running a Ryzen CPU with above max spec RAM speeds that would be the main suspect, could also just be bad RAM or other hardware issue.
 
After the problem is fixed a scrub will list the corrupt the corrupt files in the syslog, those need to be deleted/replaced from backups.

According to the log there are no valid btrfs filesystems in any device, you can try this, it might work depending on how the devices were wiped:
 
btrfs-select-super -s 1 /dev/sdX1  
Do this for both devices, if the command doesn't output an error for one at least one of them reboot and post new diags.
 
 

That means it's using RAID firmware, ideally you'd crossflash to IT mode, there's a thread about that, but it's more complicated than just an update, and it can't be done inside Unraid, alternatively update it with RAID firmware to 20.00.07 and see if it helps.

Btrfs is detecting data corruption, start by running memtest.

SMART Extended Self-test Log Version: 1 (1 sectors) Num Test_Description Status Remaining LifeTime(hours) LBA_of_first_error # 1 Short offline Completed: read failure 50% 29399 2368412  
SMART test is failing, so yes, device needs to be replaced.

Sorry, missed your first reply due to an old forum bug, filesystem is crashing immediately after mounting, there are some recovery options here that you can try.

That is usually a power/connection problem, replace cables on that disk.

Best bet is to backup and reformat the pool, you can also try btrfs fsck, but only after everything is backed up.

SMB is case insensitive, you need to delete "shows" from disk2.

Check filesystem on disk6