Yeah in my experience with rootless you don't need to worry about UID shenanigans anymore. Containers can do stuff as root (from their perspective at least) all they want but any files you bind mount into the container are still just owned/modified by your user account on the host system (not a root user bleeding through from the container).

How does that work in practice? Podman is changing the permission bits of files that are synced between the host and the container?

If I create a file with certain permission bits in the container, I'd expect the file to be 100% identical when pulling it over to the host, but maybe that's just "legacy" thinking coming from my docker experience?

What about copying files directly between containers, would that change the permissions as well?

The permissions (rwx) don't change, but the uid/gid is mapped. E.g. uid 0 is the running user outside the container, by uid 1 will be mapped to 100000 (configurable), and say 5000 inside the container is mapped to 105000. I don't remember the exact mapping but it works roughly like that.

Oh, that sounds great! Thank you, that was the information i wanted.

>If I create a file with certain permission bits in the container, I'd expect the file to be 100% identical when pulling it over to the host

The permission bits are metadata on the fs, the file can still be identical.

Plus, how permissions on a file on the container be identical in the host, if e.g. the groups/users are different?

There’s podman-compose which does what you want, but is a community maintained script.

There’s also the ability for podman to run as a system service, and provide an OCI compatible container API. This then integrates seamlessly with the actual docker-compose.

See: https://www.redhat.com/sysadmin/podman-docker-compose

You can point the official docker-compose at podman now!

I do that!

It's 99.999% compatible as the podman people basicaly reimplemented all the docker daemon APIs.

It sometimes lags a bit behind, because sometime docker implements new stuff... But for usage with docker-compose it has worked flawlessly for me.

EDIT: you can also export the podman unix socket via socat, i also tried it to run a rootless docker runtime in kubernetes (podman daemon running as a pod, to run docker builds in kubernetes) as an experiment. It works but i'd love to see a better integration with Gitlab runner project.

Gitlab is supposedly getting podman support any time soon, in 15.1 IIRC ?

I tried podman compose quite a few months ago with my docker compose file and it failed, what is the difference between doing that and this?

So like, you can use docker compose for podman instead of docker, instead of something like podman compose?

The difference is that instead of using podman-compose you use the actual docker-compose.

You have to point your $DOCKER_HOST to the podman unix socket or something, but other than that it’s the actual docker-compose experience. Via the env var trick you could even use the actual docker binary. But you could just alias docker to podman and it works the same, by design!

Wow that sounds amazing! Thanks for the information.

Nah no good alternative yet, I tried running my docker compose file which works perfectly with docker in podman compose and it failed outright.