Taztrophe

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!

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?

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.

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

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).

Attached. tower-diagnostics-20210308-0017.zip

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