Installing Podman as a Rootless Container Engine
Podman is an OCI-compatible container engine that runs containers without a continuously running daemon. In rootless mode, a regular Linux user starts containers through user namespaces, while the container’s root maps to an unprivileged host identity. This suits development, CI jobs and small production services where granting an application sudo access is unnecessary.
The guide targets RHEL, CentOS Stream and Fedora, distributions commonly encountered by Australian administrators in Melbourne, Sydney, Brisbane and Canberra. These commands also suit compatible enterprise Linux hosts. Rootless Podman is practical for teams working from home offices and connecting to shared infrastructure across Australian states.
Rootless does not mean harmless. Images can contain vulnerable software, and workloads can still consume CPU, memory or storage. Combine rootless execution with image updates, resource limits and restricted mounts. The reduced privilege footprint also supports least-privilege design where Australian privacy duties apply, including the federal Privacy Act 1988 and New South Wales’ PPIP Act 1998.
Comparing rootless Podman with traditional Docker
Podman and a traditional Docker installation can both work with OCI images, but their defaults differ. This comparison covers rootless Podman and a rootful Docker daemon.
| Feature | Rootless Podman | Traditional Docker |
|---|---|---|
| Privilege | Ordinary user by default | Daemon runs as root |
| Service | No persistent daemon required | Daemon usually required |
| Command-line | Podman commands and Docker-style aliases | Docker client talks to a daemon |
| Storage | Per-user by default | Usually system-wide |
| System integration | User-level systemd and Quadlet | System-level service |
Choose according to the operating model, not command similarity. Podman keeps images under the invoking user’s account by default, so two administrators on one server do not automatically share the same cache or containers.
Installing Podman on RHEL-family systems
On RHEL 8 or 9, CentOS Stream 9 and current Fedora releases, install the packaged engine:
sudo dnf install -y podman
Use sudo for installation only. Running sudo podman creates root-owned images and defeats the purpose of a rootless workflow.
Verify the installed version and active mode as your normal user:
podman --version
podman info --format '{{.Host.Security.Rootless}}'
The second command should print true. Check /etc/subuid and /etc/subgid as well: the package normally prepares a subordinate range for your account, and missing entries can break user mapping. Hosts that restrict user.max_user_namespaces need an administrator to review that setting. Readers comparing container engines can consult container tooling resources for a wider ecosystem view.
Running and inspecting containers
Run Podman’s small demonstration image as an ordinary user:
podman run --rm -it quay.io/podman/hello
It prints a confirmation and exits, removing the container automatically. No engine daemon needs to be started first, and no sudo is required.
For regular work, inspect resources with podman images and podman ps -a, and read output with podman logs CONTAINER. Remove stopped containers with podman rm CONTAINER and unused images with podman rmi IMAGE. These commands affect the current user’s storage unless rootful operation is deliberately requested.
Australian teams sharing a development host benefit from separate user accounts because images and container state stay separate. This limits accidental interference, but rootless containers still need patched software, resource limits and restricted access.
Managing storage and remote data
Use named volumes for data that must outlive a container:
podman volume create app-data
podman run --rm -v app-data:/data docker.io/library/alpine:latest ls -la /data
The volume belongs to your user account and remains after the container exits.
Bind mounts suit configuration files, but expose host paths directly. Mount a narrow directory rather than /home/$USER, /etc or the entire filesystem. Rootless mappings translate container UIDs, so host files must be accessible to the mapped user and group. SELinux hosts may also require correctly labelled paths.
Organisations with shared data on an existing server can follow NFS share configuration before connecting that export to Podman. Check ownership, export permissions and root-squash behaviour: a rootless container does not automatically gain access to a root-owned share.
Running containers as managed services
Long-running containers need supervision, and a user-level systemd service provides automatic restarts. The daemon-reload, enable and start operations are explained in systemctl service controls. On hosts supporting Quadlet, define the container as a user unit instead of maintaining a separate startup script.
Create ~/.config/containers/systemd/local-web.container:
[Unit]
Description=Local test web server
[Container]
Image=quay.io/nginx/nginx-unprivileged:latest
ContainerName=local-web
PublishPort=8080:8080
[Service]
Restart=on-failure
Environment=PODMAN_SYSTEMD_UNIT=%n
[Install]
WantedBy=default.target
Load and activate the generated unit:
systemctl --user daemon-reload
systemctl --user enable --now local-web.service
Use journalctl --user -u local-web.service for logs. To keep the service running after logout, an administrator can enable lingering with sudo loginctl enable-linger YOUR_USERNAME.
This fits Australian small businesses and regional offices that need reliable workloads without granting applications root access to a VPS or on-premises server. The point to remember is simple: install Podman as a normal user, keep routine workloads unprivileged and express persistent services through explicit user-level units. Rootless Podman provides predictable lifecycle management with a smaller privilege footprint, while patching, backups and monitoring remain essential.