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's guaranteed to disappear.

Anything you need after docker rm has to be written to a mount. Think of a database directory, uploaded files, or a cache you don't want to rebuild. A mount is 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. You'll run each one on the main lab VM (secopslog-docker). The lesson files contain site/index.html, a one-line page. You can 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). The text survived because it was written under /data, where the volume lab-notes is mounted. You don't even need docker volume create. -v lab-notes:/data creates the volume on first use if it doesn't exist. That's convenient, and it's 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. Docker Desktop keeps them inside its own Linux VM, so on a Mac or Windows laptop there's 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 you're 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's 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. It kept them, so 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's 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's mounted. The files aren't 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 doesn't 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) can't 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 couldn't 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 isn't 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. "Volumes, bind mounts and tmpfs in practice" in Docker in depth covers the rest. That includes ownership details, SELinux labels on Fedora and RHEL (:z and :Z), and how to back up and restore a volume.

Try this

Recreate lab-notes and write the note into it as before. Then leave a stopped container behind with docker run --name lab-note -v lab-notes:/data alpine:3.24 true (no --rm) and run docker volume rm lab-notes. Predict whether the removal works, check, then docker rm lab-note and try the removal again.

Takeaway

Anything that must outlive docker rm goes into a mount. The writable layer took /note.txt with it, and the next cat exited 1. For bind mounts in scripts, prefer --mount: -v quietly created a root-owned uploads directory, while the uplaods typo under --mount failed loudly with exit status 125.

Related