A Bind Mount Can Hide Files Already in an Image

Suppose a voice service image contains /opt/voice/models/en/model.bin. It works without extra mounts, yet a deployment reports that the model is missing. One possible cause is a bind mount of an empty host directory onto /opt/voice/models. The mount presents the host directory at that path, so the packaged model is hidden from the running container.

Docker’s bind mount documentation calls this obscuring: mounting a file or directory over existing container data masks what was there. The image bytes have not been removed. Docker says there is no straightforward way to unmount the path inside that container to reveal them; recreate the container without the mount to see the original layout. This makes a missing file error during startup a deployment question as well as an image question.

The mount source is a path on the Docker daemon’s host. A remote Docker client cannot bind a path from its own laptop into a daemon running elsewhere. Docker Desktop adds host sharing for its virtual machine, but a server deployment still depends on the actual daemon host’s paths. That coupling matters when the same voice image moves from a development machine to a worker whose directories differ.

Check the exact source and target before starting the container. With --mount type=bind, Docker normally errors if the source path does not exist. The shorter -v form can silently create a missing host source as a directory, which can turn a typo into an empty overlay. The Mounts section of docker inspect shows the source, destination and read/write mode for a created container. For the model example, compare that destination with the paths the image packages and the application opens.

Use readonly or ro when the service only consumes host data. That blocks writes from the container through the mount, which is useful for reference models or configuration, but read-only does not reveal image files hidden underneath. A host-side edit can also change the data the container reads. If a deployment needs one host-provided file, mount at the narrowest suitable target; if it needs the packaged model, leave that directory unmounted. Validate both the image’s expected paths and the deployment’s mount map before treating a startup failure as a broken build.