itimpi

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.

You need to reinstall the docker container binaries into the docker.img file (a new one should have been created when you re-enabled docket).   If you do it via Apps->Previous Apps then they will be re-installed with the same settings as last time.

This was unecessary and maybe even counter-productive as it puts stress on the failing drive.  Rebuilding the contents of the failed drive would get back the contents anyway.
Sounds like you have encryption set as the default under Settings->Disk Settings?    Regardless you can click on the drive on the Main tab and set its format explicitly to a non-encrypted file system which should now let you start the array.
 
Unraid will be quite happy if you want to leave parity1 slot empty.
 
You cannot combine removing parity2 and assigning parity1 into a single step.  Moving parity2 to the parity1 slot involves
Stop the array and unassign parity2 Start the array to make Unraid 'forget' the parity2 assignment Stop the array and assign the old parity2 to parity1  Start the array to commit the change and build the contents of parity1 (it uses a different algorithm to parity2). Until step 4 completes your data will be unprotected against another drive failing.

The licence is tied to the flash drive that is used to boot Unraid and therefore each server requires its own licence. 

A drive is disabled when a write to it fails for some reason.  Since you rebooted before taking diagnostics then we cannot see what lead up to this, but the commonest cause is connection errors due to SATA or power cabling.  These can sometimes be transient errors so not always easy to diagnose without the diagnostics so if it happens again then make sure to capture them before rebooting.
 
The SMART information for the parity disk looks OK, but if you want to be confident this is the case then click on the drive on the Main tab and select the option to run the extended SMART test.  This runs completely internally to the drive so is not affected by cabling issues (except perhaps a power issue).
 
To clear the disabled state you need to rebuild the contents of the parity drive.  The process for rebuilding a drive to itself is covered here in the online documentation.

I think the file system resize happens at array start, so an array stop/start may fix it.  If not a reboot probably will.

Whatever disk you want to get files off!
 
Parity has no file system and stores none of your data.

The sda1 device is almost certainly your flash drive so the screenshot indicates that one of the Unraid system files cannot be read from it.   This can sometimes be fixed by simply overwriting all the bz* type files (extracted from a zip file version of the Unraid release).  I would suggest you started by putting the flash drive into a PC/Mac to check you can read the flash drive and making a backup before trying the above.   If that does not work it might suggest the flash drive is failing.

It is worth pointing out that the config folder on the flash drive has your settings.   When you have a flash drive that is booting then just copy that from the backup and it should then boot OK. 

There are lots of 
May 23 21:09:34 Tower kernel: XFS (md3): Corruption detected. Unmount and run xfs_repair  
You need to run a check filesystem on disk3