trurl

Your question is really about the Unassigned Devices plugin. You can go directly to the correct support thread for any of your plugins by clicking its Support link on the Plugins page.

The paths you already have specified in those settings should result in them being created on cache.
/mnt/user/... are the user shares, which include all array disks and all pools.
Enable Docker and VM Manager, then post new diagnostics
 
 

The host path you specified is in RAM just like the rest of the Unraid OS. Typically you should use user shares (in /mnt/user) for host paths. The best place for that particular host path is probably going to be a subfolder named for that specific container within appdata (/mnt/user/appdata).

The correct settings for those shares would be
Primary:cache; Secondary:array; Move action:array->cache. That would get them moved to cache.
 
But, nothing can move open files, so you have to disable Docker and VM Manager in Settings before running mover
 
Try that, wait for Mover to complete, then
 
Post new diagnostics.

Check filesystem on disk1 disk2 from the webUI, capture the output, and post it.
 

Looks good! You can enable Docker and VM Manager again.
 
I see you already have appdata backup plugin installed so that's good.
 
How are you backing up flash?

You must not create any folders at the top level of /mnt, that is for the OS to do.
 
This is probably the result of specifying the path /mnt/appdata as a host path in one or more of your containers. The correct path would be /mnt/user/appdata
 
If you actually had a pool named cache, then /mnt/cache would be a valid path, but since you don't, it's not. Possibly another container host path wrong.
 
You do have a pool named cache_nvme, so /mnt/cache_nvme would be valid. But linux is case-sensitive, so /mnt/Cache_nvme is different and not valid. Possibly another container host path.
 
You seem to have a lot of non-existent user shares in the diagnostics, which makes me wonder if you don't have other incorrect paths specified causing files to be saved at the top level of /mnt/user or some disk or pool where they wouldn't actually be part of any user share. User shares are subfolders of /mnt/user, files directly in /mnt/user and not in a subfolder are not part of user shares.
 
What do you get from command line with this?
ls -lah /mnt/user  

If it works in SAFE mode then that would suggest some plugin is to blame.

USB not recommended for assigned disks. Also SSDs in the parity array cannot be trimmed, and can only be written at parity speed.
 
Unraid V7 doesn't require you to have an array. Usually SSDs would be put in pools.
 
 

If you didn't change any disk assignments since that backup then I would consider reusing it, except maybe the .plg files in config/plugins since they were probably way out-of-date.
 
And if you are unsure if any disk assignments were changed, you could just delete config/super.dat and it will make you assign array disks again.
 
That might give you a head start.
 
config has your share settings in config/shares, it has your docker templates in config/plugins/dockerMan/templates-user.
 
Almost all files in config are text, you can examine them. and maybe figure out how they correspond to webUI settings. And decide what you want to transfer from the backup to your new flash.
 
For future reference, you can always download a zipped copy of flash from Main - Boot Device - Flash - Flash Backup. Also, Unraid Connect plugin will keep a backup of your flash in Unraid Cloud.
 
You must always have a current backup of flash. When you make any settings in the webUI, they will be lost unless they are backed up.

Instead of replacing computer, another possibility would be to empty one of your existing drive by moving its contents to other drives, then reformat it to XFS, move files to it to empty other drives, repeat. You could also upsize drives to make room for emptying other drives, etc

Looks good!

That share has no setting for Mover action.
 
Set it to Primary:cache; Secondary:array; Mover action:cache->array.
 
Then after you get it moved, if you don't want new files to go to cache you can set it to Primary:array.

Tools - New Permissions, select Shares from the Disks/Shares dropdown on the left, select the Share in the right dropdown. press Start.

Both disks look OK, and emulated disk2 mounts. You can rebuild both at the same time.

Dynamix File Manager does Move as Copy to destination then Delete from source. Maybe 'arrs do too. 

Press the Stop button in your screenshot, and then post another screenshot.

RAM buffer filled up.

To simplify and clarify
 
Shutdown - Replace parity disk - Reboot
Assign new parity disk - Start array to begin rebuild

Needs to be set for cache so cache can overflow to the array, and for share, so share can choose another disk. But since you have only 1 array data disk, no other disk for the share to choose.
 
Disable Docker in Settings until you get cache fixed. 
 
cache is readonly now so nothing can be moved from it. If you have anything you wish to keep on cache, copy it.
 
Then you will probably have to reformat it before you can recreate docker.img, reinstall containers.
 

Rebuild is required because the disk is out-of-sync. The emulated filesystem is mounted so shouldn't be any corruption on rebuild.
 
Unraid disables a disk when a write to it fails. After a disk is disabled, it will not be used again until rebuilt. Instead, the disk is emulated. When the emulated disk is read, all other disks are read and the contents of the emulated disk are the result of the parity calculation. When the emulated disk is written, parity is updated so the emulated write can be recovered.
 
The initial write failure which caused the disk to be disabled, and any subsequent writes, are all emulated by updating parity. The actual disk is not written, so it is out-of-sync with the rest of the array, and must be rebuilt to recover the emulated writes and get back in sync.

Enabling Docker will create the paths specified in Docker Settings.
Enabling VM Manager will create the paths specified in VM Manager Settings.