trurl

These shares (anonymized) still have files where they probably shouldn't still be after running mover, so you probably have them misconfigured:
appdata shareUseCache="only" # Share exists on temp_cache, disk1 d-------s shareUseCache="yes" # Share exists on temp_cache, disk1 Y-----s shareUseCache="yes" # Share exists on home, disk1 appdata should be Primary:temp_cache; Secondary:array; Mover action:array->temp_cache
d-------s should be Primary:temp_cache; Secondary:array; Mover action:temp_cache->array
Y-----s should be Primary:home; Secondary:array; Mover action:home->array
 
Make those changes, run mover again, post new diagnostics

Check filesystem on disk1

Please note that I am talking about the flash drive that you boot from, not the cache drive.
 
All of your configuration is stored on flash. That is where the missing template files should have been. You must always have a current backup of flash. Do you?
 

You should never ignore FAILING NOW
 
https://en.wikipedia.org/wiki/Self-Monitoring%2C_Analysis_and_Reporting_Technology#Known_ATA_S.M.A.R.T._attributes

Starting a new thread is usually suggested to someone else when they try to get support for their (seemingly similar) problem in the same thread.

You can go directly to the correct support thread for that container by clicking its icon in your Unraid webUI and selecting Support.

Here are the relevant lines from your syslog
Jan 19 02:18:29 UR-SERVER kernel: md: recovery thread: recon D3 ... Jan 19 05:34:08 UR-SERVER kernel: md: sync done. time=11739sec Jan 19 05:34:08 UR-SERVER kernel: md: recovery thread: exit status: 0 Jan 19 05:36:30 UR-SERVER Parity Check Tuning: Parity Sync/Data Rebuild finished (0 errors) Jan 19 05:36:30 UR-SERVER Parity Check Tuning: Elapsed Time 1 day, 11 hr, 19 min, 46 sec, Runtime 1 day, 11 hr, 1 min, 44 sec, Increments 2, Average Speed 158.6 MB/s Jan 19 05:36:30 UR-SERVER Parity Check Tuning: Send notification: Parity Sync/Data Rebuild finished (0 errors): Elapsed Time 1 day, 11 hr, 19 min, 46 sec, Runtime 1 day, 11 hr, 1 min, 44 sec, Increments 2, Average Speed 158.6 MB/s (type=normal link=/Settings/Scheduler) exist status 0 means it was successful.

So that means the movies-4k folder has host path /mnt/user/data/torrents/movies-4k.
 
The container folder /data is mapped to the host path /mnt/user/data/torrents.
 
So, in the container, the path to the movies-4k folder would be /data/movies-4k, not /movies-4k

Jan 19 10:11:36 E-NAS kernel: BTRFS warning (device nvme0n1p1): csum failed root 5 ino 354410 off 2149146624 csum 0x0e9bd184 expected csum 0x6cad0ad0 mirror 1 Jan 19 10:11:36 E-NAS kernel: BTRFS error (device nvme0n1p1): bdev /dev/nvme0n1p1 errs: wr 0, rd 0, flush 0, corrupt 1, gen 0 btrfs csum failed is almost certainly bad RAM.

No need to physically remove the disks, just set the slots to no device then start the array.
Stop, reassign, restart

https://docs.unraid.net/unraid-os/release-notes/7.0.0/#zfs-pools

Looks like you may have flash corruption, several FSCK files there, which would explain empty go (and empty ident.cfg)
 
Do you have a current backup of flash?
 

Looks like connection problems. Check connections, SATA and power, both ends, then post new diagnostics.

Jan 13 13:39:00 B650-7700x kernel: BTRFS warning (device loop2): csum failed root 5 ino 269 off 4096 csum 0xa700954d expected csum 0xacb6b47d mirror 1 Jan 13 13:39:00 B650-7700x kernel: BTRFS error (device loop2): bdev /dev/loop2 errs: wr 0, rd 0, flush 0, corrupt 16, gen 0 Jan 13 13:39:00 B650-7700x kernel: BTRFS warning (device loop2): csum failed root 5 ino 269 off 4096 csum 0xa700954d expected csum 0xacb6b47d mirror 1 Jan 13 13:39:00 B650-7700x kernel: BTRFS error (device loop2): bdev /dev/loop2 errs: wr 0, rd 0, flush 0, corrupt 17, gen 0 Jan 13 13:39:00 B650-7700x kernel: BTRFS warning (device loop2): csum failed root 5 ino 269 off 4096 csum 0xa700954d expected csum 0xacb6b47d mirror 1 Jan 13 13:39:00 B650-7700x kernel: BTRFS error (device loop2): bdev /dev/loop2 errs: wr 0, rd 0, flush 0, corrupt 18, gen 0 csum errors on btrfs are usually bad RAM.
 
Have you done memtest recently?
 

Attach Diagnostics to your NEXT post in this thread.

Typically SSDs should go in a pool outside the array. SSDs in the array cannot be trimmed and can only be written at parity speed.
 
Any writes to array data disks also updates parity at the same time. 

Yes, and then continue with the next part in the docs about reinstalling your containers from Previous Apps.

Several of these and similar dockers in Apps

Correct
https://docs.unraid.net/unraid-os/manual/storage-management/#replacing-a-disk-to-increase-capacity
 
https://docs.unraid.net/unraid-os/manual/storage-management/#moving-files-between-a-pool-and-the-array

appdata backup plugin?

The config folder on flash is all you need to get your configuration going again. Possibly all you need is the super.dat file since that is where the array assignments are stored.

Just reformat and prepare the flash as a new install then copy the config folder from your backup.

Unassigned Devices plugin and Dynamix File Manager plugin.

Your appdata and system shares have files on the array. Not exactly the cause of your problem, but might as well fix these as well since you need to disable Docker anyway.
 
Nothing can move open files, so you have to disable Docker and VM Manager in Settings so these shares can be moved. Leave them disabled unti move is complete. In fact, leave Docker disabled until the rest of the fix below.
 
You can invoke Mover from Main - Array Operations page.
 
You can check that appdata and system no longer have files on the array by clicking Compute... for these on the User Shares page.
 
Finally, the actual cause of your problem, corrupt docker.img
 
You will have to delete and recreate docker.img
https://docs.unraid.net/unraid-os/manual/docker-management/#re-create-the-docker-image-file
 
Then reinstall your containers from Previous Apps.
https://docs.unraid.net/unraid-os/manual/docker-management/#re-installing-docker-applications