Comment by teekert
4 days ago
I went all in on podman compose last year but went all back because off constant permission errors. I thought it was going to be better than docker because I run the containers as a user… but man the amount of time I wasted on files that either I or the container itself or some other container couldn’t read… With docker I felt that stuff just works.
And then there are the extra steps: Enable user lingering, make a systemd service that starts the compose containers (and there is nothing really “native”, it’s a script.) With Docker compose containers just restart if you say so in the file.
There are many great things about podman, will try again in a year or so perhaps?
> I went all in on podman compose last year but went all back because off constant permission errors.
The issue is that "ease of use" and "it just works" come at the expensive of security and the principle of least privilege. Docker makes things easy by running a daemon as root. Rootless Podman forces you to think about permissions and does not stab you in the back by overwriting your firewall rules.
Yes, the firewall rule altering was what drove us to podman! Was kind of weird to find a container's Postgres wide open on 5432 after a `sudo ufw default deny`. Madness really.
But as said below, the permissions issues got to us.
what kind of stuff is in your compose?
Mostly self made containers, also one with Claude-code, but I couldn't for the life of me get it to be able to store and retrieve credentials in an externally mounted folder (~/.claude). I tried everything from fixing the user creation process in the container, `--userns=keep-id`, `--userns=keep-id:uid=1000,gid=1000`, several tags, :Z, :U, `chown`-ing after creation etc. And I keep running into that stuff.
I wish that "run podman containers as a user, rootless" would just simply mean: All the things are also the property of the user, but you get weird uid/guid combos and stuff on your filesystem as owners you never heard of (like www-data, but not that one in particular) due to the mismatches.
If containers can ever simply be run as user like they are a user process, that would be so nice.
I had to do some extra stuff for my containers, here's some info from a tutorial I wrote:
Following the Arch wiki:
# Dependencies `yay -S podman slirp4netns aardvark-dns`
# Setup podman-compose and the venv ``` python -m venv .venv source .venv/bin/activate pip3 install --user podman-compose ```
On WSL, you'll need to be on Debian bookworm or newer. Older versions of podman-compose for, ie, bullseye, do not work.
# Reserving alternate UIDs/GIDs `# usermod --add-subuids 100000-165535 --add-subgids 100000-165535 username`
# Setup the storage configuration to overlay Create/edit the following file: `vim ~/.config/containers/storage.conf`
Add/edit the following line: ``` [storage] driver="overlay" ```
# Propagate changes to podman `$ podman system migrate`
# Bring the systems up `podman-compose up`
# I'm on WSL and it's not working (DNS issues)
Check if the network created by podman has dns enabled:
``` % podman network inspect $containername_default | grep dns "dns_enabled": true, ```
If it's false, install another dns resolver:
``` sudo apt install golang-github-containernetworking-plugin-dnsname ```
Then delete the network created by podman-compose:
`podman network rm $containername_default`
## Out of memory when running `podman-compose up`
This error may include "could not map anonymous shared memory".
If you're on a mac, try increasing the amount of memory the VM can use, eg:
https://stackoverflow.com/questions/70114200/increase-podman...
``` podman machine stop podman machine set --memory 4096 podman machine start ```
This will provide podman with 4GB of memory to work with when spawning containers.
https://gist.github.com/ijustlovemath/82b4fa31a7c745e87bac5f...
2 replies →