3 hours ago, trurl said:

Then you set them back to prefer cache to get them moved back as explained at that link.

That link looks to be out of date, since as far as I can tell, there is no "prefer cache" option any longer. At least I haven't seen it.

I've looked through all my docker settings, and as best as I can tell, they're all looking at /mnt/user/ not /mnt/cache, with the exception of one (Rustdesk, which I fixed).
So why are all the container appdata folders getting recreated when the docker service restarts? It's baffling.

Ok, I think I have it cleaned up. It appears that overnight the server sorted it self out and only the Rustdesk files were left on the cache this morning. I deleted those manually, so now there's nothing showing on the cache drive, although it does report that 537MB are in use. I assume that's just overhead, or are there hidden files I should be hunting down?

Edited June 9Jun 9 by Elmojo
cleaned up to reflect new data.

51 minutes ago, Elmojo said:

That link looks to be out of date, since as far as I can tell, there is no "prefer cache" option any longer. At least I haven't seen it.

prefer cache is the old terminology from before 6.12. The link does discuss versions before and after, and how to work with 6.12 and above.

prefer cache is the same as Primary:cache; Secondary:array; Mover action:array->cache.

56 minutes ago, Elmojo said:

are there hidden files I should be hunting down?

What do you get from command line with this?

ls -lah /mnt/cache

Or you can use the File Manager to look at the contents of cache:

14 minutes ago, trurl said:

What do you get from command line with this?

root@Tower:~# ls -lah /mnt/cache

total 16K

drwxrwxrwx 1 nobody users 0 Jun 9 14:55 ./

drwxr-xr-x 17 root root 340 Jun 9 16:00 ../

15 minutes ago, trurl said:

prefer cache is the same as Primary:cache; Secondary:array; Mover action:array->cache.

Gotcha. I figured there would be updates once 7.x was released.

So this just leaves the issue of why I have (at least) one VM that didn't migrate. As best I can tell, it didn't pick up the new location of the disk image.
I pointed it to the existing image in the new location (array), but now it says no boot device found, or similar. Is there any way to recover it? I sure hope so...
EDIT: I recovered the VM using a URBackup image.

Edited June 10Jun 10 by Elmojo

I was able to fix the VM issue myself by restoring the image from a backup.
I guess now I just need to pull the old (failing) cache drive and send it in for repair or replacement, then reverse the process once I receive the new one.
I'll try to remember to update once that's done, in case any else runs into a similar issue in the future.

Update/resolution:
Samsung replaced my faulty SSD under warranty.
After replacing the drive, and moving my VMs and dockers back onto the cache, the machine is now fully back up and running.

Thanks to everyone for the help!
Issue resolved.