February 13, 20251 yr I started out with my Docker data-root set to "directory", then installed and removed a few containers while testing out Docker support within unraid. I have since switched the Docker data-root to a vdisk and recreated all of my containers. So far, the containers and container updates run fine. Can I safely delete the entire /mnt/pool-a/docker/btrfs directory now that all of my images are being stored in the vdisk? From what I've gathered this sounds correct, but I haven't seen it worded as such. Just looking for a sanity check before I nuke the /mnt/pool-a/docker/btrfs directory.
February 13, 20251 yr Author 37 minutes ago, trurl said: Attach Diagnostics to your NEXT post in this thread. beast-diagnostics-20250213-1457.zip Diagnostics attached.
February 13, 20251 yr Community Expert 1 hour ago, Rickerdo said: Can I safely delete the entire /mnt/pool-a/docker/btrfs directory now that all of my images are being stored in the vdisk? Yes. In any case, docker.img vdisk is easily recreated from your templates anyway. https://docs.unraid.net/unraid-os/manual/docker-management/#re-create-the-docker-image-file https://docs.unraid.net/unraid-os/manual/docker-management/#re-installing-docker-applications
February 13, 20251 yr Author Thank you very much for the quick responses! Safe to assume I can recursively delete the /mnt/pool-a/docker/image/ directory as well? I'm assuming everything under this directory is now stored in the vdisk. Again, just looking for a sanity check.
February 14, 20251 yr Author For posterity... Assuming Docker is running, the docker.img vdisk mount point can be found by issuing the following command from the command line. mount |grep docker.img Which (on my system) shows: /mnt/pool-a/docker/docker.img on /var/lib/docker type btrfs (rw,noatime,ssd,discard=async,space_cache=v2,subvolid=5,subvol=/) /mnt/pool-a/docker/docker.img on /var/lib/docker/btrfs type btrfs (rw,noatime,ssd,discard=async,space_cache=v2,subvolid=5,subvol=/) Once the mount point is found, take a look at the contents: root@beast:/mnt/disk1# ls -l /var/lib/docker total 16 drwx--x--- 1 root root 20 Feb 6 12:32 btrfs/ drwx--x--x 1 root root 152 Feb 6 12:30 buildkit/ drwx--x--x 1 root root 12 Feb 6 12:30 containerd/ drwx--x--- 1 root root 2816 Feb 13 18:30 containers/ -rw------- 1 root root 36 Feb 6 12:30 engine-id drwx------ 1 root root 10 Feb 6 12:30 image/ drwxr-x--- 1 root root 10 Feb 6 12:30 network/ drwx------ 1 root root 20 Feb 6 12:30 plugins/ drwx------ 1 root root 0 Feb 13 18:27 runtimes/ drwx------ 1 root root 0 Feb 6 12:30 swarm/ drwx------ 1 root root 44 Feb 13 18:27 tmp/ drwxr-xr-x 1 root root 12 Feb 6 12:40 unraid/ -rw-r--r-- 1 root root 154 Feb 13 16:53 unraid-autostart -rw-r--r-- 1 root root 5366 Feb 13 17:52 unraid-update-status.json drwx-----x 1 root root 184 Feb 13 18:27 volumes/ The directories and files listed can be safely removed from the previous path. On my server, this was everything under /mnt/pool-a/docker EXCEPT for docker.img. Bottom line... I was unaware that migrating from a directory based Docker data-root to a vdisk Docker data-root would leave behind so many unneeded files and directories.
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.