Diagnosing and Fixing Rootless Podman Start Failures Due to Cgroup v2 Misconfiguration

Problem Statement

Rootless Podman attempts to start a container and immediately prints:

podman run alpine
cannot open /proc/self/cgroup: Permission denied

This error is almost always caused by the host not exposing a unified cgroup v2 hierarchy. Rootless runtimes rely on cgroup v2; if the kernel is running cgroup v1 or a mixed hierarchy, the process cannot read its own cgroup information and aborts.

Common Symptoms

• Command line output: cannot open /proc/self/cgroup: Permission denied
• Podman exits with exit code 1 on every container run.
• Systemd services that spawn Podman containers fail during boot.

Diagnostic Table

Check	Expected Result	What It Means
cgroup hierarchy type	all subsystems show ‘1’ in /proc/cgroups	cgroup v1 active – rootless Podman cannot run.
cgroup v2 mount	mount point for cgroup2 exists	unified hierarchy present – proceed.
kernel boot param	systemd.unified_cgroup_hierarchy=1 or no cgroup_no_v1	kernel configured for cgroup v2.
user namespace support	kernel version ≥ 4.8 or uname -r shows support	rootless mode can operate.

Step‑by‑Step Checks

1. Verify the cgroup hierarchy type

   # cat /proc/cgroups
   #   subsystem   hierarchy  num_cgroups  enabled
   #   cpu          1          0           1
   #   cpuacct      1          0           1
   #   ...
   

   If every subsystem shows a hierarchy of 1, the system is still on cgroup v1. In that case, proceed to enable cgroup v2.

2. Check for the unified mount

   # mount | grep cgroup2
   cgroup2 on /sys/fs/cgroup/unified type cgroup2 (rw,nosuid,nodev,noexec,relatime)
   

   Absence of a cgroup2 mount confirms the hierarchy is missing.

3. Inspect kernel boot parameters

   # cat /proc/cmdline
   linux ... systemd.unified_cgroup_hierarchy=1 ...
   

   Look for systemd.unified_cgroup_hierarchy=1 or the negation cgroup_no_v1. If neither is present, the kernel was not instructed to expose cgroup v2.

4. Confirm user namespace support

   # uname -r
   5.15.0-46-generic
   

   Kernel versions before 4.8 lack the necessary user namespace features for rootless Podman.

5. Test container start after enabling cgroup v2

   # podman run --rm alpine true
   

   If the command exits with status 0, the issue is resolved.

Fixes by Finding

• cgroup v1 active: Edit the bootloader configuration (e.g., /etc/default/grub) to add systemd.unified_cgroup_hierarchy=1 to GRUB_CMDLINE_LINUX_DEFAULT. Run update-grub and reboot.
• cgroup v2 missing mount: After reboot, run mount -t cgroup2 none /sys/fs/cgroup/unified to create the mount point. Persist the mount by adding a cgroup2 entry to /etc/fstab.
• Kernel too old for user namespaces: Upgrade the kernel to at least 4.8 or use a distribution that ships a newer kernel.
• Systemd unit files using cgroup v1: If you use systemd to launch containers, adjust unit files to use Delegate=yes and Slice=system.slice to allow delegation into the unified hierarchy.

Escalation Criteria

If after applying the above fixes Podman still fails:

• Run journalctl -u podman for detailed logs.
• Verify that /proc/self/cgroup is readable by the user: cat /proc/self/cgroup should succeed.
• Check for SELinux or AppArmor policies that may block access to /proc entries.
• If the system hosts critical services that rely on cgroup v1, consider a staged rollout or use systemd.unified_cgroup_hierarchy=0 for those services while keeping rootless Podman on a separate node.

Quick Reference

• cat /proc/cgroups – view hierarchy type.
• mount | grep cgroup2 – confirm unified mount.
• cat /proc/cmdline – check boot parameter.
• podman run --rm alpine true – test container start.

Follow the diagnostics in order; most rootless Podman start failures due to cgroup misconfiguration resolve after enabling the unified hierarchy and rebooting.