Docker bind mounts: find hidden image files

Compare the image with the running container

The decisive clue is a mismatch between an unmounted run and the service that fails. Inspect the service container image ID so the comparison uses exactly the same build. A mutable image tag alone is not enough if another build has moved it.

Inspect the Mounts array and compare each destination with the missing path. A mount on /app covers /app/build and /app/node_modules as well as source files. The application sees the contents of the host directory at that location.

sh · EXAMPLE

container_id=$(docker compose ps --all --quiet api)
docker inspect --format '{{.Image}}' "$container_id"
docker inspect --format '{{json .Mounts}}' "$container_id"
# Use the image ID printed above for an unmounted comparison.
docker run --rm --entrypoint sh IMAGE_ID -c 'ls -la /app'

Build a minimal image with one known file

Create a new directory for this experiment, save the Dockerfile below there, then build it with the following section commands. The file is generated inside the image so it cannot depend on an untracked host build directory.

Use the name mount-proof only for this disposable image. The purpose is to show what the mount changes, independently of npm, a compiler, or a framework.

dockerfile · EXAMPLE

FROM python:3.12-slim
RUN mkdir -p /app && printf 'from-image\n' > /app/built.txt

Hide the file without deleting it

Run these commands from the new experiment directory on a local Docker daemon. The empty directory must exist before the explicit --mount form is used. The read-only option ensures the container cannot change that host folder.

The first run prints from-image. The mounted run cannot find /app/built.txt. A final unmounted run prints the original text again. Our validation observed this sequence against the same image, demonstrating a visibility change rather than a missing build artifact.

sh · EXAMPLE

docker build --tag mount-proof .
mkdir -p empty-host
docker run --rm mount-proof cat /app/built.txt
# Expected failure: the empty directory hides the image contents.
docker run --rm   --mount "type=bind,src=$(pwd)/empty-host,dst=/app,readonly"   mount-proof cat /app/built.txt
docker run --rm mount-proof cat /app/built.txt

Choose a smaller development mount

If you only need to edit application source, mount the source subdirectory instead of the entire application root. If build outputs must be generated inside a development container, choose and document their storage location rather than assuming image-time files remain visible underneath a host mount.

A separate volume for dependencies can be useful, but introduces its own lifecycle. An existing dependency volume can outlive an image rebuild and carry old packages. Treat that as an explicit design choice rather than a universal one-line repair.

yaml · EXAMPLE

services:
  api:
    image: your-api:dev
    volumes:
      - type: bind
        source: ./src
        target: /app/src
        read_only: true

Verify the corrected runtime view

Recreate the service after changing its mount configuration. Compare the effective mounts and list the exact missing file again. Check application startup after the file becomes visible; a successful ls does not prove the application can execute or read it under its runtime identity.

If the unmounted image is also missing the file, return to the build context and build output. If the file is visible but unreadable, inspect permissions. These branches keep runtime mount behavior separate from build and ownership failures.

Know the limits

The controlled example mounts an empty host directory over /app in a Linux container. Docker Desktop runs that container in its VM; remote Docker daemons resolve mount sources on the daemon host. A bind mount is not a backup and is writable unless configured otherwise. Reproduction checked on 26 October 2026 using Linux containers on Docker Engine 29.6.2 and Compose 5.3.1; this is the validation environment, not a minimum-version claim.

Sources & further reading

A technical publication by CoreTrailKit.

Browse all articles