A Dockerfile contains the instruction `VOLUME /var/lib/data`. What does the Docker daemon do when someone runs a container from that image, and why do hosts running such images accumulate dozens of unnamed volumes?

## What `VOLUME` really is `VOLUME ["/var/lib/data"]` in a Dockerfile writes an entry into the image's config metadata (`Config.Volumes`). It does not create storage while building. Its effect is entirely at container-creation time: the daemon reads that list, and for each path **not already covered by an explicit `-v`/`--mount` from the run command**, it creates a fresh volume and mounts it there. ## Anonymous volumes The volume Docker creates in that case has no name you chose. It gets a random 64-character hexadecimal ID and appears in `docker volume ls` as exactly that: ``` local 9f2c1a...c7e4 ``` Internally it is an ordinary volume with the `local` driver — same mountpoint layout, same inspect output. What distinguishes it is a piece of bookkeeping: because you never gave it a name, Docker marks it as anonymous, and that flag is what cleanup commands key on. The original intent was helpful: an image author signalling "this path holds state, do not leave it on the container's throwaway writable layer." The container gets working persistence even if the operator forgets to mount something. In practice the cost outweighs the benefit, which is why images like the official Postgres still carry it but most application images do not. ## Why hosts fill up Each `docker run` creates a *new* anonymous volume — there is no reuse across containers, because nothing identifies one anonymous volume as "the same state" as another. So the multiplication is linear in container starts: - CI that runs an integration test image 200 times a day creates 200 volumes a day. - A crash-looping container recreated by an orchestrator creates one per recreation (restarts of the *same* container reuse its volume; recreation does not). And plain `docker rm mycontainer` does **not** delete them. The cleanup paths are: - `docker run --rm ...` — removes the container and its anonymous volumes on exit. The habit to teach for CI. - `docker rm -v mycontainer` — the `-v` flag removes anonymous volumes attached to that container (never named ones). - `docker compose down` — removes anonymous volumes belonging to the project's containers; `-v` additionally removes the named volumes the file declares. - `docker volume prune` — on Docker Engine 23.0 and later this removes **only anonymous** unused volumes by default, precisely because that is the safe bulk cleanup; `--all` extends it to unused named volumes too. Symptom to recognise: `docker system df` shows a large VOLUMES row with a high count and near-100% reclaimable, and `docker volume ls` is a wall of hex. ## The build-time trap This is the part that separates people who have read the docs from people who have been bitten. Consider: ```dockerfile VOLUME /var/lib/data RUN mkdir -p /var/lib/data && ./seed-database.sh # writes 200 MB of seed data ``` During that `RUN`, the builder honours the declared volume by mounting a temporary volume at `/var/lib/data`. The script writes into that temporary volume, the layer is committed from the container's filesystem changes — and the volume's contents are **not** part of the layer. The image ships with an empty directory, the seed data is gone, and the error message is nothing at all. The rule: never write to a path after declaring it as a `VOLUME`; put `VOLUME` last if you keep it at all. The same metadata is also sticky through inheritance: a child image `FROM` a parent that declared a volume inherits the declaration, and there is no `UNVOLUME` instruction to take it back. You can only avoid the anonymous volume by always mounting something at that path yourself (`-v app-data:/var/lib/data` or a bind mount), which is the practical mitigation when you must consume such a base image. ## What to do instead Modern practice is to omit `VOLUME` from application Dockerfiles and document the persistent paths instead — in the README, in the Compose file, in the Helm chart. Persistence then becomes an explicit operator decision with a name attached, which means it can be inspected, labelled, backed up and deleted deliberately. `docker inspect --format '{{json .Config.Volumes}}' <image>` tells you whether an image you are about to adopt carries the declaration.