itimpi

That is enough to get the drives included in the space calculations.   Deleting the empty folders will rectify the space calculation.

That is quite normal.   If you get that you need to run with -L (and without -n) to get the repair done.

When you use a folder for docker (rather than the more common image) that represents the used and free space on the drive holding the folder.

When you set the array as primary storage all new files go to the array but existing files are left where they are.

For Mover to move anything you need the pool set as primary storage, and the array as secondary storage snd mover direction set accordingly.   If there is no secondary storage set on a share then mover does nothing.  
 

The syslog in the diagnostics show eth0 is only running at 100Mbps.    Commonest cause of this is a LAN cable which does not have all 4 internal wire pairs making end-to-end contact (100Mbps only requires 2).

Looks like you are getting macvlan related crashes.  
 
Jun 9 02:21:23 UNRAID root: Fix Common Problems: Error: Macvlan and Bridging found You can avoid these either by switching docker networking to use ipvlan instead of macvlan or if you want to continue using macvlan disable bridging on eth0.

Yes.
 
Make sure you have set a Minimum Free Space setting for the ‘cache’ pool to avoid it filling completely.

The 32GB limit is not a hard limit but is recommended simply due to the fact that the drive needs to be formatted to FAT32 and Windows will not format drives larger than 32GB to FAT32.   Unraid itself only needs a couple of TB GB so even with 32GB there is lots of space unused.    If you use drives larger than 32GB then you might want to use a 3rd party tool such as Rufus to format the drive to FAT32, or the USB Creator tool also knows how to do this.
 
Because Unraid runs from RAM there is no benefit (except perhaps a few seconds faster boot) to having USB3 drives.  Heat is the enemy of USB drives, and USB2 drives (if you can get them nowadays) tend to run cooler than USB3 ones and thus last longer.   Failing that the USB3 ones with metal casings to improve cooling are a good idea.

What you want is not possible using standard Unraid.   Visibility on the network (and access) is controlled at the share level, not for folders within that share.

I see in your syslog
Jul 1 00:41:31 Home-server rc.docker: created network macvlan br0 with subnets: 172.16.10.0/24 and this combination is known to cause instability.    You should either switch docker to using ipvlan or if you need to continue using macvlan ensure bridging is disabled on eth0.

You now need to run with -L and without -n.

First I should point out that you are looking at legacy documentation.   It is not necessarily wrong but you need to treat it with caution.
 
In terms of running the commands you never want more than one instance referring to the same drives (either as source or target).   The reason is that if you do this it will typically be slower than running the commands one a time as you start causing excessive head movements on any drive referenced in more than one command.   If you have a parity drive this effect can be even more marked as even when the command do not reference the same drives you can get contention on the parity drive.

The only share that now has files on the cache pool is the ‘appdata’ share.   You are not going to fully resolve this issue unless you either get a cache drive large enough to hold all of the appdata share, or set that share to not all be held on the cache.    If you have the Dynamix File Manager installed you can use this to see what is the total size of the appdata share, and also investigate exactly how much space individual apps are using within that share.

Assuming you are running from the GUI (which is strongly recommended) Unraid will only let you run xfs_repair in Maintenance mode.

Yes when your smaller disks are half the size of the later on AND are in higher number disk slots.
 
Not that I know off.
 
The allocation methods are described in some detail 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.

Precleared disks are portable between systems (assuming you are not using a RAID controller on either system) asthe preclear signature is stored on the drive so there should be no issues.
 
Precleared disks can be added to an existing array without the need to rebuild parity,
 

Another possibility that occurs to me  is that if disk 6 can be successfully replaced on the original controller (with a drive of 2TB or less) then there would only be one disabled disk on the new controller so disk 3 could be 'repaired' to use 3TB as Unraid will think it is a new disk since the size changed.

A major difference is that one typically uses the New Config tool any intend to keep drives in the main array.   This is different to never having had drives there in the first place which is the case with a new install.

It should work but is officially an unsupported setup.    You should look in the "Virtualizing Unraid" part off the forum if you want more information or help getting it working.
 

Not quite.   If you use 'cp' then the data will end up on both drives.   You need to either delete the files from disk1 after doing the copy or use a command that does a move.   
 
When a file exists in the same location on more than one drive then Unraid will initially show the copy on the lowest number drive and hide the other one.   This can then get confusing as if you delete the file it appears to not happen as this then 'uncovers' the copy on the other drive.

Not surprising as the location /mnt/cache refers to a ‘cache’ pool that you do not have so that ends up being a location in RAM which is lost when the system is rebooted.
 
Any reason you changed the path for the docker.img file from the default value of /mnt/user/system/docker.img?   That would have been ok.
 

There are 2 basic approaches I can see.
Upgrade the parity disk to 8TB (as no dataa drive can be larger than the parity drives) and then one at a time replace the other disks rebuilding their contents onto the new 8TB drives.  Create a new array of 8TB drives and then mount the old 3TB drives one a time using Unassigned Devices to copy their contents onto the new 8TB based array.   If going this route it would be fastest to only add the parity drive at the end after doing the copying. Option 2 assumes that you are going to replace all drives at the same time.    Option 1 is the more traditional Unraid approach as it can spread the cost over time and allows you to upgrade capacity more slowly as you only add the 8TB data drives as you need the space.

It sounds as if the flash drive might have failed  
 
Do you have a backup of the flash drive?

I seem to remember a  comment about the USB drive being inside one of the NVME bays.   
 
The Linkstation home site has detailed instructions on how to reinstall Unraid once you have the USB boot drive.  They boil down to the same instructions that can be used when installing Unraid onto a flash drive for any other system.
 

You need to follow the steps outlined in the link I gave.   For instance the first step is NOT to start the array but to unassign the disabled disk.