itimpi

You might find something like this to be more reliable.    The problem with the ones you have is that if you connect 4 drives to them they might be subject to voltage sag when under load as the SATA connection at the host end is less robust and can carry less current than the Molex equivalent and that can cause the symptoms you are seeing.
 
Your issue could of course be something else entirely but power issues can be a bit tricky to track down at times.

I think you are falling foul of the behaviour described in the Caution in this section of 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.   

Your diagnostics are showing resets on multiple drives.  Are you sure your PSU is capable of handling that many drives?

There has been a bug where the notification give the results of the previous check rather than the one that has just finished.

The syslog in the diagnostics is the RAM version that starts afresh every time the system is booted.  You can enable the syslog server (probably with the option to Mirror to Flash set) to get a syslog that survives a reboot so we can see what leads up to a crash.  The mirror to flash option is the easiest to set up (and if used the file is then automatically included in any diagnostics), but if you are worried about excessive wear on the flash drive you can put your server's address into the remote server field.

Have you tried creating the flash drive using the Manual install method.   In my experience it is more reliable than using USB Creator.

This is true as far as it goes.   The normal answer is to install the CA Backup plugin to backup the 'appdata' share that is on cache elsewhere (typically the main array) at scheduled intervals.

if you are simply rebuilding the parity to larger drives and not using the specialist parity swap procedure then the Parity Check Tuning can be set to pause the process while drives are too hot, and automatically resume it when they cool sufficiently..

It is due to the fact that you had an unclean shutdown while a manual check was running and the plugin does not clear the state information for the manual check after the reboot when an automatic check starts so it is triggering an internal check on state for a scenario that is not meant to happen..  This should auto-fix itself when the automatic check finishes, but if you want to stop it immediately you can delete the party.check.tuning.manual file in the plugins folder on the flash drive.   The next release of the plugin will handle this scenario more tidily.

Yes.  
 
With parity drives the only requirement is that none of them are smaller than the largest data drive.

This is a bad sign for disk2:
197 Current_Pending_Sector -O--C- 100 099 000 - 50 so I think the drive should be replaced.   When you add a parity disk then Unraid is unable to recover a failed disk unless all other disks can be read error free.
 
There is also this:
# 1 Extended offline Completed: read failure 90% 34760 1693889040 and we normally say that any drive that cannot pass the Extended SMART test should be replaced.

You could delete the config/vfio.cfg file on the flash drive and reboot.

The New Config option 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. The Unraid OS->Manual section in particular covers most features of the current Unraid release.
 
i recommend you use the option to keep all current assignment, and then just remove the drive you longer want in the array on the Main tab before starting the array to commit the change.   No need to physically disconnect that drive.   Your dockers, etc will stay installed.

Looking at that SMART report and the syslog entries it looks likely that the drive really has failed.
 
you could try and run an extended SMART test on it (possibly on another system) as if that fails it is normally enough to get a RMA (assuming the drive is still under warranty).

I would expect that you can just delete the file and it would be recreated.

With those settings at the container level, you want to tell Plex to transcode to /transcode.   The docker system will then redirect that to /tmp/plex_transcode at the Unraid level.

Unraid currently requires at least one drive in the array.   If you do not intend to use it to store anything a workaround is to use an old flash drive.

You should:
Disable the Docker service under settings (it needs to be disabled to stop it keeping files open) Run mover to transfer the contents of the 'system' share to the cache (optional) When that completes you might want to confirm that there is now no sign of the 'system' share on disk1  Set the secondary storage option for the 'system' to None Enable the option to use Exclusive shares under Settings->Global Share settings to get the performance advantage of bypassing the Unraid Fuse layer  Reenable the Docker service Once this is done then docker will not be keeping disk1 and parity spun up all the time.

Did not spot anything obvious either!
 
It might be worth installing the File Activity plugin to see if that gives a clue as to what is accessing the drive.

It is most likely to be something you have configured in a docker container.

The reason that 32GB is mentioned is that the flash drive needs to be formatted as FAT32 and Windows does not support as standard doing this on drives over 32GB.   Also Unraid only needs something like 1-2GB on the flash drive so large drives have lots of space that will never be used.

Do you by any chance have the Docker Folder plugin installed?   If so you should remove it (it has been replaced by Folder View).
 
if it is not that you are likely to get better informed feedback if you attach your system’s diagnostics zip file to your next post in this thread.

More often than not when a drive is disabled (because a write failed) it was due to an external factor and the drive is physically OK.

Your screen shot shows you ran a correcting parity check which made the parity agree with the data drives.  Had you by any chance had an unclean shutdown earlier - they would normally cause a few sync errors.   You should then not expect any further errors on the next check
 
Was this a manually initiated check or a scheduled one?   Just asking as we normally recommend that scheduled checks are set to be non-correcting so that faulty hardware will not end up corrupting parity before you are aware of any issues.

That output suggests there is some level of corruption.
 
You ran with the -n option (the no modify flag) so nothing was fixed.    To actually fix it you need to run without -n (and if it asks for it add -L). 
 
After that you can restart the array in normal mode to see if the drive now mounts.   I expect it will, so you then need to look for a lost+found folder which is where the repair process puts any folders/files for which it could not find the directory entry giving the correct name and gives them cryptic names instead.  Not having this folder is a good sign that the repair went perfectly.   However if you DO have that folder you have to sort its contents out manually or restore any missing files from backups (which is normally easiest if your backups are good enough).