--userns=ns:<path> appears to be broken for rootless podman

[bpoldrack]

Issue Description

When using --userns=ns:<path> with (rootless) podman-run referring to an already existing user namespace (underneath podman unshare), I get an error claiming that both, a path and a mapping was specified:

Error: OCI runtime error: runc: runc create failed: user namespaces enabled, but both namespace path and non-matching mapping specified -- you may only provide one

I don't specify a UID mapping in addition, though. It seems that the OCI spec generated by podman contains a default UID mapping despite this option being given.
If I run podman-create instead of podman-run and then a podman-inspect on that container, I do see something like this:

...
"UsernsMode": "ns:/proc/284016/ns/user",
"IDMappings": {
    "UidMap": [
         "0:0:1"
    ],
    "GidMap": [
         "0:0:1"
    ]
},
...

What seems strange to me, is that this looks like the --userns=ns: mode can actually never work if that mapping is generated unconditionally.
I couldn't find any issue, release note or troubleshooting entry that seems related. I might be missing something about this --userns mode, but I can't find anything about it other than its description in the manpage, that suggests it's supposed to work exactly like the respective option for joining an existing network namespace.

Steps to reproduce the issue

Steps to reproduce the issue
1.

# get rootless user namespace
> podman unshare

# get a new user namespace underneath 
> unshare --user --map-users 0:0:1 --map-users 1:1:1024 --map-groups 0:0:1 --map-groups 1:1:1024

# get PID 
> echo $$
284016

In a different terminal:

> podman run --userns=ns:/proc/284016/ns/user --rm -it docker.io/library/debian:latest
Error: OCI runtime error: runc: runc create failed: user namespaces enabled, but both namespace path and non-matching mapping specified -- you may only provide one

Describe the results you received

An error suggesting a UID mapping was specified in addition to a namespace path, when no such mapping was specified by the user.

Describe the results you expected

The container to run in the given user namespace.

podman info output

host:
  arch: amd64
  buildahVersion: 1.39.3
  cgroupControllers:
  - cpu
  - memory
  - pids
  cgroupManager: systemd
  cgroupVersion: v2
  conmon:
    package: conmon_2.1.13+ds1-1_amd64
    path: /usr/bin/conmon
    version: 'conmon version 2.1.13, commit: unknown'
  cpuUtilization:
    idlePercent: 90.35
    systemPercent: 1.77
    userPercent: 7.88
  cpus: 8
  databaseBackend: sqlite
  distribution:
    codename: forky
    distribution: debian
    version: unknown
  eventLogger: journald
  freeLocks: 2041
  hostname: tree
  idMappings:
    gidmap:
    - container_id: 0
      host_id: 1000
      size: 1
    - container_id: 1
      host_id: 100000
      size: 65536
    uidmap:
    - container_id: 0
      host_id: 1000
      size: 1
    - container_id: 1
      host_id: 100000
      size: 65536
  kernel: 6.16.3+deb14-amd64
  linkmode: dynamic
  logDriver: journald
  memFree: 448475136
  memTotal: 16401018880
  networkBackend: netavark
  networkBackendInfo:
    backend: netavark
    dns:
      package: aardvark-dns_1.16.0-1_amd64
      path: /usr/lib/podman/aardvark-dns
      version: aardvark-dns 1.16.0
    package: netavark_1.16.1-2_amd64
    path: /usr/lib/podman/netavark
    version: netavark 1.16.1
  ociRuntime:
    name: runc
    package: runc_1.1.15+ds1-2+b4_amd64
    path: /usr/bin/runc
    version: |-
      runc version 1.1.15+ds1
      commit: 1.1.15+ds1-2+b4
      spec: 1.2.0
      go: go1.24.4
      libseccomp: 2.6.0
  os: linux
  pasta:
    executable: /usr/bin/pasta
    package: passt_0.0~git20250503.587980c-2_amd64
    version: ""
  remoteSocket:
    exists: true
    path: /run/user/1000/podman/podman.sock
  rootlessNetworkCmd: pasta
  security:
    apparmorEnabled: false
    capabilities: CAP_CHOWN,CAP_DAC_OVERRIDE,CAP_FOWNER,CAP_FSETID,CAP_KILL,CAP_NET_BIND_SERVICE,CAP_SETFCAP,CAP_SETGID,CAP_SETPCAP,CAP_SETUID,CAP_SYS_CHROOT
    rootless: true
    seccompEnabled: true
    seccompProfilePath: /usr/share/containers/seccomp.json
    selinuxEnabled: false
  serviceIsRemote: false
  slirp4netns:
    executable: /usr/bin/slirp4netns
    package: slirp4netns_1.2.1-1.1_amd64
    version: |-
      slirp4netns version 1.2.1
      commit: 09e31e92fa3d2a1d3ca261adaeb012c8d75a8194
      libslirp: 4.9.1
      SLIRP_CONFIG_VERSION_MAX: 5
      libseccomp: 2.6.0
  swapFree: 15569956864
  swapTotal: 15997071360
  uptime: 360h 5m 3.00s (Approximately 15.00 days)
  variant: ""
plugins:
  authorization: null
  log:
  - k8s-file
  - none
  - passthrough
  - journald
  network:
  - bridge
  - macvlan
  - ipvlan
  volume:
  - local
registries: {}
store:
  configFile: /home/ben/.config/containers/storage.conf
  containerStore:
    number: 3
    paused: 0
    running: 0
    stopped: 3
  graphDriverName: overlay
  graphOptions: {}
  graphRoot: /home/ben/.local/share/containers/storage
  graphRootAllocated: 486171246592
  graphRootUsed: 128404692992
  graphStatus:
    Backing Filesystem: extfs
    Native Overlay Diff: "true"
    Supports d_type: "true"
    Supports shifting: "false"
    Supports volatile: "true"
    Using metacopy: "false"
  imageCopyTmpDir: /var/tmp
  imageStore:
    number: 6
  runRoot: /run/user/1000/containers
  transientStore: false
  volumePath: /home/ben/.local/share/containers/storage/volumes
version:
  APIVersion: 5.4.2
  BuildOrigin: Debian
  Built: 1753478586
  BuiltTime: Fri Jul 25 23:23:06 2025
  GitCommit: ""
  GoVersion: go1.24.4
  Os: linux
  OsArch: linux/amd64
  Version: 5.4.2

Podman in a container

No

Privileged Or Rootless

Rootless

Upstream Latest Release

No

Additional environment details

No response

Additional information

No response

[Honny1]

I attempted to reproduce this on Fedora 42 using Podman v5.7.0-dev from the podman-next repository, but I was unable to.

@bpoldrack Could you please try to reproduce it on your machine with the latest version of Podman?

[github-actions]

A reviewer has determined we need more information to understand the reported issue. A comment on what is missing should be provided. Be certain you:

• provide an exact reproducer where possible
• verify you have provided all relevant information - minimum is podman info
• answer any follow up questions

If no response to the needs-info is provided in 30 days, this issue may be closed by our stale bot.

For more information on reporting issues on this repository, consult our issue guide.

[bpoldrack]

@Honny1 The newest available version on debian is 5.6.1. Tried that with the exact same result.

[bpoldrack]

While I'm not really familiar with this code base or even just Go, I do want to point out, that this looks like it's adding a mapping on purpose: https://github.com/containers/podman/blame/ef584d4d6d5b50d7eb48a785be6c954bb0abe5c6/pkg/specgen/namespaces.go#L506

Not touched in 4 years, though. To me the behavior I get looks like runc's complaint is now kind of the other way around.
So, may be the trouble is a behavior change in runc since then.

Edit:

Guess, I found it. Here is the change that seems to make the workaround above obsolete:
https://github.com/opencontainers/runc/pull/4124/files
Respective doc change is still an open PR, though:
opencontainers/runtime-spec#1237

[Honny1]

Ah, good investigation. Did you try it with crun?

[bpoldrack]

@Honny1 I did not. For what I'm building that wouldn't help, b/c I'm not in control of the infrastructure this is supposed to run on. That's why it's all rootless as well.
However, I guess you can take it from here?