I’m still new to all of this so forgive my newbieness but I’m creating a container with a standard volume of -v /var/www but I’m having a hard time trying to find exactly where the files are getting created on the host system. I know I can run docker inspect [container] which will show the full path of where the files are on the host OS but I still am confused on where exactly that is.
I’m looking for them on the Windows 10 machine I have running the Docker CE for Windows but am not finding anything. I’m guessing that the files are getting stored to the default Linux Virtual Machine that docker uses when I run containers but I have no idea how to access that VM. In HyperV I can try to connect to the MobyLinuxVM but it never connects.
So what am I missing that could help me understand where this directory is on which host? Thanks in advance.
When you use just -v /var/www, you are telling docker you don’t really need the data volume to be accessible from the host. You’re telling it that the data volume is all internal to your container ecosystem and doesn’t matter from the host side – or that any access you need to that volume, from the host, will be accomplished through any of your running containers and not directly.
Your intuition is correct that you /could/ discover the volume’s home in docker-for-windows’ system but that path is not going to be a happy one, not straightforward.
The easiest solution to this is to change your volume declaration to either use a name for the volume or bind it to a specific directory on the host (see Docker or docker-compose docs in the area describing how to declare volumes). I suspect if you want direct as possible access to the volume’s files from the host, you may want to use a bind mount.
But here’s a warning about a follow-up problem; you’ll find that if you bind mount, Docker for Windows currently (yes, even a year after your post) is stuck on a problem where the container’s root user permanently owns the contents of the data volume, and chown and chmod do not work on that area within the container’s file system, and this remains true even if you try to trick docker by creating the volume first under another user before you bind it to the host. People are stuck on this and bailing out back to docker on its native Linux. There is also a workaround at http://docker-sync.io.