Volumes

dockmesh’s Volumes page lists every named Docker volume across every host, with size, mount count, and driver.

Named vs bind mounts

Docker has two types of persistent storage dockmesh tracks differently:

Type	Example	Managed by
Named volume	`analytics_pgdata`	Docker (under `/var/lib/docker/volumes/`)
Bind mount	`/srv/data:/data`	You (any path on the host)

Named volumes show up in Volumes. Bind mounts show up per-container but aren’t in the global list — they’re filesystem paths, not Docker objects.

The list view

Columns:

Column	Description
Name	Volume name
Driver	Usually `local`; can be `nfs`, `cifs`, or third-party plugins
Mountpoint	Absolute path on the host
Size	Disk usage (may be slow on large volumes — cached)
Used by	Container count currently mounting it
Host	Which host holds the volume
Created	Timestamp

Creating volumes

Usually volumes are created automatically when a stack with volumes: is deployed. To create one manually:

Actions → Create volume opens:

Name
Host
Driver (usually local)
Driver options (e.g. for NFS: type=nfs, o=addr=10.0.0.5,rw, device=:/share)
Labels

Pruning

The Prune unused volumes button under Resources → Volumes removes every named volume that isn’t currently mounted by a container. Prune is destructive — the data in those volumes is gone.

Safety today is a single confirmation dialog (“This cannot be undone. Volume data is deleted.”). There is no built-in dry-run preview and no backup-job awareness — if you have a backup target pointed at a volume name that’s about to be pruned, the prune still runs. The recommended workflow is: pause any backup job referencing the volume, run the prune, restart the job.

Browsing content

Click a volume → Files tab to browse its content in a read-only file tree. dockmesh first tries direct filesystem access via the volume’s mountpoint; if that fails (Docker volumes default to root:root 0700), it falls back to spawning a short-lived alpine helper container with the volume mounted, which sees the contents as root inside its own namespace.

This view is intentionally read-only — heavy operations (download, upload, edit, delete) aren’t exposed here. For write access, exec into a container that mounts the volume and use cp / tar.

Migration across hosts

When Stack Migration moves a stack to another host, named volumes are streamed over the mTLS tunnel via chunked tar. Bind mounts are not moved automatically — they point to host-specific paths.