![r/unRAID icon](data:image/svg+xml,<svg xmlns="http://www.w3.org/2000/svg" width="161" height="162"><rect fill-opacity="0"/></svg>){kind=small}
Mover breaking docker when run
I've just set up my first unRAID server a few days ago and every time the mover runs it completely breaks my docker setup. Running containers, stopped containers, I can't even install new containers.
I'm using a NVME SSD pool as primary storage for /mnt/user/appdata/ with the array set as secondary storage, and I have set docker to folder mode at /mnt/user/appdata/docker/ because the image was shown as taking up over 100GB of storage space with only a few small containers installed.
Now every time the mover moves data from the SSDs to the array docker completely breaks and the only two ways I've found to fix this are either disabling docker for a few seconds, which also removes all containers, or having the mover move everything back to the SSDs.
I'm guessing I'm having something configured wrong but I have no idea what because as far as I understand everything pointing to /mnt/user/ should be able to access all data regardless if it's on the pool or array so the mover moving data around between the two shouldn't affect anything.
Comments Section
some few clarifications, the size of the docker image is that large because it is reserved space for your installed docker containers. See it as a VM image that you have set to a certain size as well, the space is reserved for that purpose.
The reason why you have problems with your docker is because your mover is trying or is actually moving something in relation to your docker (probably the image) to your array.
So, the natural misconfiguration is that your shares are trying to move something to your secondary storage that shouldn't be moved there in the first place.
My general rule of thumb is this:
Frequently READ files should be moved to the array
Frequently WRITTEN files or files that need a high random read speed should remain on the array
So, for example, Video files are usually read more often so they should be written on the cache temporarily but then stored long-term on the array. Files like the docker AppData or the Docker image or virtual machine images should not be put on the array because they have frequent writes that would always force your array to update the parity and keep the drives running and the writes and reads happen randomly because of the many applications inside of the docker containers so you would hinder yourself in terms of usability speed when they are running on much slower HDDs.
But that doesn't mean you shouldn't include the array as a secondary storage location, instead, you should configure your share with the mover action cache <- array. This means that even when, for some reason, files are being written to the array that are in a share that should be on the cache, the mover would move them to the cache.
So if I understand you correctly then my problem is indeed because the mover is moving things around it shouldn't, I'm guessing mostly the content of /appdata/docker/ because otherwise it shouldn't stop containers which were shut down while the mover was working from being started back up again.
So the solution is to keep /appdata/ on the SSD pool while using the array as fallback storage in case writing to the pool temporarily isn't possible for some reason?
Also, should I set docker back to using an image file instead of a folder and maybe move it to its own dedicated share, possibly with a SSD for itself alone?