itimpi

That QNAP device will not be capable of running Unraid as it has an ARM based processor, while Unraid requires a x86 based one.

Should be fine.
 
You might find this item on Unraid 6.12-rc4 to be of interest in understanding about Unraid storage management.

It is normal for this path to exist in addition to /mnt/user.  The user0 path is the contents of the share ignoring any files that are on a pool whereas the user one does include any pool files.   /mnt/user disappearing is typically caused by the shfs process that supports user shares crashing.
 

Parity does not backup your shares - it merely provides the mechanism that means if an array drive fails then its contents can be reconstructed.   You still need backups of any important/critical data.
 
in terms of shares showing some files are unprotected that is normal if the share in question has files on a pool (cache) and that pool is not redundant.

The cache drive is not showing up, but since you rebooted before taking diagnostics we cannot see what lead up to that.
 
Your best chance at this point is to power-cycle the server to see if the cache drive becomes visible again.  If not then it has probably failed.

The parity check tuning plugin will get the correct times in the final report and the history record when the operation completes.   I believe the problem is that the standard Unraid reporting does not take into account properly the fact that an array operation is running in increments.

Have you tried doing a file system check on disk?

If you keep the file system type the same the data will still be there on the drive (which is now a cache drive).  If the relevant shares are set to Use Cache=Yes and pointed at that cache drive mover will subsequently transfer the data to the array.

You can change as many disks as you like after using New Config.   Any data on existing disks being kept will be left intact.  Any data on drives being removed will no longer be there. 
 
Shares will remain intact, but you may have to make adjustments if you have set includes/excludes to match the new set of drives.
 

That suggests you need to run again without the -n option so it can be fixed.    If it asks for -L give that option.

You can use the Parity Swap procedure which is designed for exactly this Use Case.

That is not a valid unique GUID.    It should not change as it is meant to be set at the hardware level.    Have you tried rebooting the server (possibly with a power cycle involved) to see if your flash drive gets back to reporting a valid GUID.   If it continues to report that GUID of all zeroes then there is a problem with the flash drive and your only option will be to move to a different flash drive that DOES report a valid GUID.

For the first problem I would suggest deleting the config/network.cfg file from the flash drive and rebooting to get a new default one generated as it looks as if there are remnants of when you had 2 active NICS in there.
 
Regarding problem 2 the ASM1166 does not appear to be showing up at the hardware level.   You should check if your motherboard has any restrictions on where it can be plugged in, and if not check it is properly seated.

Unfortunately not   as part of tightening security a password is now mandatory.
 
the only way to achieve what you want would be to set up a separate web server (probably in a docker container) and go via that.

According to the diagnostics the flash drive has dropped off-line (or failed).
 
You will need to reboot (possibly with a power-cycle) to rectify this.  If you can while doing this I would plug the flash drive into a PC/Mac to check i can be read correctly (and make a backup if you do not already have one).   
 
If you have a choice of ports on the server use a USB2 one in preference to a USB3 one as they tend to be more reliable.

The issue you have to contend with is that the moment you move disks between slots this will invalidate parity2,  Parity1 does not care about slot number.
 
The procedure I would recommend is:
If you have not done one recently do a parity check to ensure that parity is currently valid and no drives have issues. Use Tools->New Config and select the option to retain all current assignments Return to the Main tab and unassign parity2 Set the data drive assignments as you want them to end up Click the Parity is Valid checkbox and start the array to commit the drive changes.  Ignore any message that suggests parity will be overwritten as it does not take into account the checkbox being ticked. At this point the array should now be operational with all the data intact and parity1 in place for protection.   If you have any shares that were including or excluding a drive whose position you have changed the settings will need amending appropriately. Stop the array Assign parity2 Start the array to rebuild parity2 based on your revised drive assignments.   This is likely to be the most lengthy step.  

You may find this part of the documentation useful in at least identifying which are data and which are parity drives.

Change it with the array stopped.
 
I suspect the docker image file got corrupted when the cache drive got full.
 
I would delete the current document and recreate it 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.  Then follow the instructions for reinstalling your existing apps keeping settings intact.

The problem with drives larger than 32GB is that the flash dtive needs to be formatted as FAT32 which standard Windows cannot do.  As long as you can get it formatted that way larger drives should work.

In that case it is highly likely that your new server will ‘Just Work’ once you have put it together and plugged in the drives without you having to do anything.

You might find 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 useful in at least identifying the parity drives.   It will not give you the order of the data drives but that will only matter if you have restricted shares to particular drives (and in such a case you can probably work out the original order by examining their contents once they are back online).

I would think the most likely culprit is the power supply as that is when the current draw is likely to be at its max.

To clear the disabled state you need to rebuild the parity 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.
 

Checking parity does not affect performance (except while the check is running).   It is a housekeeping task to confirm the array is in a healthy and consistent state.   While a parity check is running array performance is degraded so you do not want to run it too frequently.
 
Probably the commonest frequency chosen is once a month, but others go for something less frequent like every 2-3 months.  If you have large drives you may find the Parity Check Tuning plugin is worth installing to give you more control over the process.
 

Is the 4TB drive an Unassigned Device?    You cannot have a parity drive that is smaller than any of the data drives.
 
In terms of copying data the easiest way is to install and  use the Dynamix File Manager plugin.