Skip to content

[FR] OpenCloud with Podman Rootless and Quadlet #2053

New issue
New issue
Closed
Feature
Closed
[FR] OpenCloud with Podman Rootless and Quadlet#2053
Feature
Labels
Type:Feature-Request

Description

@cryinkfly
cryinkfly
opened on Dec 17, 2025

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.

Activity

  1. fschade
    added
    Type:Feature-Request
    on Dec 24, 2025
  2. github-project-automation
    added this to Roadmapon Dec 24, 2025
  3. github-project-automation
    moved this to Unqualified in Roadmapon Dec 24, 2025

  4. micbar commented on Dec 31, 2025

    @micbar
    micbar
    on Dec 31, 2025
    Member

    @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.

  5. db-ot
    added the
    Feature
    issue type on Jan 13, 2026
  6. db-ot
    changed the title [-]Feature Request: OpenCloud with Podman Rootless and Quadlet[/-] [+][FR] OpenCloud with Podman Rootless and Quadlet[/+] on Jan 13, 2026
  7. tbsbdr
    removed this from Roadmapon Mar 3, 2026

  8. beedaddy commented on Jun 19, 2026

    @beedaddy
    beedaddy
    on Jun 19, 2026

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

  9. sektor4fun commented on Jun 20, 2026

    @sektor4fun
    sektor4fun
    on Jun 20, 2026

    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

  10. micbar commented on Jun 20, 2026

    @micbar
    micbar
    on Jun 20, 2026
    Member

    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.

  11. senekor commented on Jun 20, 2026

    @senekor
    senekor
    on Jun 20, 2026

    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.

  12. micbar commented on Jun 20, 2026

    @micbar
    micbar
    on Jun 20, 2026
    Member

    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?

  13. senekor commented on Jun 20, 2026

    @senekor
    senekor
    on Jun 20, 2026

    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?

  14. micbar commented on Jun 20, 2026

    @micbar
    micbar
    on Jun 20, 2026
    Member

    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.

  15. micbar commented on Jun 20, 2026

    @micbar
    micbar
    on Jun 20, 2026
    Member

    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

  16. sektor4fun commented on Jun 20, 2026

    @sektor4fun
    sektor4fun
    on Jun 20, 2026
    • 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.

  17. beedaddy commented on Jun 24, 2026

    @beedaddy
    beedaddy
    on Jun 24, 2026

    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.

  18. senekor commented on Jun 24, 2026

    @senekor
    senekor
    on Jun 24, 2026

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

  19. rhafer commented on Jun 24, 2026

    @rhafer
    rhafer
    on Jun 24, 2026
    Member

    I am moving this to a discussion. I think that is better suited for this topic. BTW, nice to see all this efforts around quadlets for OpenCloud!

  20. opencloud-eu
    locked and limited conversation to collaborators on Jun 24, 2026
  21. rhafer
    converted this issue into a discussion #3010 on Jun 24, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    Type:Feature-Request

    Type

    Feature

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions