itimpi

Did you disable of the services - not just running instances while running mover?   Keeping the services running will keep files open so that they then get ignored by mover.

Any drive that fails the Extended SMART test should be replaced. 
 
In addition having pending sectors (let along lots of them and the number increasing) is a bad thing as that would prejudice the error-free recovery of any other drive that failed.
 
Neither of the above should be affected by cabling as they are internal to the drive.  Power issues might cause problems but I doubt that is the issue - I would think it is the drive itself that is the problem.

Your appdata, system and domains shares all have files on disk1 which explains why disk1 and parity disks are spinning up.
 
These shares typically want to be held on a cache pool for performance reasons and if you are running the VM or Docker services they will hold files open (which stops mover transferring files).

It could just be a bad cable as 100 Mbps is less stringent than 1Gbps.  A bad port is also a possibility but I would think less likely.

The simple way to express it that the security on a port is as good as that of the application handling that port.   Therefore in your case that is the security capabilities of NextCloud.  Also, since you are presumably running NextCloud in a docker container then when setting up the volume mapping for the NextCloud container you should not give it any access to more of the Unraid server's filestore than it needs to operate correctly.

Have you checked under Settings->Unassigned Devices->SMB Security that you do not have it set to No (which means do not make it visible on the network).  You want at least one of the other modes - probably Public I would guess which used to be the default until security on shares was tightened and the No option was added and made the default.

That will not do anything as mover ignores shares which are set to ‘Only’.
 
I suspect the current issue is that due to earlier activity some files exist on both the cache and the array.   Mover will not overwrite an existing file.   Such a situation needs to be cleaned up manually and it is up to the user to decide whether the copy on the cache or the copy on the array is the one to keep/

It should be a different issue I believe.
 
BTW:  You can always manually make a local flash backup by clicking on the Boot drive on the Main tab and selecting the Backup option from there.

It looks like you must have installed a plugin that is trying to download that file as it does not happen with the base Unraid build.   You can check this by booting in Safe Mode as that would disable any plugins from running.

I would definitely try the USB2 port as experience has shown them to be far more reliable than USB3 ones.     If it works on the external USB2 port then I see that board also has USB2 headers that you could use if you prefer the drive to be internal.   I also recommend (if possible) a USB2 based flash drive although they are now getting a bit harder to source as they also seem to work more reliably if you only have USB3 sockets available.
 
on paper USB3 feels like it should be a better solution but experience has shown this is often not the case although it could change as the technology gets better and uSB3 support improves.

It may not be making that many accesses.   Perhaps just  keeping the file open might be enough?

Yes, because the parity drive has no file system.

There should be a progress.save file in the plugins folder on the flash drive.   If you PM me that I might be able to work out why you do not get the correcting/non-correcting indicator.    The fact that it is being flagged as a Manual check shows the plugin HAS updated the history as that is not done as standard.   There is also a config/parity-checks.log file on the flash drive that is of interest so I can see if the correcting status WAS recorded there but not displayed when you invoked the history so you could PM me a copy of that as well.
 
If you do not activate any of the extra functionality then the plugin will not be doing anything in those areas so any side-effects should be minimal/unlikely.   The plugin does not install any new binaries which are the commonest reasons for plugins causing instabilities.   You can see if Limetech will enhance the history without the plugin but not sure if they have any plans in that area so good luck with that.
 
That is because of changes at the forum level and many previous links have recently been broken by the changes.    The link in the plugin has been updated for the next plugin update (as part of getting ready for the 6.12 Unraid release).

That message is quite normal as described here in the online documentation describing the process for repairing an XFS file system.  You need to run without -n and add -L.

You seem to have at some point created a User Share called 'Cache' which is the cause of your problem and is why the system will not let you create a pool called 'Cache'.    The cache.cfg file you posted is that for a User Share - not that for a pool.  Since this share does not exist on any drive at the moment you can delete the config/shares/cache.cfg file from the flash drive and then the system would let you create a pool called cache.

Yes, and if it asks for it use the -L option

According to the diagnostics it appears that your cache drive has dropped offline (which would explain the dockers not working).   I would carefully check and power and SATA cabling to the drive.

Your syslog shows that many files on the cache seem to already exist on the array.   Did you manually try moving files from the cache drive to an array drive at any point?   I am asking as mover will not move a file from cache to array if that file already exists on the array.    In Normal operation a file should only exist at one location - either on the cache or on the array - not both.

The default setting for a new share is Export=No which means it is not accessible via the network.   If you want it to be visible you will need Export=Yes.

The strange size being displayed when you call up the history will almost certainly be because you have the Parity Check Tuning plugin installed.   There was a change in the 6.11.x series to the format of the history file and the way showing history is invoked and this is not being accounted for.   I am in the final stages of testing an update to the plugin that will correctly handle this (and also show the extended history information the plugin records).   When the update is available (hopefully in the next few days) and installed then that field will have the expected value (even for the existing entries). 

Parity can still be valid if something caused file system corruption as parity does not understand file systems - only bit patterns on a disk.
 
The correct handling of unmountable disks 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.

If you want persistent logs that survive reboots then you should enable the syslog server.

What is doing this mount?    Whatever is doing it will be hiding the normal contents of /mnt/user which is all the user shares.

Since you see to be using a completely different set of drives have you used Tools->New Config to reset the array?
 
You are likely to more informed feedback if you attach your system’s diagnostics zip file to your next post in this thread.

If you really want to start clean you could just restore the key file from the config folder in the backup to the config folder on the flash drive.