Volumes and bind mounts

Keep data when containers go away, and know which mount to use.

A container wrote one line to /note.txt. docker diff lists what the container changed compared with its image, and here it shows a single added file:

A /note.txt means the file was added in the container's writable layer, the per-container scratch area described in "Images, containers and the core commands". docker rm deleted that layer with the container. The new container started from the same unchanged image, so cat exits with status 1. Nothing failed. The write simply went to the one place that is guaranteed to disappear.

Anything you need after docker rm (a database directory, uploaded files, a cache you do not want to rebuild) has to be written to a mount: storage that lives outside the container and is attached at a path inside it. Docker gives you three kinds. A named volume is storage Docker creates and manages. A bind mount is a directory of the host (the machine running the Docker daemon) made visible inside the container. A tmpfs mount is memory. This lesson runs each one on the main lab VM (secopslog-docker). The lesson files contain site/index.html, a one-line page; create it yourself if you prefer, with the content cat prints below.

Named volumes

Create a volume, write through one container, read through another:

Both containers were removed as soon as they exited (--rm), and the text survived because it was written under /data, where the volume lab-notes is mounted. You do not even need docker volume create: -v lab-notes:/data creates the volume on first use if it does not exist, which is convenient and also how a typo in a volume name silently gives you a new, empty volume.

docker volume inspect shows where the data lives:

Mountpoint is /var/lib/docker/volumes/lab-notes/_data on a rootful Linux engine, and it stays there with the containerd image store that Docker 29 uses for images. Rootless Docker keeps volumes under ~/.local/share/docker/volumes, and Docker Desktop keeps them inside its own Linux VM, so on a Mac or Windows laptop there is no such path on your disk. The directory belongs to root, which is why the listing needed sudo. Treat that path as Docker's: read it when debugging, but change volume contents through a container. CreatedAt carries the VM's local timezone and will differ on your machine.

A mount can be read-only. The long --mount syntax spells every field out, which makes it easier to review than -v with its colon-separated fields:

The kernel refused the write (Read-only file system), and the shell exited 1. Mount data read-only wherever the process only needs to read it.

Bind mounts

A bind mount shares an existing host directory. Edits on either side are visible on the other immediately, which is what makes bind mounts the normal tool for local development:

Nginx served the file from site/ on the host. After the echo, the second request returned v2 with no rebuild or restart, because the container reads the host directory directly. readonly keeps Nginx from writing into your working tree. The -p 127.0.0.1:8080:80 part publishes the container on the VM's loopback address only, as covered in "docker run in depth".

The price of that convenience is coupling to the host. The path has to exist on every machine that runs the container, with the right contents and permissions. That is fine on your laptop and fragile on servers, so production data usually goes into named volumes and code goes into the image.

Mounting over files the image already has

The Nginx image ships two files in /usr/share/nginx/html. What you see at that path depends on what you mount there:

The empty named volume lab-html received a copy of the image's 50x.html and index.html the first time it was mounted, and kept them: a plain Alpine container sees the same two files in the volume. Docker populates a volume from the image this way whenever the volume is empty when it is first mounted, named or anonymous; the volume-nocopy mount option turns it off. It never happens for a bind mount. The empty bind mount produced no output at all: the host directory covers the image's files for as long as it is mounted. The files are not deleted from the image, just hidden. A web server that suddenly serves a blank page or a 403 after you added a mount is usually this.

A typo in a bind mount path

The two syntaxes disagree about a host path that does not exist:

With -v, the daemon created uploads for you, as root, and the container started happily with an empty directory. With --mount, the misspelled uplaods stopped the container from being created (exit status 125, the status docker run uses for its own errors). In scripts and Compose-like automation, the error is what you want. Use --mount where a missing directory should be a failure.

Who owns the files

Files written through a bind mount keep the numeric user and group IDs of the process that wrote them. The host has no idea what user names exist inside the image:

ls -ln shows numbers instead of names. The Alpine container ran as root, so from-root.txt belongs to UID 0 on the host, and the ubuntu account (UID 1000) cannot edit it. It can still delete it, because deleting depends on write permission on the directory, which ubuntu owns. A process running as UID 1001 could not create a file at all, since the directory is drwxr-xr-x for UID 1000. Running the container with --user "$(id -u):$(id -g)" made the new file yours. When a containerised app gets Permission denied on a bind mount, compare the UID the process runs as (docker exec <name> id) with the owner shown by ls -ln before touching the app. Choosing that UID deliberately is the subject of "Run as non-root" in Advanced container security.

tmpfs for scratch data

/proc/mounts confirms /scratch is a tmpfs: memory-backed, private to this container, and empty again the next time the container starts. Docker mounts it noexec,nosuid,nodev by default. It never lands in the container's writable layer or in a volume, which suits temporary files and sockets. It is not a secure vault: under memory pressure the kernel can swap tmpfs pages to disk, and its size counts toward the container's memory.

Choosing, and cleaning up

Clean up the lab. Removing the containers never removed the volumes; that always takes an explicit command:

docker volume rm refuses to remove a volume that a container (running or stopped) still uses. docker volume prune removes only unused anonymous volumes (the unnamed ones some images declare) unless you add --all, and it asks before it deletes. Ownership details, SELinux labels on Fedora and RHEL (:z and :Z), and backing a volume up and restoring it are in "Volumes, bind mounts and tmpfs in practice" in Docker in depth.

Try this

Work through “Choosing, and cleaning up” yourself on a sandbox you can throw away, following the commands above in order. Then break one step deliberately and re-run, so you have seen the failure before it finds you.

Takeaway

If you keep one thing from volumes and bind mounts, keep “Choosing, and cleaning up”. Decide now which check you will run when this shows up on a live system, and write it somewhere your team will find it.

Related