itimpi

Total disks in the system at the point the array is started regardless of whether they are being used by Unraid (and excluding the boot flash drive).  Removable drives plugged in after the array is started do not count towards the limit (but would need to be unplugged before the next time the array is started to not count at that point).

You should download the zip file for the release and extract ALL the bz* type file overwriting those on the flash drive as described 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.  

There were no obvious indications I could see that the drive in question is dying - just that there was file system corruption on the drive.
 
 
Drive can have many alternate names - md5 refers to disk5 in the parity protected array once it has been started.
 
You should run a check filesystem on disk5 to correct the file system errors.  If you do this from the GUI then you do not have to worry what name to use for the drive as the GUI takes care of this for you. 
 
If you simply replace the drive then the replacement will be rebuilt with exactly the same file system errors so you normally want to get this corrected before the rebuild (assuming you even want to go ahead with the replacement once the file system is corrected). 

When you use rsync then trailing slashes on the paths used are important - it looks like you go one of them wrong 🙂
 
You can probably correct most of the issues by using the 'mv' command from a console session and this would be the quickest.    If for any reason there are any issues doing this or you are not comfortable with the command line I suggest you use the Dynamix File Manager plugin to move them.
 
Since you also mention that you were not able to access the folder contents you probably also managed to get the permissions messed up so you should run Tools->New Permissions against disk17.

If you want to move the files to the main array this needs to be set to cache_ssd->array.     Your current setting is what you would use later to move the file back to the cache.

Each docker container can have its own requirements around any folders/files that are part of its working set located in a folder under the appdata share so the only foolproof way to fix it is to remove the relevant folder in appdata for a particular docker container and let it be recreated from scratch.  Any mappings to other shares should be OK.   You can do this for just those docker containers that have problems if you can identify them.
 
You can delete the folder using the Dynamix File Manager plugin with the relevant docker container stopped and then restart the container to get the folder recreated.   If there are any containers where you really do not want to loose the current working set data then you would have to ask for guidance on that particular container in its support thread.

The 'loop' devices are used to support docker and VMs.  In your case loop2 almost certainly refers to your docker.img file which by default is formatted as BTRFS internally.   You should follow the instructions here in the online documentation accessible via the Manual link at the bottom of the Unraid GUI to create a new empty image file and then re-instate and repopulate this file with your previous docker containers with settings intact.

Sounds as if you have been emulating that missing disk ever since without realising it 😒.  It is a common misconception that unassigning a disk is all that is required not realising that doing so will make Unraid treat it as a failed disk and start emulating it.   To stop this happening you need to follow the correct procedure to remove a disk from the array as documented 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.
 

Try removing the Mover Tuning plugin.

What about the power to the drive?    The noises could be an indication of insufficient power.  Do you use power splitters to get enough connections - they can cause problems.   You could try swapping the power cables with another drive to see if the problem stays with the drive or moves with the cable change.

Unless you have a very old CPU then doing 2 parity drives at the same time can run at a similar speed to doing a single one.   If the new parity drive is slower, that WILL slow things down as the speed is determined by the slowest drive at any point in the check.   I wonder if the new WD parity drive is using SMR technology rather than CMR as that could make a big difference .

According to the SMART report the drive failed the extended SMART test which indicates it should be replaced.

Your ‘system’ share is on disk1 so if you run any docker containers or VMs you will get the symptoms you describe.    You really want this share to be only on the cache pool.  You need the docker and VM services temporarily disabled to be able to move it as they keep files open in that share

The logs in the diagnostics start over every time the system is booted.    You would need to enable the syslog server to get a syslog that survives a reboot so we can see what lead up to the crash.
 
The commonest cause of instability seems to be using macvlan with docker so it might be worth checking for that.   The easiest solution is to switch to using ipvlan instead.

It looks like your ‘system’ share has files on disk3,   This means that if the docker or vm services are enabled disk3 and parity will be spun up most of the time.   You want to get all the contents of this share onto the ‘cache’ pool to avoid this and to maximise performance.
 
you also have a lot of .cfg files in the config/shares folder on the flash drive for shares that currently do not exist.    Deleting these will tidy up that part of the diagnostics and make it easier to spot relevant information. 

You need to contact support to get them to do this for you.

That suggests that you have something generating spurious keyboard input.

Yes.

I would suggest that you contact support giving the GUID for the new flash drive and they should be able to help you.

The problem will be that Unraid sets the start sector for the partition on the drive differently for SSD and HDD so the available space is not actually the same.

You should not have done step 4).   You would have got a pop up warning that this would create an empty file system; update parity to reflect this; and was not part of any data recovery process.   Without step 4) your data would have been rebuilt onto the replacement drive.
 
the correct process to use is documented 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.

Stop array unassign parity1 ready to make Unraid forget current assignment start array to commit change stop array assign parity1 start array to sync both parity drives

When it gets written to will depend on the Allocation Method you have selected for the share and how full your current drives are.   It can be some time!   You could manually create a folder corresponding to the share name on the drive if you want to force it to show up early.

If the file is located in the ‘system’ share (which is the default), then the linked process would work.   Alternatively you could use the Dynamix File Manager to do it manually.

Lots of the array drives started simultaneously getting errors and they do not show up in the SMART reports so they went offline.   This suggests a problem with something they share such as power or the HBA they are attached to.