Running Podman Containers Without Root: A Practical Guide

Problem: You need containers but lack sudo access

Many developers and sysadmins work on shared machines where they cannot obtain root privileges. Installing Docker or running privileged containers often fails because the daemon requires root. Podman offers a rootless mode that lets you create and manage containers using only your regular user account, provided the underlying kernel supports the necessary isolation features.

Thesis: Podman’s rootless mode works automatically when the kernel provides user namespaces and cgroups v2

If you are not root and the kernel has USER_NS enabled (typically Linux 5.0+), Podman detects the capability and runs containers in a separate user namespace. This gives you most of the functionality of rootful containers while keeping the attack surface limited to your user ID.

Section 1: Verify that your system supports rootless mode

Run the following command as your regular user (no sudo needed). It queries Podman’s internal host information and prints the rootless flag.

podman info --format '{{.Host.Rootless}}'

Expected output: true. If you see false or an error, the kernel may be missing user namespace support or cgroups v2.

You can also check the kernel configuration directly:

grep -E 'USER_NS|CGROUPS' /boot/config-$(uname -r)

Look for lines like CONFIG_USER_NS=y and CONFIG_CGROUPS=y. If either is missing, rootless containers will not start.

Section 2: Run a simple rootless container

With rootless mode confirmed, launch a test container. This command pulls the Alpine image (if not present) and runs an echo command inside the container.

podman run --rm alpine echo 'rootless works'

No sudo is required. The command should complete quickly and print the message. If it fails, note the error; common causes are missing kernel features or insufficient uid/gid ranges in /etc/subuid and /etc/subgid.

Section 3: Confirm that the container is isolated via user namespaces

After the container runs, you can inspect its namespace IDs to see that they differ from the host’s.

podman run --rm alpine sh -c 'cat /proc/$$/ns/user'

Compare the output with the host’s namespace (run the same command on the host). The numbers should be different, indicating a separate user namespace.

Alternatively, examine the container’s namespace mode via inspect:

podman inspect --format '{{.HostConfig.NamespaceMode}}' 

For rootless containers this typically returns private.

Trade‑offs and limitations

• Privileged ports: Binding to ports below 1024 is blocked unless you add the container capability CAP_NET_BIND_SERVICE or use --port with a host port above 1024.
• Device access: Devices like /dev/fuse are not available by default; you must grant them with --device or adjust /etc/subuid//etc/subgid mappings.
• Image ownership: Some images assume root ownership of files inside the image. When run rootlessly, those files may appear owned by an unprivileged UID, causing permission errors. Mitigate by rebuilding the image with a non‑root user or mounting a volume with appropriate ownership.
• Kernel version: Older distributions (e.g., RHEL 6, Ubuntu 14.04) lack the needed namespace features and will refuse to start rootless containers.

You can test the privileged‑port limitation yourself:

podman run --rm -p 80:80 alpine nc -l 80

Expect an error similar to "permission denied" unless you add --cap-add=CAP_NET_BIND_SERVICE.

Actionable closing: Get started with rootless Podman today

1. Ensure you are logged in as a non‑root user.
2. Run podman info --format '{{.Host.Rootless}}' to confirm rootless support.
3. If the check fails, upgrade your kernel to version 5.0 or newer and verify CONFIG_USER_NS and CONFIG_CGROUPS are set.
4. Run a test container with podman run --rm alpine echo 'hello' to see it work.
5. For workloads that need low ports or special devices, add the appropriate capabilities or device flags, remembering that these require explicit user approval.

By following these steps you can run containers securely on any Linux workstation where you lack sudo, while still benefiting from Podman’s OCI‑compatible image format and CLI.