Podman-in-podman without privileged and with host mounts

[remingtonc]

I'd love to run podman-in-podman, but I also want to seamlessly share a host mount from the user.

This is possible with rootless-in-rootless, but necessitates very long (30+ minute) container starts on first run with UID/GID remapping/chown. e.g.

podman run -it --user podman --uidmap "+1000:@$(id -u):1" --gidmap "+1000:@$(id -g):1" --security-opt=disable --device /dev/fuse --mount type=bind,src=.,target=/home/podman/user_share quay.io/podman/stable:latest

(or similarly doing --userns=keep-id,uid=1000,gid=1000)
(I am notably using an image built on top of quay.io/podman/stable which is much larger/many more files.)
Similar to #16541

Running rootful-in-rootless seemed like the next acceptable step in my case - easy UID mapping and no issues with the file access! However it seems to necessitate --privileged or else root fails to run containers. e.g.

podman run alpine echo hello
...
Error: crun: mount `proc` to `proc`: Operation not permitted: OCI permission denied

I'd prefer to not assign privileged, but is a concession which seems necessary currently.

It may well be that the podman image config I'm relying on simply is not configured for rootful-in-rootless and it's an easy fix. https://github.com/containers/image_build/tree/main/podman

I haven't figured out an ideal solution here between 1) need podman-in-podman, 2) don't necessarily want it to be a privileged container, 3) need to share host directory to container seamlessly.

Is there a configuration to make root podman invocations behave more like rootless to enable root-run containers for rootful-in-rootless podman?

[manimovassagh]

The rootful-in-rootless approach is the right direction for your use case, and you can avoid --privileged by granting just the specific capabilities and devices the inner Podman needs.

Rootful-in-rootless without --privileged

The proc mount error happens because the container lacks CAP_SYS_ADMIN in its user namespace. Instead of --privileged (which grants everything), you can add only what is needed:

podman run -it \
  --cap-add=SYS_ADMIN,MKNOD,NET_ADMIN,SETUID,SETGID \
  --security-opt label=disable \
  --security-opt seccomp=unconfined \
  --device /dev/fuse \
  --mount type=bind,src=.,target=/home/podman/user_share \
  quay.io/podman/stable:latest

Breaking this down:

• SYS_ADMIN -- needed for mounting proc/sysfs/overlayfs inside the inner container
• MKNOD -- needed for device node creation
• NET_ADMIN -- needed for network namespace setup (slirp4netns/pasta)
• SETUID/SETGID -- needed for user namespace UID/GID mapping
• seccomp=unconfined -- the default seccomp profile blocks some syscalls that inner Podman needs (mount, pivot_root, etc.)
• label=disable -- disables SELinux label confinement which blocks inner container operations

This is significantly more restricted than --privileged, which also gives access to all host devices, disables all namespace isolation, etc.

Alternative: use --userns=keep-id with a tmpfs overlay for the slow chown

If the 30-minute startup is your main pain point with rootless-in-rootless, the slow part is the initial chown of files in the bind mount. You can work around this by mounting the shared directory with the right ownership from the start:

podman run -it \
  --user podman \
  --userns=keep-id:uid=1000,gid=1000 \
  --security-opt label=disable \
  --device /dev/fuse \
  --mount type=bind,src=.,target=/home/podman/user_share \
  --storage-opt overlay.mount_program=/usr/bin/fuse-overlayfs \
  quay.io/podman/stable:latest

The key insight: --userns=keep-id maps your host UID to the target UID inside the container, so the bind-mounted files appear owned by the right user without any chown. The 30-minute delay you experienced likely comes from the container image layers being re-chowned, not the bind mount. If you use fuse-overlayfs as the storage driver (which the quay.io/podman/stable image already does), the layer chown should be much faster.

TL;DR

For production use, go with rootful-in-rootless + the explicit capabilities listed above. For development, rootless-in-rootless with keep-id and fuse-overlayfs is cleaner but might still have a first-run penalty on very large images.

[remingtonc]

Thanks for the reply, but AI-generated responses are not what I seek here. I have similarly used AI to troubleshoot this issue and am hoping for a more authoritative discussion on strategies.