Persistent storage and containers as systemd services

Keeping data outside the container

A container's writable layer is thrown away when the container is removed. A database or upload folder must live on the host. A bind mount maps a host directory into the container: -v /srv/web:/var/www/html. Podman also has named volumes (podman volume create), stored under the user's container storage; bind mounts are easier to back up and inspect.

SELinux and the :Z option

Container processes run with the SELinux type container_t, which may only use files labelled for containers (container_file_t). A normal host directory has another label, so the container gets "Permission denied". Adding :Z to the volume tells Podman to relabel the directory privately for this container. Lower-case :z labels it so several containers can share it.

$ mkdir -p ~/web-content
$ echo "Namaste from the host" > ~/web-content/index.html
$ podman run -d --name web -p 8080:8080 -v ~/web-content:/var/www/html:Z registry.access.redhat.com/ubi9/httpd-24
$ ls -Zd ~/web-content
system_u:object_r:container_file_t:s0:c215,c840 /home/asha/web-content
$ curl localhost:8080
Namaste from the host

Rootless containers map user IDs: root inside the container is your own UID outside, and other IDs inside map to a private range from /etc/subuid. If an image runs as a non-root user, files it writes on the host may show a high UID number. podman unshare chown UID:GID dir changes ownership as the container sees it.

Starting a container at boot: Quadlet

A container started by hand does not come back after a reboot. The modern RHEL 9 way (Podman 4.4 and later) is Quadlet: you write a small .container file, and systemd generates a service from it. For a rootless container the file goes in ~/.config/containers/systemd/; for a root container, in /etc/containers/systemd/.

# ~/.config/containers/systemd/web.container
[Unit]
Description=Company website container

[Container]
Image=registry.access.redhat.com/ubi9/httpd-24
ContainerName=web
PublishPort=8080:8080
Volume=%h/web-content:/var/www/html:Z

[Install]
WantedBy=default.target

$ systemctl --user daemon-reload          # Quadlet generates web.service
$ systemctl --user start web.service
$ systemctl --user status web.service --no-pager | head -3
● web.service - Company website container
     Loaded: loaded (/home/asha/.config/containers/systemd/web.container; generated)
     Active: active (running) since Mon 2026-10-19 18:02:11 IST; 4s ago
$ loginctl enable-linger asha              # start asha's services at boot, without a login
$ loginctl show-user asha | grep Linger
Linger=yes

The older way: podman generate systemd

Earlier RHEL 9 releases, and many exam guides, use podman generate systemd --name web --files --new to write a unit file from an existing container, then copy it to ~/.config/systemd/user/ and run systemctl --user enable --now container-web.service. This still works but is deprecated in favour of Quadlet. Check the current exam objectives and use whatever method they expect; both give a systemd user service plus enable-linger.

Common mistakes

• Using su - asha and then systemctl --user: it fails with "Failed to connect to bus". Log in as the user over SSH (or a real login) so the user's systemd and XDG_RUNTIME_DIR exist.
• Forgetting loginctl enable-linger: the container starts when the user logs in and stops when they log out, not at boot.
• Leaving out :Z and getting Permission denied, or using it on a shared system directory.
• Editing the .container file and forgetting systemctl --user daemon-reload.