Hey bigdickdonkey, I recently tried and wasn’t able to shit my way through podman, there just wasn’t enough chatter and guides about it. I plan to revisit it when Debian 13 comes out, which will include podman quadlets. I also tried to get podman quadlets to work on Ubuntu 24 and got closer, but still didn’t manage and Ubuntu is squicky.

I read about true user rootless Docker and decided that was too finicky to keep up to date. It needs some annoying stuff to update, from what I could tell. I was planning on many users having their own containers, and that would have gotten annoying to manage. Maybe a single user would be an OK burden.

The podman people make a good argument for running podman as root and using userns to divvy out UIDs to achieve rootless https://www.redhat.com/en/blog/rootless-podman-user-namespace-modes but since podman is on the back burner till there’s more community and Debian 13, I applied that idea to Docker.

So I went with root Docker with the goals of:

• read only
• set user to different UID:GID for each container
• silo containers in individual Docker networks
• nothing gets /var/run/docker.sock
• cap_drop: all
• security-opt=no-new-privileges
• volumes all get tagged with :rw,noexec,nosuid,nodev,Z

Basically it’s the security best practices from this list https://cheatsheetseries.owasp.org/cheatsheets/Docker_Security_Cheat_Sheet.html

This still has risk of the Docker daemon being hacked from the container itself somehow, which podman eliminates, but it’s as close to the podman ideal I can get within my knowledge now.

Most things will run as rootless+read-only+cap_drop with minor messing. Automatic ripping machine would not, but that project is a wild ride of required permissions. Everything else has succumbed, but I’ve needed to sometimes have a “pre launch container” to do permission changes or make somewhere like /opt writable.

I would transition one app stack at a time to the best security practices, and it’s easier since you don’t need to change container managers. Hope this helps!

deleted by creator

Not sure if it makes a difference and not quite your question but I’ve just switched away from nextcloud-aio to just having my own docker compose, so I have better control and know what’s going on more. I always found it funny and when installing on a new VPS decided to try. It was surprisingly straightforward and Ive been able to install everything I need.

Let me know if my docker compose would help. I still need to add the backup solution but it’s going to be straightforward as well.

I’m running podman and podman-compose with no problem. And I’m happy. At first I was confused by the uid and gid mapping the containers have, but you’ll get used to it.

This are some notes I took, please don’t take all of it for the right choice.

Podman-Stuff

https://github.com/containers/podman/blob/main/docs/tutorials/rootless_tutorial.md

storage.conf

To use the fuse-overlay driver, the storage must be configured:

.config/containers/storage.conf

[storage]
  driver = "overlay"
  runroot = "/run/user/1000"
  graphroot = "/home/<user>/.local/share/containers/storage"
  [storage.options]
    mount_program = "/usr/bin/fuse-overlayfs"

Lingering (running services without login / after logout)

https://github.com/containers/podman/issues/12001

https://unix.stackexchange.com/questions/462845/how-to-apply-lingering-immedeately#462867

sudo loginctl enable-linger <user>

I switched and was very glad to do so. You increase your security and so far I haven’t seen any downside. Every container I’ve tried has worked without issues, even complex ones.

One of the main reason I switched to podman was its compatibility with firewalld. Haven’t used rootless docker, but podman and podman-compose gets the job done for me.