itimpi

You can always change the file system for any array drive, but it involves reformatting it so any existing data is wiped so any contents needs first copying elsewhere to avoid data loss.

This.  
 
Once Unraid selects a disk for a file it does not change its mind if it does not fit - it gives an out of space error.

This.
 
When booting off that drive you would then be taken through the licence transfer process.
 

Was there any reason you did not use Apps->Previous Apps to reinstall containers with previous settings intact - that tends to be easier.

Yes.   In fact it makes interpreting any diagnostics easier so recommended.

The docker.img file is a ‘sparse’ file so the space occupied on disk can be less than the allocated size (although space occupied will grow towards allocated size as it is used).   In that sense they can both be right.

You need to keep the one that has the same capitalisation as the folder name for that share (Linux is case sensitive whereas Samba shares are not).  Then make sure the settings for the remaining one is what you want.

You have less than 2TB on the pool (the size of the smaller drive), so you could change the profile to be RAID1 and run a Balance.  After that it would be possible to remove the larger drive from the current pool.
 
If the 4TB drive is then used in a new single drive pool then it would be optimal for performance but not redundant.   You could have regular backups done to the array via a script run using the User Scripts plugin - not sure if that will suit your needs?   It is worth pointing out that even redundancy/parity is not a replacement for backing up critical data so you should still have a backup strategy in place for really important stuff.

These are normally OK if Molex->SATA but tend to be problematical if SATA->SATA.

Try removing the Mover Tuning plugin and then trying again.

You seem to have an empty docker.img file.   You may have more than one so the one currently being used was probably created as a new one while sorting out your other issues.   You either find the original, or (probably easier) reinstall the container binaries with settings intact via Apps->Previous Apps.

It sounds like you may be falling foul of the issue mentioned in the Caution in this section of the online documentation.   If that is the case then you are probably best setting the share up to be cached and files later moved to the array.

Yes.

What was the folder name on the pool?   If it was the share name that would explain your symptoms because a top level folder with the same name as the share is considered to be part of that share if it is on ANY array disk OR pool regardless of the settings for the share.

Not really looked into it, but I would think that the FUSE file system component that Unraid uses to support User Shares will contain entries that point to where any file accessed that way is really located so I would think the statement is true.   Still an interesting question to ask 😊

When you use docker exec you are referring to a path within the container, but ‘find’ in the Unraid terminal uses a path at the Unraid level and it is unlikely these are the same.

You should check between steps 4 and 5 that there are no files (or folders) for the share left on the main array.  You can do this using the Dynamix File Manager.  Note that mover will not overwrite files that are in both locations so if that scenario exists you will have to manually delete one copy and you have to decide which one (typically the oldest ).

There are a number of speedtest docker containers available via the Apps tab.
 
If you have booted in GUI mode then you could also do a speedtest from the Unraid GUI by going to speedtest.net from there.

Not sure why you think you have a problem?
 
I would think the ‘cache’ pool is getting full because the contents of the ‘appdata’ share are larger than the size of the ‘cache’ pool and your system is set to move as much of its contents onto it as it can.
 
the Public’ share will show as unprotected if it currently has any files/folders on the ‘fastlane’ pool (which has that pool set to act as a cache for the share) and that pool is not redundant.
 
i also see you have 160GB set for the docket.img file - why so large?   The default of 20GB is enough for the vast majority of users as long as all containers are configured correctly.

The cutover point is not a percentage of the disk but based on the actual size of the largest data disk.    The largest disk is 1TB so the first cutover  point would therefore be 500GB and at point the remaining disks are not larger than this so are not used.  The next cutover point will be 250GB so disk1 and disk2 will be used until they get down to this, and then disk3 will start being used.

Your settings for docker containers were stored on the flash drive so if you had a backup then you could get your docker containers without setting them up again.    Unfortunately without a backup you have to configure them again.  Note that it is only the ‘config’ folder from the flash drive that is important as all user settings are stored there.

Once you have valid parity in Unraid then parity is maintrained in realtime any time you make writes.

UDMA errors are connection errors - not drive errors.   The value never gets reset so fixing the connection issue simply stops it increasing.
 
Once a drive has been disabled you need to rebuild it to clear this status.   If you think the drive is OK then you can Rebuild it to itself.

All parity drives have to be at least as large as the largest data drive so the message was valid as at that time you still had a 4TB parity drive present.

With Unraid 7 mover can operate pool->pool.    With the 6.12 release mover only supports doing it in two stages pool1->array and then array->pool2