itimpi

The behaviour you describe sounds correct for the way that you have your system is currently set up.   You are trying to overload your pool capabilities.
 
A point to remember is that Minimum Free Space does NOT mean keep that amount of space free.   It is a value that when it drops below that the NEXT file to be created is sent to a different drive.   The current file will continue until it is complete which can take the free space well below the setting value..   That is why you want that setting to be larger than the biggest file you want to transfer.   Mover will not automatically move files off to get to the Minimum Free Space value.
 
It does not make sense to have Use Cache=Prefer for shares which total more than the available space.   You should either restrict this setting to those shares you really want on the pool and that will fit, or alternatively you can increase the size of the pool, or create additional pools.   Many people will have separate pools for caching, docker apps, VMs etc with each one using hardware and settings optimised for that type of use although there is nothings stopping you combining these functions onto a single pool.

This is covered here in the online documentation accessible via the ‘Manual’ link at the bottom of the GUI or the DOCS link at the top of each forum page.

You cannot copy data to the drive outside Unraid without invalidating parity.   However as long as the drive was formatted by Unraid then you can copy data to it outside Unraid as long as you later use the New Config tool to reintroduce the drive and then rebuild parity.
 
if you say there may have been some confusion at the ‘Unraid level about what file system was on the drive then there are a couple of thing I would suggest trying:
Stop the array. unassign the drive (if it is currently assigned) click on the emulated drive and explicitly set it to be XFS rather than Auto start the array to see if any data is now visible. The other thing to try while the drive is not in the array is to see if it can be mounted in the server using the Unassigned Devices plugin.   If it can then you could do any copying locally within the server.    You could either speed up the copying by removing the parity drive until copying finished, or (safer) keep the parity drive assigned and live with the slower copying to keep protected against any other drive having problems.

Those diagnostics are full of read errors on disk2 and since there is no SMART report for that drive it has probably dropped offline.

If you are moving lots of small files (as if often the case for the appdata share)  then mover will be slow as there is a significant overhead per file for checks that mover does before it moves a file.  It can be faster to use something like Dynamix File Manager to move the shares from the cache to a specific disk,

Unassigning the drive would have exactly the same effect as physically removing it.  In both cases the drive will be emulated using the other drives plus parity.
 

The User Scripts allows you to run scripts at array stop/start/first start so you can easily make a custom script.
 
if you want to send a notification you can use the /usr/local/emhttp/webGui/scripts/notify command.   If you want to simply write to the syslog then you can call the ‘logger’ command.  Run either of these from a command line with —help to get the options supported.

Looking at the syslog in those diagnostics I see this:
Jun 17 22:18:50 T2 emhttpd: shcmd (2956): /usr/local/sbin/mover &> /dev/null & Jun 17 22:18:50 T2 kernel: shfs[29898]: segfault at 0 ip 000055d7967cb59c sp 0000151246774810 error 4 in shfs[55d7967c9000+c000] Jun 17 22:18:50 T2 kernel: Code: 48 8b 45 f0 c9 c3 55 48 89 e5 48 83 ec 20 48 89 7d e8 48 89 75 e0 c7 45 fc 00 00 00 00 8b 45 fc 48 63 d0 48 8b 45 e0 48 01 d0 <0f> b6 00 3c 2f 74 4d 8b 05 67 dd 00 00 85 c0 78 39 e8 9e da ff ff which indicates that the shfs process used to support User Shares immediately crashed when mover started - no idea why.
 
The good news is that restarting the server will get all your shares back as they were.
 
You could manually move the files from the drive on the array on to the pool to bypass mover if needed.

Have you checked for a folder called ‘appdata’ even if it is empty?   If it is empty then you can simply delete it.

Parity drives have no file system, and also do not need pre-clearing (except perhaps as a stress test) as building parity overwrites every sector on the drive.

The check/repair process refers to unmountable drives - not disabled ones    Since the drive is disabled is it successfully being emulated by Unraid (i.e. does it appear to mount and its contents look intact) when the array is running in Normal mode.  It might be a good idea to provided your system's diagnostics zip file so we can see what is going on and provide more informed feedback.
 
The standard way to clear a disabled state is to rebuild the disk.  If you think the disabled disk is OK then you can use the process to Rebuild a drive onto itself, but if not sure ask for advice.

All drives in Unraid main array are self contained file systems that can be read by any Linux system.  If using Windows then you will need additional software that supports the required file system type (probably reiserFS if really such an old Unraid system)

I do not know if it does, but if you cannot tell us what command you actually used and what sort of output it produced then anything we say is only going to be a guess.   I am not sure how xfs_repair interacts with encrypted drives as I have never personally bothered to use xfs encrypted drives.   You are likely to get better informed feedback if you attach your system’s diagnostics zip file to your next post in this thread.

If you only have single parity then re-arranging them is easy as drive slot number is not part of the parity calculation.   You just use the New Config tool; rearrange the drives; tick the parity is valid checkbox ; start the array.  

However parity2 DOES use the slot number as part of its calculation so rearranging drives breaks parity2.

The syslog you listed shows that when you tried to format a drive (sac) it would get an I/O error and drop offline.    It was then re-connecting with a different Id.    This suggests that either that drive really does have a problem or the power and/or SATA cabling to the drive have an issue.
 
 

One of the limitations of ZFS is that if you have a pool with a vdev size of 3 drives you can only extend it with another vdev of 3 drives.

I would not bother as CRC errors are very rarely anything to do with the drive, but are typically due to issue with the power and/or SATA cabling to the drive.

If you did not have parity then any files on the failed disk are lost.  Files do not span disks so any files left should be intact.
 

If you have reset the array via Tools->New Config then there is no need to put the old disk back - just build parity with your new parity disk based on the data disks you want to keep in the array.    Where you physically connect the drives is irrelevant as Unraid recognises them by their serial numbers - not by where they are connected.

Why do you think everything should be on cache?   With the settings you show new files should go to the cache until mover runs, but older files will have been moved to the array.

Really up to you.   If you are familiar with rsync I would tend to use it as it gives you more control.

No, but it is the drive you rebuild, not parity.   Replacing the drive requires rewriting every sector on that drive with its new contents and during that process Unraid will be reading from all the other data drives and the parity drive to reconstruct it’s contents.   There is no need to first copy the data elsewhere as the rebuild process puts back the contents.   It’s a good idea, though, to keep the removed disk intact until the rebuild finishes just in case anything goes wrong during the rebuild.
 

Under Settings->Global User Share settings you have set restrictions on which drives can be used for User Shares and all those drives are full  I suspect you mean to allow some of the other drives be used for User Shares as well?
 
It is normally better to let that setting be left at all drives and then use either Include or Exclude settings on individual shares if you want to restrict the drives they can use.  It is easy to forget the global setting when you add additional drives.

Have you checked under Settings->Global Share settings that you have allowed disk1 to be used for User Shares?

Have you tried clicking on the Orange icon to see what it says is the problem, and then using the Acknowledge option on the drop-down menu so you only get notified about new changes.