podman

Podman as a devcontainers engine doesn't currently work rootlessly (the default) if you use devcontainer features [1] or (and this sounds like you're issue) if you use WSL2. I haven't submitted the WSL2 issue to the Podman team yet. If you get to it before I do, can you link it here? I've worked around the features bug by just using `devbox generate devcontainer` then adding all my desired container apps and services inside a `devbox.json` file. [1] https://github.com/containers/podman/issues/18691#issuecomme...

looks like this issue: https://github.com/containers/podman/issues/20639

https://github.com/containers/podman/issues/20081 https://github.com/containers/podman/issues/20428 https://github.com/containers/podman/issues/20462 https://github.com/containers/podman/issues/19611

Yes. https://github.com/containers/podman/blob/3e8f19be9d84548039... https://github.com/containers/podman/blob/3e8f19be9d84548039...

Podman installs a systemd generator that automatically transforms the name.container files shown in the article into ordinary systemd user service units[1][2][3], so loginctl enable-linger USER (run once, as root) should cause USER's podmansh container to start as soon as the system enters multi-user mode, independent of USER's login sessions, allowing persistent daemons, including those necessary for job scheduling, namely… Ordinarily, users can create systemd timer units[4] to schedule at- and cron-style jobs; I assume you need to run a systemd instance inside each user's podmansh container to allow users to create systemd units in the present containerized context (running systemd inside a container is explicitly supported by podman[5]). If your users don't like systemd, you can also run traditional atd/crond daemons in user conta

I had the same experience for a while, and was a little bitter about repeatedly taking them at their word that you could transparently `alias docker=podman`, even when Podman 4.0 didn't even support volume mounts from the host without jumping through hoops. I suggested that the team document or at least label compatibility issues so users are informed about them, but they rejected the idea[0], recommending instead that users keep abreast of changes to a 35 page troubleshooting file. That said, I've been living on it full time for a few months, and it's working well. I'm using the Docker CLI with Podman providing the backend implementation. Biggest caveats: Mounting volumes from the host is still a little limited. It doesn't play nice with giving docker.sock back to Docker Engine (wontfix[1]). The --platform flag was broken but should be f

While rootless containers are suitable for user-managed containers on a system, for server-based container deployments, utilizing the "--userns=auto" option provides a more secure solution in Podman. In Podman, when running containers in a non-privileged environment (rootless), they operate within the same user namespace, potentially leading to attacks between containers. However, running the containers as root (rootful) with the "--userns auto" flag, Podman ensures isolation within distinct user namespaces, thereby enhancing security.

It's this issue; people ran into it since early 2022. I haven't tracked it down in the Ubuntu issues yet, but basically the same thing fails on today's AMIs. https://github.com/containers/podman/issues/13341 The fix is fairly trivial - if you don't care about apparmor you can disable it. If you do, the usual new policy from the complain log is enough.

Restart support was added using `podman-restart` https://github.com/containers/podman/issues/17580 Buildkit needs a full API implementation https://github.com/containers/podman/issues/13889/ https://github.com/containers/podman/issues/11780

Hmmm, pasta seems to solve all rootless networking issues... https://github.com/containers/podman/pull/16141