Skip to content

nested-podman-socket

Recipe card from the charly-distros plugin (Images — the deployable catalog).

nested-podman-socket — the nested podman’s API socket

Section titled “nested-podman-socket — the nested podman’s API socket”

Composes container-nesting (/charly-distros:container-nesting) and serves that nested rootless podman as an API socket at unix:///run/user/1000/podman/podman.sock.

container-nesting supplies nested podman; this candy supplies its SOCKET. A nesting box that only builds and runs containers itself needs no API endpoint, and starting a podman service in every such box would be scope it did not ask for. Anything driven from OUTSIDE the container needs exactly that endpoint — charly box load (/charly-build:load) delivering images in, or an in-pod controller spawning its own containers.

The socket’s store IS the container’s rootless store, which is the whole point: containers spawned through it stay inside the candybox instead of landing in the host store beside everything else.

The runtime-dir named volume is load-bearing

Section titled “The runtime-dir named volume is load-bearing”

/run is a fresh ROOT-OWNED tmpfs at container start. A build-time mkdir /run/user/1000 therefore does not survive into the running container, and the uid-1000 service cannot create its own runtime dir under a root-owned /run/user. The candy declares a NAMED VOLUME at /run/user/1000: podman copy-up populates an empty named volume from the image’s content at that path, ownership preserved, so the container starts with the uid-1000-owned directory seeded at build time.

A tmpfs is NOT an alternative, and this is measured rather than argued: podman’s --tmpfs rejects uid=/gid= (unknown mount option "uid=1000"), so a tmpfs at this path can only ever be root-owned.

The seed chowns the WHOLE directory, not just its podman/ subdirectory — the nested podman writes its libpod runtime dir alongside, and seeding only the subdirectory leaves the service unable to start. The candy’s build-context check asserts the PARENT’s owner for exactly that reason.

The candy’s own plan asserts the socket exists, answers, and reports a graph root inside the container’s rootless store — the last of which is what would fail if the socket were ever wired to a store outside the candybox. check-boxload-pod exercises the whole arrangement end to end.