Very new to Unraid and Docker but have successfully installed and configured both a Pihole and Plex container which have been running for two weeks with no problems. Tonight I added a LogitechMediaServer container which also came up fine. I was annoyed by the fact that the random hostname appears as the library to which I connect my Squeezebox devices so went about determining if I could change the hostname of the container. I found a couple solutions and tried both. First I used the nsenter command in the console to connect to the container and ran hostname which worked but wasn't persistent after a restart of the container. Next I found a solution that looked like it changed the hostname in the configuration of the container which would be reboot persistent. Per the guidance, I stopped all my running containers then stopped the Docker service (all from the GUI). I then edited the hostname within the file /var/lib/docker/containers/CONTAINER_ID/config.v2.json (where CONTAINER_ID was the container ID for the newly installed LogitechMediaServer.  I tried to restart the Docker service (enable in the GUI) and it reported "Docker Service failed to start" on the Docker tab. I did manage to find in the system logs that the docker.img failed to mount (root: /mnt/user/system/docker/docker.img is in-use, cannot mount).

 

Concerned that my edit of the hostname in the container may have caused the issue, I restored the hostname value to its original value but the Docker image file still failed to mount. I looked for some further guidance on determining the problem but was having trouble finding specific help on how to check my docker.img file.

 

I haven't changed anything so I can provide a diagnostic capture if needed.

 

TIA for any help!

 

-- Taztrophe

6 hours ago, Taztrophe said:

diagnostic

Always 

Attached. tower-diagnostics-20210308-0017.zip

Possibly unrelated but your system share has files on the array. You should clean that up.

 

What do you get from the command line with this?

ls -lah /mnt/disk2/system

 

root@Tower:~# ls -lah /mnt/disk2/system
total 16K
drwxrwxrwx 1 nobody users 12 Feb 21 19:36 ./
drwxrwxrwx 1 nobody users 44 Feb 24 22:06 ../
drwxrwxrwx 1 root   root  20 Feb 21 19:36 docker/

 

I set most of the drive configurations either as default or per guidance I found online. All the filesystems that should be on fast filesystems were set to Prefer: Cache. Are you saying I should have them as Cache Only? I think I set them as Prefer so I wouldn't have a failure if for some reason the Cache filled but if that's causing issues I'll change it. I thought with Prefer: Cache it wouldn't move them unless it actually ran out of space (which it hasn't). But I suppose it could have occurred while I was transferring files from my old NAS at which time the Cache may have temporarily filled.

 

And I just looked to confirm. My docker.img is in fact in that docker folder on disk2 listed above. I'm guessing that's my issue? Wouldn't Prefer:Cache cause Unraid to move it back to the cache drive at some point? Not sure why it moved it as the cache has plenty of space (and did last night when I was messing with stuff).

Mover can't move open files. You have to disable the Docker service in Settings to get that moved.

Docker is currently disabled (in Settings). That was the original issue. After disabling, it wouldn't reenable.

Go to Settings - Docker and delete docker.img. Enable will recreate it in accordance with the settings on that page, so it will get created on cache where it belongs.

 

Then your containers can all be reinstalled exactly as they were using the Previous Apps feature on the Apps page.

Ok. Thanks. I saw some mentions of that last night but wanted to ensure there wasn't an easier fix that I was missing somehow before doing that. Gonna give that a go now.

Thanks again for the help. That was shamefully easy. Back in operation just like that.

 

So to prevent any odd behavior going forward, I should set the appdata, system, and domains (vm storage) shares to Cache Only, correct?

Prefer should be OK unless you fill up cache. Probably the only thing that could overflow to the array in that case would be appdata since system already exists on cache. The most likely cause of system winding up on the array is having the docker service enabled when there isn't a working cache drive in the system.

Ok cool. I have no idea what quirk happened last night to trigger the docker.img being placed on the array disk versus on the cache (my mover is scheduled for 1:30am) but recovering the img file being so easy made it pretty painless to correct.

 

Thanks again for the help!