Learn Podman - Volumes & Mounts

#Introduction

In episode 6 you grouped containers into pods and made them share a network namespace. But there's one thing not yet covered: data. Containers are ephemeral — once removed, their filesystem goes with them. Episode 7 covers how to store and share data with volumes and mounts: named volumes, bind mounts, tmpfs, volume drivers, and the volume rename feature that arrived in Podman 6.1.

#Why Volumes Are Needed

Containers are designed as disposable entities. When podman rm runs, the entire container filesystem layer is deleted along with it. The problem arises when data must outlive the container itself:

• A database whose data must not be lost when the container restarts.
• Application logs that must be archived even after the old container is replaced.
• Configuration files you want to edit without entering the container.

Volumes solve all of this by separating data from the container lifecycle. The data is placed in a location managed by Podman, then mounted into the container filesystem.

#Storage Types in Podman

There are four ways to bring data into a container, each with different characteristics:

The most important difference is the lifecycle. Named volumes are created explicitly and outlive the container; anonymous volumes are created silently and are usually discarded when the container is removed; bind mounts use host files directly; tmpfs never touches the disk at all.

#Named Volume: podman volume create

Named volumes are the most recommended way to handle persistent data. The volume is managed by Podman itself, the storage location is managed by the engine, and you only interact through its name:

podman volume create mydbdata
podman run -d --name db --volume mydbdata:/var/lib/mysql mariadb:latest
podman volume ls

podman volume create mydbdata creates a volume named mydbdata, and --volume mydbdata:/var/lib/mysql mounts it to MariaDB's data directory inside the container. podman volume ls lists the volumes along with their drivers.

The volume management commands you'll use often:

podman volume inspect mydbdata
podman volume prune

podman volume inspect mydbdata shows information like the driver and mountpoint on the host. podman volume prune cleans up volumes no longer used by any container — run it carefully because the data inside is gone with them.

#Bind Mount: Using Host Files Directly

A bind mount places a directory or file from the host directly into the container. The data isn't managed by Podman; the container reads and writes to the host path as-is. It's suitable for placing configuration files, source code during development, or log directories you want to access directly:

podman run -d --name web \
    --mount type=bind,src=/home/budi/app,dst=/usr/share/nginx/html \
    nginx:latest

The --mount syntax uses key=value pairs: type=bind marks it as a bind mount, src points to the source path on the host, and dst points to the destination inside the container. Its short form is the -v flag, familiar to Docker users: -v /home/budi/app:/usr/share/nginx/html. The long --mount form is more explicit and recommended for scripts.

#Syntax Differences: -v and --mount

podman run -v /data:/data and --mount type=bind,src=/data,dst=/data essentially do the same thing; the difference is in the level of control. --mount is also the way to use other mount types, including tmpfs.

#tmpfs: Data in Memory

For truly temporary data — cache, file locks, or secrets in a short session — tmpfs keeps everything in RAM, never touches the disk, and disappears automatically when the container stops:

podman run -d --name cache --mount type=tmpfs,dst=/cache redis:latest

--mount type=tmpfs,dst=/cache creates a temporary filesystem at /cache that only lives while the container runs. No data remains on the disk, making it the right choice for a Redis cache or temporary work directory. Keep in mind that tmpfs uses container memory — the size must be adjusted to the available RAM.

#Volume Drivers

Volumes in Podman are created through a driver, similar to how the storage backend works. The default driver is called local, which stores data at the host's local mountpoint:

podman volume create --driver local backup-vol
podman volume inspect backup-vol

The local driver is enough for almost all daily needs. The container ecosystem provides additional drivers for syncing to remote or cloud targets, and volumes using custom drivers are still treated the same from the CLI side — you don't need to change how you use --volume.

#Rename Volume: New Feature in Podman 6.1

Since Podman 6.1, volumes can be renamed after creation. Previously you had to create a new volume and copy data manually — an error-prone process. Now a single command suffices:

podman volume rename mydbdata dbdata-prod
podman volume ls

podman volume rename mydbdata dbdata-prod renames the volume along with all its contents without moving the data. This is very helpful when a new naming standard is adopted across a team — for example adding an environment suffix — without needing a manual data migration.

#Sharing Volumes Between Containers

Volumes also serve as a data bridge between containers. Two containers mounting the same volume see the same contents, whether both are in one pod or are standalone containers:

podman run -d --name writer --volume shared:/data alpine sleep 3600
podman run -d --name reader --volume shared:/data alpine sleep 3600

Both writer and reader write to shared:/data — changes from one container are immediately visible to the other. This pattern is used for pipelines where one container processes files that another consumes, or for applications that must read logs from a nearby process.

#Closing

Episode 7 covered how data is stored and shared: the difference between anonymous volumes, named volumes, bind mounts, and tmpfs; creating named volumes with podman volume create; bind mounts via --mount type=bind and the short -v form; tmpfs for temporary in-memory data; volume drivers; the podman volume rename feature from 6.1; and the pattern of sharing volumes between containers.

The key points to take home:

• Named volumes are the default choice for persistent data — their lifecycle is independent of the container.
• Bind mounts for data that lives on the host — configuration files and source code.
• tmpfs for temporary data — fast and never touches the disk.
• podman volume prune and podman system reset are two commands that can delete data — use them with caution.

In the next episode, Episode 8, you'll connect containers and pods to each other through networking: the netavark and aardvark-dns stack, per-container DNS, port mapping, and a comparison of bridge, macvlan, ipvlan, and host network types.