[FR] OpenCloud with Podman Rootless and Quadlet

[cryinkfly]

Feature Request: OpenCloud with Podman Rootless and Quadlet

Is your feature request related to a problem? Please describe.

The official OpenCloud guide describes installation via Docker. However, many users want to run Podman Rootless containers to ensure security without root privileges, while also benefiting from systemd integration for automatic start and restarts.

Without an easy Podman Rootless guide, users currently have to:

• manually run podman run (no automatic management),
• use rootful Podman (losing the security advantages of Rootless),
• or create their own scripts to properly configure data volumes and startup options.

Describe the solution you'd like

I would like an official or documented way to run OpenCloud directly with:

• Podman Rootless,
• systemd integration via Quadlet,
• existing Podman data volumes,

so that:

• OpenCloud starts automatically at boot,
• configuration and data persist in Podman volumes,
• HTTPS/OC_URL works correctly.

My implementation can be found here:
https://github.com/cryinkfly/podman-rootless-quadlets/tree/main/quadlets/opencloud-minimal
(I adapted the Docker guide from https://docs.opencloud.eu/de/docs/admin/getting-started/container/docker for Podman Rootless + Quadlet.)

Describe alternatives you’ve considered

• Run OpenCloud manually with podman run, without systemd integration or automatic start.
• Use rootless Podman without a Quadlet systemd unit, which complicates management.
• Use rootful Podman, losing the security benefits of a Rootless installation.

Additional context

• The goal is a simple setup for Podman Rootless users, including persistent data via Podman volumes.
• It would be nice to be briefly mentioned in the official project as I implemented the Quadlet integration.

[micbar]

@cryinkfly Thank you for that proposal.

We already have this thread https://github.com/orgs/opencloud-eu/discussions/1498 where the proposal has been made originally.

We want to support that and start with it in Q1 2026. So this should be good news!

We will reach out in january and try to coordinate that for the community. We will also take a look at your implementation.

[beedaddy]

I'm waiting eagerly for this. But it has been removed from the roadmap? Why? What's the status of this feature request?

[sektor4fun]

While I cannot answer your question directly I can share a podman quadlet that works via rootless podman and may help you a bit.
The first lines demonstrate a full cycle from deinstall to install (commented out - just for reference). If you aim for a fresh install, start with the "mkdir" line. The last line is optional. It's just the CLI equivalent of the quadlet itself, interesting for testing purposes. Instructions are derived from the official install docs and extended where required. Main thing is "UserNS=keep-id:uid=1000,gid=1000" when the uid/gid of your rootless podman user is NOT 1000. Let's assume your uid/guid is 1001/1001, then you need this line! This is required because OpenCloud runs inside the container as uid/gid 1000 and you want to access the files from the bind mount. Otherwise use keep-id. The "AutoUpdate" line should be considered.. Not everyone wants automatic updates (systemd units "podman-auto-update" and "podman-auto-update.timer" must be running and enabled to make auto updates work.)

## Complete cycle from delete existing instance to install a new one:
#podman container stop opencloud
#rm -rf $HOME/opencloud/
#mkdir -p $HOME/opencloud/opencloud-config; mkdir -p $HOME/opencloud/opencloud-data
#podman run --rm --userns keep-id:uid=1000,gid=1000 -it --hostname opencloud --name opencloud -v $HOME/opencloud/opencloud-config:/etc/opencloud -v $HOME/opencloud/opencloud-data:/var/lib/opencloud -e IDM_ADMIN_PASSWORD=admin -e OC_URL=https://server:9200 docker.io/opencloudeu/opencloud:latest init
#podman run --rm --userns keep-id:uid=1000,gid=1000 --hostname opencloud --name opencloud -d -p 9200:9200 -v $HOME/opencloud/opencloud-config:/etc/opencloud -v $HOME/opencloud/opencloud-data:/var/lib/opencloud -e IDM_ADMIN_PASSWORD=admin -e OC_INSECURE=true -e PROXY_HTTP_ADDR=0.0.0.0:9200 -e OC_URL=https://server:9200 docker.io/opencloudeu/opencloud:latest


[Unit]
Description=OpenCloud
Documentation=https://docs.opencloud.eu
Requires=podman-auto-update.timer
After=podman-auto-update.timer

[Container]
Image=docker.io/opencloudeu/opencloud:latest
ContainerName=opencloud
HostName=opencloud
AutoUpdate=registry
UserNS=keep-id:uid=1000,gid=1000
PublishPort=9200:9200

Environment=IDM_ADMIN_PASSWORD=admin
Environment=OC_INSECURE=true
Environment=PROXY_HTTP_ADDR=0.0.0.0:9200
Environment=OC_URL=https://server:9200

Volume=%h/opencloud/opencloud-config:/etc/opencloud
Volume=%h/opencloud/opencloud-data:/var/lib/opencloud

[Service]
# Extend timeout to wait for image download
TimeoutStartSec=900
# Automatic restart
Restart=always

[Install]
# Start at boot
# WantedBy=default.target

The rest as usual:

copy to $HOME/.config/containers/systemd/opencloud.container
systemctl --user daemon-reload
systemctl --user start opencloud

[micbar]

The opencloud team currently has no capacity for working on this, but we could offer to create a repository and let the community work together on that.

[senekor]

I'm comparing this quadlet file with my own and I have some comments.

• Having Requires= and After= dependencies on the auto-update timer seems weird to me. It basically expresses that the container cannot run unless auto-updates are working. I just use AutoUpdate=registry and ennable the timer separately (systemctl --user enable --now podman-auto-update.timer).

• I don't use directories in my home folder. I use named volumes, which Podman automatically creates if they don't exist yet.

  Volume=opencloud-config:/etc/opencloud:Z
  Volume=opencloud-data:/var/lib/opencloud:Z

• I don't mess around with keep-id either. Why would you want to access the files in those volumes yourself? For backup, you can use podman volume export.

• You shouldn't use the latest tag, this will auto-update across major versions with breaking changes. Productive deployments should pin to the latest major version, 4 in this case.

• I also have a comment in my quadlet file about the first init step:

  # only needed at first start:
  # Exec=init --insecure=true

  To do the initial deployment: Uncomment that line, daemon-reload, start the service, check logs, stop the service, comment the line again, daemon-reload, start the service.

  The official docker-compose file does "init" and "start" in one step by swallowing errors from the init step. That's great if the init step fails because init has already happened. It's not so great if init fails for another reason. Then, the official setup just silently moves on to the "start" stage and likely fails there, because "init" isn't actually complete.

[micbar]

The official docker-compose file does "init" and "start" in one step by swallowing errors from the init step. That's great if the init step fails because init has already happened. It's not so great if init fails for another reason. Then, the official setup just silently moves on to the "start" stage and likely fails there, because "init" isn't actually complete.

The init step is convenience. It is a shortcut to create randomized secrets and uuids for the storage. One could completely skip it and provide the values from the ENV variables.

Is there a better fit in podman to let maybe podman create random secrets?

[senekor]

Is there a better fit in podman to let maybe podman create random secrets?

Not that I know of. Is there documentation about these values that need to be provided to skip the init step? If the step is just a convenience, maybe it could be implemented as an optional flag to the server command? Or, if there is no reason why somebody wouldn't want these secrets and uuids to be generated, the server command could just do that always?

[micbar]

Or, if there is no reason why somebody wouldn't want these secrets and uuids to be generated

Yes. In our kubernetes helm chart, all these values live in a configmap and in kubernetes secrets and can be managed by kubernetes native processes.

The server command is really scoped only to start the server, there shouldn’t be any hidden magic in it.

[micbar]

In our dev stack, we skip the init step.

The needed configs are there https://github.com/opencloud-eu/opencloud/blob/main/.vscode/launch.json#L41

[sektor4fun]

• Having Requires= and After= dependencies on the auto-update timer seems weird to me. It basically expresses that the container cannot run unless auto-updates are working. I just use AutoUpdate=registry and ennable the timer separately (systemctl --user enable --now podman-auto-update.timer).

Thank you for pointing me to this typo! It makes no sense of course, copy/paste bug.. See the corrected quadlet here:

## Complete cycle from delete existing instance to install a new one:
#podman container stop opencloud
#rm -rf $HOME/opencloud/
#mkdir -p $HOME/opencloud/opencloud-config; mkdir -p $HOME/opencloud/opencloud-data
#podman run --rm --userns keep-id:uid=1000,gid=1000 -it --hostname opencloud --name opencloud -v $HOME/opencloud/opencloud-config:/etc/opencloud -v $HOME/opencloud/opencloud-data:/var/lib/opencloud -e IDM_ADMIN_PASSWORD=admin -e OC_URL=https://server:9200 docker.io/opencloudeu/opencloud:latest init
#podman run --rm --userns keep-id:uid=1000,gid=1000 --hostname opencloud --name opencloud -d -p 9200:9200 -v $HOME/opencloud/opencloud-config:/etc/opencloud -v $HOME/opencloud/opencloud-data:/var/lib/opencloud -e IDM_ADMIN_PASSWORD=admin -e OC_INSECURE=true -e PROXY_HTTP_ADDR=0.0.0.0:9200 -e OC_URL=https://server:9200 docker.io/opencloudeu/opencloud:latest

[Unit]
Description=OpenCloud
Documentation=https://docs.opencloud.eu
After=network-online.target
Wants=network-online.target

[Container]
Image=docker.io/opencloudeu/opencloud:latest
ContainerName=opencloud
HostName=opencloud
AutoUpdate=registry
UserNS=keep-id:uid=1000,gid=1000
PublishPort=9200:9200

Environment=IDM_ADMIN_PASSWORD=admin
Environment=OC_INSECURE=true
Environment=PROXY_HTTP_ADDR=0.0.0.0:9200
Environment=OC_URL=https://server:9200

Volume=%h/opencloud/opencloud-config:/etc/opencloud
Volume=%h/opencloud/opencloud-data:/var/lib/opencloud

[Service]
# Extend timeout to wait for image download
TimeoutStartSec=900
# Automatic restart
Restart=always

[Install]
# Start at boot
# WantedBy=default.target

• I don't mess around with keep-id either. Why would you want to access the files in those volumes yourself? For backup, you can use podman volume export.

This is why I use bind mounts instead of volumes. It enables me to execute headless and fast incremental backups via restic. Exporting such a huge volume (in my case) is not something that helps from a backup point of view. Keep-id is required to make sure the files within the bind mount are owned by the host user, otherwise the backup program must run as root which I don't like.

• You shouldn't use the latest tag, this will auto-update across major versions with breaking changes. Productive deployments should pin to the latest major version, 4 in this case.

You are right. This quadlet is supposed to be a starting point for those who are looking for a simple home setup to begin with. It requires modifications if you aim for something more professional, of course.

[beedaddy]

Thanks for providing the examples. Actually, it's not so much the basic OpenCloud that drives me crazy, but rather when you want to use various extensions like Collabora Office or Radicale. That's when things get a little complicated.

[senekor]

I haven't done it yet, but a community repo would be nice for that. Let's figure it out together.