JorgeB

Disk dropped offline, this is usually a power/connection problem, replace cables or swap with a different disk.

You can have UD run a script when the remote share is mounted, or install the user scripts plugin and have that run on a schedule.

Parity is not valid, and you can't replace parity and a data disk at the same time.

You must set the minimum free space for the share, it should be set to twice the largest file you expect to transfer, or when cache is full (and later arrays disk) it will fail.

Are you using the default ARC size? The problem is usually not just about not enough RAM but more about fragmented RAM, a small swap file on disk might help, you can use the swapfile plugin:
 
https://forums.unraid.net/topic/109342-plugin-swapfile-for-691/
 

The reply above already mentions your best bet, if xfs_repair cannot fix the filesystem basically the only option, and assuming there are no backups, is to use a file recovery util, like UFS explorer.

That will happen if something is using them, e.g., a terminal windows opened on a mounted path.

If you don't have a backup you follow this:
 
https://wiki.unraid.net/Manual/Changing_The_Flash_Device#What_to_do_if_you_have_no_backup_and_do_not_know_your_disk_assignments:

Disk2 was already assigned at boot, but assuming the data is all on disk2 you can do a new config to get rid of the disabled disk1.

Looks more like a power/connection problem, since there are some UDMA CRC errors replace the SATA cable and assuming the emulated disk is mounting and contents look correct you can rebuild on top.
 
https://wiki.unraid.net/Manual/Storage_Management#Rebuilding_a_drive_onto_itself
 
 

Formatted with type 2 protection 8 bytes of protection information per logical block  
You need to remove this:
 
https://forums.unraid.net/topic/93432-parity-disk-read-errors/?do=findComment&comment=864078

https://forums.unraid.net/topic/110835-help-with-a-sas-drive/

Run xfs_repair again without -n, and if it asks for -L use it.

Aah, the NICs use the same driver so didn't notice one was the onboard, remove the DHCP configuration from eth1, since it's together with eth2 it might than allow you to pass-through both.

https://forums.unraid.net/bug-reports/stable-releases/6103-samsung-980-temp-warning-r2007/?do=findComment&comment=20180
 

Mar 13 10:04:37 Tower init: Switching to runlevel: 0 Mar 13 10:04:37 Tower init: Trying to re-exec init Mar 13 10:04:49 Tower Parity Check Tuning: Send notification: Array stopping: Restart will be attempted on next array start: Automatic Correcting Parity-Check (79.3% completed) (79.3% completed) Mar 13 10:06:39 Tower root: Status of all loop devices  
Still not enough, did you stop the parity check? You can also time how long it takes for the array to stop after you click the stop button.

Parity doesn't know about the data, only bits, it doesn't matter if the disk is empty or completely full, it will take the same time to replace.
 
https://wiki.unraid.net/Parity#How_parity_works

Flash drive dropped offline, make sure it's using a USB 2.0 port and reboot, if it doesn't come back online or if it drops again best to replace it.

There are what look like power/connection issues with that disk, check/replace cables.

Yes, by default ARC is configured to use 1/8 of installed RAM, but that can be changed, see release notes.

Unraid doesn't move array data on its own, you'd need to do it manually or using for example the unbalance plugin.

Try posting in the existing plugin support thread:
 
 

Start here:
 
https://forums.unraid.net/topic/46802-faq-for-unraid-v6/?do=findComment&comment=819173
 

Under normal circumstances the 2nd option would be easier, unless something goes wrong during the balance, so always good to make sure backups are up to date before starting, then add the NVMe device to the cache pool, wait for the balance to finish, it will finish when the cache activity stops and you can stop the array, stop array, unassign the 840 EVO SSD, start array, a new balance will start to delete the old device, once that finishes you are done.

Run the same command again, but if it's recurring best to then backup and re-format the pool, also see here for better pool monitoring, if new corruptions are found you have other issues, like a RAM problem.

Problem with the onboard SATA controller, this used to be be fairly common with Ryzen boards and v6.9/v6.10, much less common with v6.11, possibly because of the newer kernel, look for a BIOS update and/or try v6.12-rc2, failing that best bet would be to use an add-on controller instead.