Repository navigation
Podman fix: derive --userns=keep-id mapping from the remote user's actual UID/GID #1284
Description
Activity
Hello,
The combination of these PRs allows "defaults" to work for cases where the host UID/GID is abnormally high. This is common when the Linux workstation is using Active Directory for authentication (e.g. via SSSD or FreeIPA). In this case a base value is used to avoid clashing with regular users so UID/GID in the billions is possible.
If you use a regular devcontainer.json and the CLI detects podman, it injects these defaults:
"runArgs": [ "--userns=keep-id", // user has not specified, but CLI injects this for podman ],The problem is that typically in
/etc/login.defusers are allowed to map up 64K IDs:# Extra per user uids SUB_UID_MIN 524288 SUB_UID_MAX 600100000 SUB_UID_COUNT 65536Therefore the above fails because if your host UID is >64K it is out of range inside the container.
In order to use rootless podman in a system that has a high UID/GID (common when the Linux workstation is using Active Directory for authentication, e.g. via SSSD or FreeIPA) you need to specify special flags that address this:
"runArgs": [ "--userns=keep-id:uid=1000,gid=1000", // map to a container user that is within range: <64K ], "updateRemoteUserUID": false, // do not attempt to chown the workspace to match host UID/GID as it fails (out of range >64K)However, making such changes to
devcontainer.jsonwill make it break for other users that have "normal" UID/GID (typically starting at 1000 in most Linux distros).This fix detects this situation for podman and applies the configuration that works:
"runArgs": [ "--userns=keep-id:uid=...,gid=...", // actual values are detected from container settings for remoteUser ], "updateRemoteUserUID": false, // since user is owned by target mapping no need to chown to host UID/GIDTherefore a devcontainer.json that does not specify a
--usernsrun argument and has noupdateRemoteUserUIDcan work for the cases of high UID/GID - existing docker/podman users are unaffected as these defaults only kick in when the UID is unmappable. Therefore a devcontainer.json with defaults will work in all cases.Let me know if you need further clarification.
- changed the title
[-]Feature request: derive `--userns=keep-id` mapping from the remote user's actual UID/GID[/-][+]Podman fix: derive `--userns=keep-id` mapping from the remote user's actual UID/GID[/+]on Sep 11, 2026
The problem
When running a dev container with rootless podman, the Dev Containers CLI injects a plain
--userns=keep-idflag, which maps the host user id to the same UID number inside the container.This breaks for high/out-of-range host UIDs (e.g. AD/SSSD users which have values like
1400601154, which are not valid inside the container (they are out of range as the containers are typically given a 0-65535 range via subuid/subgid mapping). As a result the mapping fails silently and the container'svscodeuser remains at UID 1000, not matching the host user, and causingPermission deniedon the workspace bind mount).Current workaround
The current workaround is a fragile manual
runArgsentry (--userns=keep-id:uid=1000,gid=1000). Since the host UID is unmappable to itself, we keep the 1000 id inside the container and map the host user to that. This allows one to use podman on Linux boxes with AD and thus high uid/gid combinations, as it removes the requirement for the exact host UID to be inside the container's range.The request for improvement
Instead of injecting a plain
--userns=keep-id, the CLI should resolve theremoteUser's actual UID/GID in the image and emit--userns=keep-id:uid=<remote-uid>,gid=<remote-gid>. This fixes the high-UID case with no regressions: when the host UID already equals the container user's UID,keep-id:uid=X,gid=Xproduces the identical mapping to plainkeep-id, so existing setups are unaffected.