Chapter 3: Volumes
This introduction explains why applications use volumes to keep data outside container images, clarifies what bind mounts do, and previews the security considerations and volume features covered in the chapter.
After this chapter you will be able to
- Reasons for separating application data. Explain why application data may be kept outside a container image: to avoid embedding data such as database contents, reuse one image across environments, improve storage performance, or share network-stored content.
- Bind mount paths and changes. Describe how podman run --volume (-v) HOST-DIR:CONTAINER-DIR bind mounts a host file or directory at a container path, and explain that content changes are visible from either side when writing is permitted.
- Read-only mount and cleanup. Explain that :ro makes the mounted content read-only to container processes while host processes can still change it, that mounts default to read/write, and that :z relabels content with a shared SELinux label. Describe why removing the container leaves the host content intact.
- Named volume creation and use. Explain how a named volume differs from mounting an existing host path, and describe creating a volume with `podman volume create`, inspecting its mount point, and using it with a container.
- Named volume lifetime and cleanup. Explain that named volumes can be shared by multiple containers and persist after a container is removed, that `podman run` creates a named volume automatically if it does not exist, and how to remove a volume and its dependent containers.
- Rootless volume ownership. Explain why a rootless container process may be unable to write to a bind-mounted directory, and how the :U option fixes its ownership.
- Shared and private SELinux labels. Distinguish the SELinux relabeling performed by lowercase :z and uppercase :Z, including when each is appropriate.
- System directory labeling risk. Explain why recursively relabeling an existing system or home directory can be harmful, and describe the section’s alternative for examining such directories from a container.
- Mount option behavior and limits. Explain that podman run --mount accepts options understood by the Linux mount command and passes them to the kernel, while supporting only bind, volume, image, tmpfs, and devpts mount types.
- Data separation through mounts. Justify keeping writable or non-application-specific data in volumes or mounts rather than in a container image: images can generally be treated as read-only, avoiding copy-on-write overhead can improve performance, and the same image can be used with different data.
What it builds on
- Differences between a container and an image (chapter 2) · The distinction between a container and its image.
- exec-ing into a container (chapter 2) · Editing index.html inside a running container with podman exec
Section by section
Introduction
This introduction explains why applications use volumes to keep data outside container images, clarifies what bind mounts do, and previews the security considerations and volume features covered in the chapter.
- Reasons for separating application data: Explain why application data may be kept outside a container image: to avoid embedding data such as database contents, reuse one image across environments, improve storage performance, or share network-stored content.
Why it matters: These reasons explain when a volume is useful rather than putting everything in the image. - Bind mount data semantics: Describe a bind mount as making the same host files or directories accessible at another filesystem location, without copying or creating data.
Why it matters: This distinction helps you reason about what happens to the underlying files when content is shared with a container. - Volume security and chapter scope: State that giving containers access to volumes adds security complexity because container protections normally restrict access to files outside the image, and describe the chapter's preview of host sharing, user namespaces and SELinux, volumes in images, volume types, and volume commands.
Why it matters: The chapter treats access to outside data as both a useful feature and a security concern.
Key terms: container image, volumes, overlay, fuse-overlayfs, bind mounts, file hierarchy, user namespace, SELinux, container images
3.1 Using volumes with containers
This section shows how to serve host-provided web content from a container with a bind mount, then explains mount permissions and cleanup.
- Host content instead of edits: Explain why mounting host content is preferable to changing the web page inside a running container with podman exec: it lets users supply or update content without relying on an error-prone, hard-to-scale editing method.
Why it matters: This explains the problem that volumes solve in the web application example. - Bind mount paths and changes: Describe how podman run --volume (-v) HOST-DIR:CONTAINER-DIR bind mounts a host file or directory at a container path, and explain that content changes are visible from either side when writing is permitted.
Why it matters: The host-to-container path mapping is the key to supplying content without embedding it in the container filesystem. - Read-only mount and cleanup: Explain that :ro makes the mounted content read-only to container processes while host processes can still change it, that mounts default to read/write, and that :z relabels content with a shared SELinux label. Describe why removing the container leaves the host content intact.
Why it matters: These options determine whether the container can write to the mounted web files and how SELinux handles them.
Key terms: podman exec, volumes, container filesystem, podman run, --volume, -v, HOST-DIR:CONTAINER-DIR, bind mount, :ro, :z
3.1.1 Named volumes
This section shows how to create, use, retain, remove, and transfer Podman named volumes.
- Named volume creation and use: Explain how a named volume differs from mounting an existing host path, and describe creating a volume with `podman volume create`, inspecting its mount point, and using it with a container.
Why it matters: Named volumes provide a reusable place for container data without requiring you to choose an existing host path. - Named volume lifetime and cleanup: Explain that named volumes can be shared by multiple containers and persist after a container is removed, that `podman run` creates a named volume automatically if it does not exist, and how to remove a volume and its dependent containers.
Why it matters: A container's removal does not necessarily remove its data, so volume cleanup needs its own decision. - Volume archives and plugins: Describe how `podman volume export` writes a volume's contents to a TAR archive that can be moved to another machine and restored with `podman volume import`, and state that plugins can provide other types of volumes.
Why it matters: These features extend volumes beyond data stored and used by one local Podman installation.
Key terms: named volume, podman volume create, podman volume inspect, mount point, local-named volumes, podman run, podman volume rm, --force, podman volume ls, volume plugins
3.1.2 Volume mount options
This section explains how Podman volume options handle ownership and SELinux access, and when a different mounting option is needed.
- Rootless volume ownership: Explain why a rootless container process may be unable to write to a bind-mounted directory, and how the :U option fixes its ownership.
Why it matters: The right ownership lets an application running as a non-root user write to its volume. - Shared and private SELinux labels: Distinguish the SELinux relabeling performed by lowercase :z and uppercase :Z, including when each is appropriate.
Why it matters: Choosing the right label controls whether other containers can access the mounted data. - System directory labeling risk: Explain why recursively relabeling an existing system or home directory can be harmful, and describe the section’s alternative for examining such directories from a container.
Why it matters: Avoiding an inappropriate relabel protects host files that other confined processes need to use. - Read-only and alternative mount options: State what :ro does and why Podman offers --mount in addition to the simpler --volume option.
Why it matters: These options help you select the needed access mode and mounting syntax.
Key terms: :U, user namespace, UID mapping, chown, podman unshare, :z, SELinux, relabel, --security-opt label=disable, SELinux enforcement
3.1.3 podman run - -mount command option
This subsection explains how Podman’s --mount option exposes Linux mount options and why mounts keep writable data outside container images.
- Mount option behavior and limits: Explain that podman run --mount accepts options understood by the Linux mount command and passes them to the kernel, while supporting only bind, volume, image, tmpfs, and devpts mount types.
Why it matters: This helps you describe what --mount can configure without assuming it supports every mount type. - Data separation through mounts: Justify keeping writable or non-application-specific data in volumes or mounts rather than in a container image: images can generally be treated as read-only, avoiding copy-on-write overhead can improve performance, and the same image can be used with different data.
Why it matters: Separating data from images makes images more reusable and can make data access faster.
Key terms: podman run --mount, Linux mount command, bind, volume, image, tmpfs, volumes, mounts, container image, read-only
3.2 Summary
The chapter summary explains that volumes separate container data from image applications by mounting filesystem content, and that access may require security adjustments.
Where this is used later
- Filesystem isolation: SELinux (chapter 10) · Provides later context for SELinux filesystem isolation.
- Storage location (chapter 5) · Understanding where local container storage is located.
- User volumes with the - -userns=auto flag (chapter 10) · Applies user-namespace ownership concepts to user volumes.
- Creating a pod (chapter 4) · Volume mount options.
- System configuration files (chapter 5) · The earlier discussion of Podman reading allocated UID and GID ranges.
- Images contain content owned by multiple user identifiers (UIDs) (chapter 6) · Discusses how user-namespace ownership mappings can affect container volumes.
Concepts explained in this chapter
- volumeA volume is persistent or separately managed storage that can be associated with a container.
- container imageA packaged filesystem and application artifact containing the code, dependencies, and runtime requirements needed to create a container.
These guides are generated from the text of Manning books by Manning's knowledge graph and link to the sections they draw on. The full books are available on liveBook and at manning.com.