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

Actions → Prune removes all volumes not currently mounted by any container. Prune is destructive — data is gone.

Safety:

Dry-run shows what would be deleted
Confirmation requires typing the word prune
Backup job schedule is checked — if a job references the volume, prune is blocked

Browsing content

Click a volume → Files tab to browse the volume’s content in a read-only file tree. This uses a temporary helper container (alpine) mounted into the volume. Useful for checking whether a backup restore landed correctly, or for quick content inspection.

Heavy operations (download, upload, edit) are intentionally not here — use a proper tool for that.

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.