itimpi

The network interface seems to be continually going up and down.   Have you tried rebooting the router.
 
i notice that you seem to have Jumbo frames enabled.   In my experience these tend to cause more problems than they are worth and provide negligible performance gain.

There is a known problem with docker that can cause this that had been fixed in the 6.12.3 release.

How is the disk in question connected?   In the diagnostics I see:
Jul 26 19:03:07 unraid1 kernel: sd 2:0:3:0: attempting task abort!scmd(0x000000002f39e8d5), outstanding for 7339 ms & timeout 7000 ms Jul 26 19:03:07 unraid1 kernel: sd 2:0:3:0: [sdh] tag#1801 CDB: opcode=0x85 85 06 20 00 d8 00 00 00 00 00 4f 00 c2 00 b0 00 Jul 26 19:03:07 unraid1 kernel: scsi target2:0:3: handle(0x000c), sas_address(0x4433221105000000), phy(5) Jul 26 19:03:07 unraid1 kernel: scsi target2:0:3: enclosure logical id(0x500605b004e9ec1f), slot(6) Jul 26 19:03:07 unraid1 kernel: sd 2:0:3:0: task abort: SUCCESS scmd(0x000000002f39e8d5) which suggests some sort of connection issue.

The Unraid GUI needs to be on eth0.   Maybe this is your problem and you need to set the 2.5G connection to be eth0?  Also, have you made sure the 1G and 2.5G connections are on different subnets?

Booting up on another PC will not do any damage on that machine as you do not try to configure anything.
 
it might be worth downloading the zip file for the Unraid release you are using and extract all the bs* type files overwriting the ones in the root of the flash drive just in case there is a problem reading one of them.

Sounds like there may be some issue successfully reading the system files off the flash drive.   
 
I would suggest you try downloading the zip file for the release you are using from the Limetech download site and extract all the bz* type files overwriting the ones in the top level of the flash drive as this sometimes seems to help.

I would suggest that you update to the current stable release (6.12.3 with 6.12.4 coming soon) to see if the problem still exists.

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.