podman-container-tools/podman · error

mount proc: %m

Error message

mount proc: %m

What it means

In the child of fork_exec_ps(), mount("proc", "/proc", "proc", 0, NULL) failed before exec'ing ps. 'podman top' reexecs itself into a new mount+pid namespace (podmanTopInner) and the C child mounts a fresh procfs for the container's PID namespace; %m is strerror(errno), typically EPERM/EACCES (missing CAP_SYS_ADMIN, seccomp or LSM blocking mount(2)) or EINVAL on odd kernel configurations. Failure exits 255 (special_exit_code).

Source

Thrown at libpod/container_top_linux.c:73

  if (argv == NULL)
    {
      fprintf (stderr, "argv not initialized");
      exit (special_exit_code);
    }

  pid = fork ();
  if (pid < 0)
    {
      fprintf (stderr, "fork: %m");
      exit (special_exit_code);
    }
  if (pid == 0)
    {
      r = mount ("proc", "/proc", "proc", 0, NULL);
      if (r < 0)
        {
          fprintf (stderr, "mount proc: %m");
          exit (special_exit_code);
        }
      if (join_userns)
        {
          // join the userns to make sure uid mapping match
          // we are already part of the pidns so so pid 1 is the main container process
          r = open ("/proc/1/ns/user", O_CLOEXEC | O_RDONLY);
          if (r < 0)
            {
              fprintf (stderr, "open /proc/1/ns/user: %m");
              exit (special_exit_code);
            }
          if ((status = setns (r, CLONE_NEWUSER)) < 0)
            {
              fprintf (stderr, "setns NEWUSER: %m");
              exit (special_exit_code);
            }
        }

View on GitHub (pinned to a2409076ef)

Solutions

1. If podman itself runs inside a container/sandbox, give it the needed privilege (--privileged or cap_add SYS_ADMIN) or run podman on the host
2. Restore the default seccomp profile or add 'mount' to allowed syscalls for the podman process context
3. For rootless: verify newuidmap/newgidmap are installed and /etc/subuid, /etc/subgid have entries for the user
4. Update podman — top namespace handling has been hardened over releases; check 'podman info' and report with it if persistent

Example fix

# before (podman nested inside a locked-down CI container)
podman top inner-ctr

# after (run the inner engine with mount privileges)
podman run --cap-add SYS_ADMIN quay.io/podman/stable podman top inner-ctr

# Can this context mount a fresh procfs? Verify before relying on podman top
#!/bin/sh
if podman info --format '{{.Host.Security.Rootless}}' | grep -q true; then
  # rootless: userns bootstrap must work (newuidmap/newgidmap present)
  command -v newuidmap >/dev/null && command -v newgidmap >/dev/null \
    || { echo 'rootless requires newuidmap/newgidmap' >&2; exit 1; }
  grep -q "^$USER:" /etc/subuid 2>/dev/null \
    || { echo "no /etc/subuid entry for $USER" >&2; exit 1; }
fi
# quick capability probe for the mount(2) podman top needs
unshare -m sh -c 'mount -t proc proc /proc' >/dev/null 2>&1 \
  || { echo 'this context cannot mount proc (missing CAP_SYS_ADMIN or seccomp)' >&2; exit 1; }

When it happens

Trigger: 'podman top' on a container when the reexec'ed helper lacks privilege to mount proc: rootless podman without a working user namespace, podman running under a restrictive seccomp/AppArmor/SELinux profile that denies mount, container-in-container (Docker-in-Podman) where inner podman top's mount is blocked, or hardened kernels (lockdown) refusing new procfs mounts.

Common situations: Running podman inside an unprivileged sandbox/CI container without CAP_SYS_ADMIN; custom seccomp profiles in /etc/containers/seccomp.json that block the mount syscall; rootless setups where newuidmap/newgidmap are missing so the userns bootstrap is incomplete; very old kernels.

Related errors

• setns NEWUSER: %m
• failed to allocate ps argv
• fork: %m
• open /proc/1/ns/user: %m
• execve: %m

AI-assisted analysis of podman-container-tools/podman@a2409076ef (2026-08-15). Data as JSON: /api/errors/a66fabbdf13f4927. Report an issue: GitHub.