Podman rootless setup?

[beedaddy]

Hi all,

I'm still having problems finding a working configuration for a OpenCloud rootless container (Podman). My containers are behind a Caddy reverse proxy. So far I have been able to set up all my server applications as quadlets, but OpenCloud seems to be particularly difficult. 😉

But maybe someone has already found a working configuration and can share it?

I've already tried a quite a few things and this is the current status for a minimal OpenCloud (later Collabora would be nice).

[Container]
Image=docker.io/opencloudeu/opencloud-rolling:latest
ContainerName=opencloud
AutoUpdate=local
PublishPort=9200:9200
Network=external.network
Timezone=Europe/Berlin
Environment=OC_URL="https://opencloud.example.com"
Environment=OC_LOG_LEVEL=info
Environment=OC_LOG_COLOR=false
Environment=OC_LOG_PRETTY=false
Environment=PROXY_TLS=false
Environment=OC_INSECURE=true
Environment=IDM_ADMIN_PASSWORD=admin4711
Environment=IDM_CREATE_DEMO_USERS=false
Volume=/srv/podvols/opencloud-config:/etc/opencloud:U
Volume=/srv/podvols/opencloud-data:/var/lib/opencloud:U
Entrypoint="/bin/sh"
Exec="-c" "opencloud init || true; opencloud server"

[Unit]

[Service]
TimeoutStartSec=600
#Restart=always

[Install]
WantedBy=default.target

And Caddyfile:

opencloud.example.com {
        reverse_proxy http://localhost:9200 #{
#               transport http {
#                       proxy_protocol v2
#                       tls_insecure_skip_verify
#               }
#       }
}

But I'm aware that this is currently not working and I always get a access-denied page after I tried to login.

[rhafer]

@beedaddy What exactly is not working? Does it fail to start? Does it crash?

I am deploying opencloud on rootless podman on a daily basis and it works just fine here. The tricky bit is probably to figure out the correct host userid that the opencloud user is mapped to (because of the user namespaces). I usually use podman unshare to set the ownship/permissions correctly.

[beedaddy]

Now I have a working Quadlet with Network=external.network. The container has for some reason to access itself through the public fqdn which does not work by default. But adding AddHost=opencloud.example.com:host-gateway does the routing. Next task is to add Quadlets for other services like Collarbora. 🥴

[Tronde]

Hi @beedaddy,
I appreciate your work creating quadlets for the different services in OpenCloud.

Are you going to publish them somewhere?

I have started to work on an Ansible collection recently. When I got it to run with Bookworm I would like to target distributions that support quadlets. It would be nice, if I can use yours to create templates.

[beedaddy]

Hi @Tronde,

I'm still hoping for someone who knows about quadlets ;)
As time goes on, I try to get other components up and running, but this is all I have for now:

[Unit]
Description=OpenCloud service
After=network-online.target

[Container]
Image=docker.io/opencloudeu/opencloud:2
ContainerName=opencloud
AutoUpdate=local
PublishPort=9200:9200
Network=netext.network
Timezone=Europe/Berlin
Environment=OC_URL="https://opencloud.mydomain.com"
Environment=PROXY_HTTP_ADDR="0.0.0.0:9200"
Environment=OC_LOG_LEVEL=info
Environment=OC_LOG_COLOR=false
Environment=OC_LOG_PRETTY=false
Environment=PROXY_TLS=true
Environment=OC_INSECURE=true
Environment=IDM_ADMIN_PASSWORD=MySecretAdminPassword
Environment=IDM_CREATE_DEMO_USERS=false
AddHost=opencloud.mydomain.com:host-gateway
Volume=/srv/podvols/opencloud-config:/etc/opencloud:U
Volume=/srv/podvols/opencloud-data:/var/lib/opencloud:U
Entrypoint="/bin/sh"
Exec="-c" "opencloud init || true; opencloud server"

[Service]
TimeoutStartSec=600
Restart=always

[Install]
WantedBy=multi-user.target default.target

[Tronde]

Thanks @beedaddy,
I know a bit or two about Quadlets. So I'm happy to answer your questions, if I can.

I would love to find all the necessary and possible config options you can set via environment variables in the documentation. Digging them up in compose files is possible but rather time consuming.

Figuring out the best Podman network config might require some trial and error.

[hichamboushaba]

I know this is a bit old, but jus tin case someone is still looking into this, I'm sharing my findings so far after struggling with a similar situation.

@beedaddy can you confirm if you are using socket activation for Caddy? If yes, then my understanding is that this expected, you need to use AddHost to make the container be able to self-callback, as with socket activation, the http socket is listening on the host, and given the container is running in rootless podman, it can't reach the host services.
When you publish the ports by the reverse proxy directly, this doesn't happen, as podman can then forward the request to the reverse proxy without needing to talk to the host network.

[BitVortex]

I've got the following working as a minimal rootless quadlet setup:

[Container]
ContainerName=opencloud
Image=docker.io/opencloudeu/opencloud-rolling:3
User=0
Volume=/home/podman/opencloud-config:/etc/opencloud
Volume=/home/podman/opencloud-data:/var/lib/opencloud
PublishPort=9200:9200
AutoUpdate=registry
Environment=PROXY_TLS=false  # allow non-TLS connections from reverse proxy
Environment=OC_INSECURE=true  # allow use with self-signed certificate
Environment=IDM_ADMIN_PASSWORD=XX-YY-ZZ
Environment=IDM_CREATE_DEMO_USERS=false
Environment=OC_URL=https://xx.yy.zz
Entrypoint="/bin/sh"
Exec=-c 'opencloud init || true; opencloud server'
[Install]
WantedBy=multi-user.target default.target

Further, more intricate setups are provided in the helpful repository by @lrdecoder below. To just get started, this might already be sufficient for some.

[lrdecoder]

Hi @BitVortex, @beedaddy, @Tronde

Replying to another question I put together this: https://github.com/lrdecoder/opencloud-quadlets. It contains opencloud with podman rootless quadlets, with Caddy as a reverse proxy. The files are based on the setup that I have running on an ARM vps, somewhat simplified and with sensitive data removed.

Maybe this is of help to you.

[Tronde]

Hi @BitVortex,
That's awesome and exactly what I'm looking for these days. I forked your setup and will try to integrate it in my environment. If I need to change or patch something I'll make sure to send a PR.

Cheers,
Tronde

[BitVortex]

Hi @lrdecoder, do you have Radicale running as well by any chance? Your quadlets have been super helpful as guidance so far.
Would you be open to merging a PR that includes Radicale support? I'd also reverse-engineer it from https://github.com/opencloud-eu/opencloud/tree/main/deployments/examples/opencloud_full, mainly to get Obsidian syncing support working with 'Remotely Save'.

[Greylinux]

Hi @lrdecoder, do you have Radicale running as well by any chance? Your quadlets have been super helpful as guidance so far. Would you be open to merging a PR that includes Radicale support? I'd also reverse-engineer it from https://github.com/opencloud-eu/opencloud/tree/main/deployments/examples/opencloud_full, mainly to get Obsidian syncing support working with 'Remotely Save'.

I managed to get Radicale working.

I created a directory for Radicale with one for the config (which I added from the opencloud repo) and one for the data.

added the proxy.yaml as per the official opencloud docker compose repo to my opencloud directory and added an additional volume for the proxy.yaml to opencloud.container

opencloud.container

[Unit]
Description=Opencloud

[Container]
ContainerName=opencloud
Image=docker.io/opencloudeu/opencloud-rolling:3
UserNS=keep-id
Volume=/var/home/core/opencloud/config:/etc/opencloud:z
Volume=/var/home/core/opencloud/data:/var/lib/opencloud:z
Volume=/var/home/core/opencloud/proxy_config/proxy.yaml:/etc/opencloud/proxy.yaml:z ## added this volume mount
Timezone=Europe/London
Network=opencloud.network
NetworkAlias=opencloud
AutoUpdate=registry
Environment=PROXY_TLS=false  # allow non-TLS connections from reverse proxy
Environment=OC_INSECURE=true  # allow use with self-signed certificate
Environment=IDM_ADMIN_PASSWORD=pass
Environment=IDM_CREATE_DEMO_USERS=false
Environment=OC_URL=https://my-cloud.duckdns.org
Entrypoint="/bin/sh"
Exec=-c 'opencloud init || true; opencloud server'

[Service]
TimeoutStartSec=600
Restart=always

[Install]
WantedBy=default.target

radicale.container

Unit]
Description=Radicale

[Container]
ContainerName=radicale
Image=docker.io/opencloudeu/radicale:latest
Network=opencloud.network
NetworkAlias=radicale
UserNS=keep-id                  ### this is important as radicale runs as user and group 2999
Volume=/var/home/core/radicale/config/config:/etc/radicale/config:z
Volume=/var/home/core/radicale/data:/var/lib/radicale:z

[Service]
TimeoutStartSec=600
Restart=always

[Install]
WantedBy=default.target

this is the link to radicale's config on the opencloud repo ( I left this unchanged for the test)

radicale config

and this is the proxy.yaml

# This adds four additional routes to the proxy. Forwarding
# request on '/carddav/', '/caldav/' and the respective '/.well-knwown'
# endpoints to the radicale container and setting the required headers.
additional_policies:
  - name: default
    routes:
      - endpoint: /caldav/
        backend: http://radicale:5232
        remote_user_header: X-Remote-User
        skip_x_access_token: true
        additional_headers:
          - X-Script-Name: /caldav
      - endpoint: /.well-known/caldav
        backend: http://radicale:5232
        remote_user_header: X-Remote-User
        skip_x_access_token: true
        additional_headers:
          - X-Script-Name: /caldav
      - endpoint: /carddav/
        backend: http://radicale:5232
        remote_user_header: X-Remote-User
        skip_x_access_token: true
        additional_headers:
          - X-Script-Name: /carddav
      - endpoint: /.well-known/carddav
        backend: http://radicale:5232
        remote_user_header: X-Remote-User
        skip_x_access_token: true
        additional_headers:
          - X-Script-Name: /carddav
# To enable the radicale web UI add this rule.
# "unprotected" is True because the Web UI itself ask for
# the password.
# Also set "type" to "internal" in the config/radicale/config
#      - endpoint: /caldav/.web/
#        backend: http://radicale:5232/
#        unprotected: true
#        skip_x_access_token: true
#        additional_headers:
#          - X-Script-Name: /caldav

in opencloud frontend it should show that you have access to calendar now.

in the clients I tested the URL was https://your-domain.com/caldav/ ( with a trailing /)

you will need to create an app token for the password.

hope this helps

[big1tasty]

Would be great if there is a deployment guide for podman too!

[Greylinux]

I cant for the life of me get this to work properly.

currently testing on a fedora CoreOS VM. I have a Caddy server with Duckdns addon to get a cert for a duckdns domain ( for testing purposes only) this all seems to work as expected. I have Opencloud in the same network as Caddy with firewall forwarding 443 ->1143 & 80 -> 1880 on Caddy and ports mapped 1880 and 1443 to 80 and 443 inside the container .

I also have a pihole that provides a local DNS entry to map my domain to the IP of the server.

This is how I currently do it with nextcloud AIO

I can get the Opencloud login but upon logging in , it suggests it cannot verify the token.

any ideas?

Opencloud.container

[Container]
ContainerName=opencloud
Image=docker.io/opencloudeu/opencloud-rolling:3
UserNS=keep-id
Volume=/var/home/core/opencloud/config:/etc/opencloud:z
Volume=/var/home/core/opencloud/data:/var/lib/opencloud:z
PublishPort=9200:9200
Network=opencloud.network
Environment=PROXY_HTTP_ADDR="0.0.0.0:9200"
AutoUpdate=registry
Environment=PROXY_TLS=false  # allow non-TLS connections from reverse proxy
Environment=OC_INSECURE=true  # allow use with self-signed certificate
Environment=IDM_ADMIN_PASSWORD=pass
Environment=IDM_CREATE_DEMO_USERS=false
AddHost=my-cloud.duckdns.org:host-gateway
Environment=OC_URL=https://my-cloud.duckdns.org
Entrypoint="/bin/sh"
Exec=-c 'opencloud init || true; opencloud server'
[Install]
WantedBy=multi-user.target default.target

Caddy.container

[Unit]
Description=Caddy

[Container]
ContainerName=caddy
Image=docker.io/serfriz/caddy-duckdns     # this is caddy with duckdns plugin 
Network=opencloud.network
PublishPort=1880:80
PublishPort=1443:443
Volume=/var/home/core/caddy/config:/etc/caddy:z
Volume=/var/home/core/caddy/data:/data:z

[Service]
Restart=always

[Install]
WantedBy=default.target

Opencloud.network

[Unit]
Description=OpenCloud network
After=network-online.target
PartOf=opencloud.target

[Network]

[Install]
WantedBy=opencloud.target

Caddyfile

https://my-cloud.duckdns.org:443 {
        reverse_proxy opencloud:9200
        tls {
                dns duckdns "my token"
                propagation_timeout 300s
                propagation_delay 120s
        }
}

These are the errors

{"level":"error","service":"proxy","error":"failed to verify access token: Get \"https://my-cloud.duckdns.org/.well-known/openid-configuration\": dial tcp 169.254.1.2:443: connect: connection refused","authenticator":"oidc","path":"/ocs/v1.php/cloud/capabilities","user_agent":"Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/142.0.0.0 Safari/537.36","client.address":"10.89.0.2","network.peer.address":"","network.peer.port":"","time":"2025-11-16T16:10:34Z","message":"failed to authenticate the request"}

{"level":"error","service":"proxy","error":"failed to verify access token: Get \"https://my-cloud.duckdns.org/.well-known/openid-configuration\": dial tcp 169.254.1.2:443: connect: connection refused","authenticator":"oidc","path":"/api/v0/settings/roles-list","user_agent":"Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/142.0.0.0 Safari/537.36","client.address":"10.89.0.2","network.peer.address":"","network.peer.port":"","time":"2025-11-16T16:10:34Z","message":"failed to authenticate the request"}

{"level":"error","service":"proxy","error":"failed to verify access token: Get \"https://my-cloud.duckdns.org/.well-known/openid-configuration\": dial tcp 169.254.1.2:443: connect: connection refused","authenticator":"oidc","path":"/graph/v1.0/me","user_agent":"Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/142.0.0.0 Safari/537.36","client.address":"10.89.0.2","network.peer.address":"","network.peer.port":"","time":"2025-11-16T16:10:34Z","message":"failed to authenticate the request"}

[micbar]

It cannot connect to Get "https://my-cloud.duckdns.org/.well-known/openid-configuration from the opencloud container.

You can check that with curl from inside the opencloud container. It is a reverse proxy problem.

[Greylinux]

Interesting , I did notice that if I used curl inside Opencloud it wouldn't resolve the domain , I didn't pin this down to a reverse proxy issue.

Mmm! Maybe its an option in the Caddyfile to work this issue out.

Thank you for some direction to try and resolve this.

[Greylinux]

I resolved the issue by discovering that I needed to add NetworkAlias=opencloud to opencloud.container file and
NetworkAlias=my-cloud.duckdns.org to the caddy.container file. This was because they were both in a custom network . I have since removed
addHost=my-cloud.duckdns.org:host-gateway

as it was no longer required in a custom network

thanks @micbar for you advice much appreciated

[pierrecnalb]

In case anyone is interested, I wrote some "security hardened" opencloud podman quadlets here https://github.com/pierrecnalb/quadlets to be used on a server.
As mentioned in the repository, they are not strictly rootless, but probably more secure than badly-configured rootless (read on) and without the hassle rootless would bring.
Indeed, according to this discussion, Daniel Walsh (one of the developer of Podman) mentioned the following:

"Rootless containers are great for containers run by users on a system, but if you are just running containers on a server, then --userns=auto is a more secure solution".

As he explained, when you run multiple containers as a rootless user, they run in the same user namespace so they can attack each other from a User Namespace point of view.
Instead, using rootful containers with the --userns=auto option, then those containers are running in unique user namespace and are isolated.

In addition to that, using a dedicated user in the container and dropping capabilities/privileges, should provide way more security than most docker compose files found on the internet anyway.

[reidprichard]

Worth mentioning that in that thread, it's noted that rootful with --userns=auto is not more secure in every way than rootless without. As of Aug 2024:

On the networking side, running as root with --userns=auto doesn't currently work with any user-mode networking implementation (#17840), so, at the moment, you can't enforce strong network isolation (no crafted frames, no ARP spoofing) by design, as root.

Interesting discussion though!

[pierrecnalb]

I don't think this assumption is correct though: using multiple rootless containers with a given user and without --userns=auto is problematic because they all would be running on the same user namespace, and therefore they could attack each other.
This is in fact what Daniel Walsh is replying in the following replies of the 2024 thread: "I believe for a server running all containers in a separate User Namespace with isolated UIDs is the most secure way to run workloads."

From a security point of view, rootful with userns=auto behaves in the same way as rootless at runtime, since the rootful userns=auto containers do not have root capabilities outside the containers. This is because all container users (including root) are mapped to unprivileged UIDs in the host namespace.
However, it is true that rootless with userns=auto would be the most secure way since it would add additional security to the network stack and the podman exe itself, but it is a bit more work to setup/manage.

In my previous comment, I thought userns=auto could only be applied to rootful, but I was wrong: containers/podman#13728 (comment)
It means that the quadlets from my repository could be used in both rootful and rootless configurations.
The only prerequesite is to setup things so that userns=auto works properly.