itimpi

You can find out by searching syslog for ata6 which shows:
Jun 27 09:40:26 Malta-Tower kernel: ata6.00: ATA-8: KINGSTON SH103S3120G, 501ABBF0, max UDMA/133 You can also from the GUI Main tab try clicking on the log icon for each drive. 

It is being started by an amended config/go file on the flash drive:
 
yours reads
#!/bin/bash # Start the Management Utility tor /usr/local/sbin/emhttp & /bin/bash /boot/config/wireguard/go while the standard default one issued with Unraid only contains
#!/bin/bash # Start the Management Utility /usr/local/sbin/emhttp &
if there are any files in the ‘extras’ folder on the flash drive they should also be removed.
 
More concerning is how a bad actor gained access to your server in the first place to make these changes.   Do you have your server exposed to the internet?
 

The other possibility is that the drives suffer from the 3.3v issue and need that pin taping off.

The values displayed are simply those being reported by queries to the BIOS.   If the 64GB will work in your motherboard then you should be OK regardless if what the BIOS reports to Unraid.

You ran with -n set which does a read-only check.   If you want any fix to be made then you need to remove the -n, and if it asks for -L then add that.   After that the repair should be done and the disk then mountable.

Things to consider are:
Reboot in Safe mode - if that works then you probably have a plugin causing issues.   You should make sure all your plugins are up-to-date so they include any fixes required for the 6.12.x releases. Under Settings->Display settings is the Page View set to tabbed or non-tabbed mode? Are you using a theme?  Your description sounds like what a tabbed view might look like under some theme? 6.12.3 is the current release not sure why you only got prompted for the 6.12.2 release.   You probably want to upgrade to this release ASAP as it includes some important fixes to help with avoiding unclean shutdowns.

OK - the following should work:
Disable the docker and VM services it looks like the ‘nas’ pool has not yet been formatted?   If so I would recommend it is set to use btrfs format, and then format it. under Settings->Global settings set the option to allow Exclusive access.  This is to later allow it to be used on suitable shares. Set the ‘system’ and ‘appdata’ shares to have Primary storage set to be the ‘nas’ pool with secondary storage set to be the array.   If you intend to run Vms you might want to also do this for the ‘domains’ share. set the mover action for these shares to be array->cache. click the Move Now option on the Main tab to make mover start moving files for these shares to the ‘nas’ pool.   This could take some time.   If you want to do it when mover completes you can unset the option to have Secondary storage as now all files for these shares should be on the ‘NAS’ pool you should now be able to set the ‘exclusive’ option for these shares which will maximise performance. Enable the docker and VM services under Settings.   your dockers should now be running off the ‘nas’ pool and should perform faster than when on the array.

Mover is very slow when moving small files as there is significant overhead due to checks done before moving each file.    Not sure how big the files are that mover is operating on although the syslog seems to suggest it IS still doing something.

You seem to have something writing to disk1 which will slow down the parity swap drastically.  I would expect things should speed up when that stops.

You have left our step 1.5 where you change the setting for mover on appdata to be cache->array as you want everything for that share to end up on the array.
 
as was mentioned step 3) needs the array set as secondary storage and mover action to be array->cache.
 
4. Mover will now move array->pool.    Mover does not support moving files between pools, only between the array and the linked pool.
 
step 4.5 change the settings for appdata to set secondary storage to none as all of appdata should now be on the pool.   You can also set Exclusive mode for better performance.
 
step 4.6. Check all docker/config configurations to make sure they never reference the old cache pool.    Going via the ‘appdata’ share is now best as with exclusive mode you get maximum performance.
 
 

Mover will never overwrite files so if a file exists in two locations you need to manually decide which copy to keep and delete the other one.

If you click on the orange thumbs down icon and select the Acknowledge option from the resulting menu then you will only be prompted again if it increase.   Note this value never resets so you can only stop it increasing.

You might find this section of the online documentation to be of use.

The syslog in your diagnostics shows:
Jul 18 17:54:47 BEAST kernel: nvme nvme5: Device not ready; aborting reset, CSTS=0x1 Jul 18 17:54:47 BEAST kernel: nvme nvme5: Removing after probe failure status: -19 This looks like some sort of hardware related error.    I would suggest making sure everything is firmly plugged in.

Multi drive pools have to be in btrfs or ZFS format - you cannot have them in xfs format.

This is a setting in the Mover Tuning plugin, so set it if you want this behaviour.   However I do not know if it ever has applied to other array operations although you suggest it did.   You should ask in this plugins support thread if you think it has changed.
 

This is not new behaviour - it is just that some bugs in the Parity Check Tuning plugin that could stop this behaviour working properly have been corrected.   It is controlled by a a setting in the Parity Check Tuning plugin so if you do not want this behaviour then you can switch it off in the plugin’s settings.  In most cases it is more efficient to pause the Parity Check while mover is running as the two processes both badly adversely affect each others performance.   It is obviously only relevant if mover DOES start while a parity check is already running which is outside the control of this plugin.

I thought the Parity Check Tuning plugin should also apply this behaviour if set for all array type operations so I need to work out why it has not done so in your case.
 
 
 
 

No.   When you selected the option to format it would have warned you that doing so would update parity to say the disk would then have an empty formatted disk and it was NOT the way to proceed if you wanted to keep the data.
 
As I said your only chance is to use specialist disk recovery software such as UFS Explorer or something similar.

Yes
 
That way if by any chance there a dive fails when building the new parity1 disk you have the old one available for recovery purposes.
 

This is the process that supports the User Share capability so you would expect it to always be running.

All the .cfg and the .ini files in the config folder on the flash drive should be human readable text files.   The disk.cfg file is in the diagnostics and is certainly corrupt as it is not plain text.
 
Do you have a backup of your flash drive?    It is possible that the flash drive is failing and needs replacing.

I’m assuming your parity drive(s) are at least 18TB as no data drive can be larger than the smallest parity drive?
 
when you rebuild to a larger drive the last step is to expand the file system to fill the drive.

Handling of unmountable drives 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.

This is not possible in the current release as you cannot have pools as both primary and secondary storage, and mover therefore will not move files between pools.  It is possible that this restriction may be removed in a future release (perhaps 6.13) but until it happens what you want cannot be done.

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 discusses this issue.

you should update to 6.12.3 as it contains a docker related fix that might fix this.    Post again if it does not.