I’ve been puzzled by this but then realised it’s an architectural issue - don’t know if it’s solvable, please read on…
I’m within a team city container and have docker.sock from the host machine mounted. I was expecting to be able to start a container within the container by doing:
docker run --rm -v /container/path:/path/within/new/container ziptools zip -r /path/within/new/container/file.zip /path/within/new/container
So in other words, mount a directory that sits within the team city container, for the new container to see/write to.
The path appears on the new container but is empty. At first this was puzzling but then I realised if you specify -v /invalid/path:/path/within/new/container in a non-container-within-container situation you get the same behaviour. Nothing seems to validate the “host” path you’re passing to -v.
So the question is, if I’m within a container and using the hosts docker.sock, how can I specify a path within my container, which the hosts docker.sock can see and mount correctly in the newly created container? Or should I not bother because I’m way over-reaching what I should be trying with docker?