podman-container-tools/podman · error

setns NEWUSER: %m

Error message

setns NEWUSER: %m

What it means

After successfully opening /proc/1/ns/user, the fork_exec_ps() child calls setns(fd, CLONE_NEWUSER) to enter the container's user namespace so UID mappings match ps output; failure prints 'setns NEWUSER: %m' and exits 255. Typical errno is EPERM: the caller must be privileged (CAP_SYS_ADMIN) over the target user namespace or share it — and podmanTopInner deliberately sets PR_SET_DUMPABLE=0 and PR_SET_NO_NEW_PRIVS, which makes an unprivileged setns(CLONE_NEWUSER) deny by design (kernel requires dumpable or CAP_SYS_ADMIN). EINVAL/EUSERS occur when mappings are malformed or the ns is not a user namespace.

Source

Thrown at libpod/container_top_linux.c:88

      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);
            }
        }

      /* use execve to unset all env vars, we do not want to leak anything into the container */
      execve (argv[0], argv, NULL);
      fprintf (stderr, "execve: %m");
      exit (special_exit_code);
    }

  r = waitpid (pid, &status, 0);
  if (r < 0)
    {
      fprintf (stderr, "waitpid: %m");
      exit (special_exit_code);
    }
  if (WIFEXITED (status))
    exit (WEXITSTATUS (status));

View on GitHub (pinned to a2409076ef)

Solutions

1. Update podman to a current release — top's userns joining has seen multiple fixes
2. Run 'podman top' as the same user (and userns) that owns the container; for rootful, ensure the process keeps CAP_SYS_ADMIN (not dropped by wrapper/service)
3. Avoid --userns=auto/keep-id for containers you need to 'top', or run top rootful on rootless containers is not supported — use rootless top for rootless containers
4. Check seccomp/LSM is not denying setns for the podman process context

Example fix

# before
sudo podman top myrootlessctr   # helper cannot setns into the container's userns

# after
podman top myrootlessctr          # same user/namespace as the container owner

# Run top as the owner of the container's user namespace
#!/bin/sh
owner=$(podman inspect -f '{{.State.Owner}}' "$ctr" 2>/dev/null) # rootless builds set this
myuid=$(id -u)
ctruid=$(podman inspect -f '{{.State.Pid}}' "$ctr" >/dev/null 2>&1 && \
  stat -c %u "/proc/$(podman inspect -f '{{.State.Pid}}' "$ctr")/ns/user" 2>/dev/null)
[ -z "$ctruid" ] || [ "$ctruid" = "$myuid" ] \
  || echo "warning: container userns owned by uid $ctruid, you are $myuid — top may fail setns" >&2
podman top "$ctr"

When it happens

Trigger: 'podman top' on a container whose user namespace is not the caller's own: rootful podman top on a --userns=auto/keep-id container from a process that lost CAP_SYS_ADMIN over that ns; rootless top where the helper reexec'ed outside the container's userns; nesting levels that drop capabilities; seccomp filtering the setns syscall.

Common situations: Rootless containers with --userns=auto or --userns=keep-id on older podman releases (top/userns joining was fixed over time); podman executed under sudo inside a different userns; capability-dropping wrappers (systemd services with NoNewPrivileges, capsh --drop); custom seccomp profiles denying setns.

Related errors

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

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