Almost every container image is constructed with the requirement that the user within the container be the pre-defined one, which is usually UID=1000.
When the user on the host system is not UID=1000 (almost every corporate system, and many personal ones), it is often still necessary for the calling user's UID to be mapped into the container's namespace as UID 1000 so it matches the permissions and settings the container image was created with (presuming --privileged is also used).
Describe the solution you'd like
Add support for the --uidmap and --gidmap options to the nerdctl run sub-command, matching what ctr and podman already have.
Additional context
The --user option does NOT do this. That option instead changes the user used within the container namespace rather than allowing mapping to an existing one. At best this can be used with --privileged to allow setting which host-system UID to use instead of the one the container image was built and designed for.
What is the problem you're trying to solve
Almost every container image is constructed with the requirement that the user within the container be the pre-defined one, which is usually UID=1000.
When the user on the host system is not UID=1000 (almost every corporate system, and many personal ones), it is often still necessary for the calling user's UID to be mapped into the container's namespace as UID 1000 so it matches the permissions and settings the container image was created with (presuming
--privileged
is also used).Describe the solution you'd like
Add support for the
--uidmap
and--gidmap
options to thenerdctl run
sub-command, matching whatctr
andpodman
already have.Additional context
The
--user
option does NOT do this. That option instead changes the user used within the container namespace rather than allowing mapping to an existing one. At best this can be used with--privileged
to allow setting which host-system UID to use instead of the one the container image was built and designed for.