Volumes

Purpose

daemon/volume/ implements named volumes (docker volume create/inspect/ls/rm), the bind/tmpfs mount machinery used by docker run -v, and the plugin protocol that lets external volume drivers add storage backends.

Layout

daemon/volume/
├── volume.go        # Volume + Driver interfaces
├── drivers/         # Driver registry; resolves names to either built-ins or v1/v2 plugins
├── local/           # Built-in `local` driver (bind to /var/lib/docker/volumes/<name>/_data)
├── mounts/          # mount specs, validation, parsing of -v / --mount
├── safepath/        # Safe path-resolution helpers (chrooted lookups)
├── service/         # VolumesService — the API-facing facade
└── testutils/

Volume vs mount

A "volume" is a named entity managed by a driver. A "mount" is the per-container request to attach a volume, bind-mount a host path, or create a tmpfs. The mount specs (and parsing for both the legacy -v syntax and the newer --mount syntax) live in mounts/.

The VolumesService (service/) is the API-facing object held by Daemon.volumes. It wraps the driver registry and tracks reference counts so that a volume in use can't be removed.

Built-in local driver

local/local.go implements the default driver. Volume data lives at <data-root>/volumes/<name>/_data. Volume options (--opt type=tmpfs,o=size=100m) translate to mount flags applied lazily when the volume is mounted into a container. On Linux it can also act as a thin wrapper around mount(2) for filesystem-typed volumes (e.g. NFS).

Plugin volumes

A volume name like myplugin:vol1 (or just vol1 when the daemon is configured with a default driver) is resolved by drivers/ through the plugin manager. Both legacy v1 plugins and managed v2 plugins are supported; the protocol is the simple JSON-over-Unix-socket scheme used elsewhere in the daemon.

Mount safety

safepath/ prevents path-traversal attacks when copying files into or out of a running container. It chroots into the container's filesystem before resolving paths, ensuring symlinks cannot escape the rootfs.

API surface

The router is daemon/server/router/volume/; it talks to volumebackend.Backend (daemon/server/volumebackend/), which is implemented by Daemon and ultimately delegates to VolumesService.

Cluster volumes

CSI cluster volumes are surfaced through the swarm subsystem (see Swarm cluster) and attached to tasks by the cluster executor. They reuse the mount spec types but live under api/types/volume/cluster_volume*.go.

Tests

• Unit tests next to each file.
• Integration coverage in integration/volume/ and integration/internal/container/.

Entry points for modification

• New mount option: update mounts/parser.go and validation in mounts/validate*.go.
• New volume driver capability: extend the Driver interface in volume.go and the plugin protocol in drivers/.
• Concurrency or refcounting: see service/.