I also hoped that it just works and that toolbox sets up the environment in a way that podman/bulidah can be used. I did these steps:   toolbox create fedora   toolbox enter fedora   sudo dnf install buildah podman   buildah from scratch   buildah mount working-container   -> Error: cannot mount using driver overlay in rootless mode. You need to run it in a `buildah unshare` session   podman run fedora   -> fails because /etc/subuid is not setup in the toolbox   sudo usermod --add-subgids 10000-65536 haddorp   sudo usermod --add-subuids 10000-65536 haddorp   podman run fedora   -> fails as newuidmap is not setup   sudo setcap cap_setuid+eip /usr/bin/newuidmap   sudo setcap cap_setgid+eip /usr/bin/newgidmap   podman run fedora   -> ERRO[0000] invalid internal status, try resetting the pause process with "podman system migrate": cannot re-exec process to join the existing user namespace do you have steps that work? thanks, Hendrik On 03.02.2023 22:50, Daniel Walsh wrote:

Hey, On Fri, 2023-02-03 at 18:08 -0500, Daniel Walsh wrote: Currently, Toolbx doesn't set up the container in a way that podman(1) and buildah(1) will just work inside it. However, it's planned as part of an overall desire to make well-known tools, which usually need to run on the host, to work inside containers. Imagine if you were hacking inside a Toolbx container on a Fedora Silverblue host, and you need to use flatpak(1) or rpm-ostree(1) to quickly do something on the host. Remembering which terminal is running a shell on the host and which is inside a container can be annoying in the middle of a frantic hacking run. Similarly, your use- case, where Podman might be part of your hacking workflow. There's some discussion here and an initial implementation here: https://github.com/containers/toolbox/issues/145 https://github.com/containers/toolbox/pull/553 One easy way is to fake it: $ toolbox enter ... ... This trick will work with many other tools: $ toolbox enter ... In fact this is how Toolbx works inside Toolbx containers: $ toolbox enter ... So, you could consider setting up some aliases inside your container to make this more palatable. I must admit that I haven't yet dug into the specifics of podman(1) and buildah(1) inside containers too deeply. I saw that the Containerfile that you linked to has: VOLUME /var/lib/containers VOLUME /home/build/.local/share/containers I haven't played at all with volumes that aren't bind mounts of host paths, but I suppose this is a way to give the container a blank ~/.local/share/containers even if $HOME is a bind mount from the host? Or does it do something else? While Toolbx doesn't really use any namespace other than the user namespace, I wonder if this is enough to have a feature complete podman(1) running inside a container, or will we keep running into corner cases and limitations caused by running inside a container. Another consideration might be if people want to share their containers and images across all their Toolbx containers or not. Cheers, Rishi