OpenCloud
Replies: 23 comments
|
same issue with same setup. The only message in logs i get is:
|
|
We need more logfiles. |
|
Try # Required: OpenCloud's minimal container image has no CA bundle, so internal service-to-service
--
# TLS verification (e.g. proxy verifying its own OIDC endpoint) must be skipped.
# This does NOT affect TLS presented to clients — browsers still get the valid Let's Encrypt cert.
INSECURE=true |
|
Same issue with same setup; the error shown on docker logs:
|
|
We need all log lines from the login attempt. The line you pasted is only showing that openCloud doesn’t accept the request. |
|
Hi
Turns out that by default podman uses(copies) your Container Host file: So in my case the I fixed that by running the container with |
|
This is a classic.
OpenCloud needs to resolve that public URL. In docker compose, we are using an alias on the reverse proxy container. |
|
I can confirm this issue with additional findings that might help narrow down the root cause: Setup: OpenCloud 7.2.0 (both standalone and opencloud-compose framework), Authentik as IdP, Traefik reverse proxy (external proxy mode). What I found after extensive debugging:
Root cause hypothesis: The Web-Frontend OIDC flow uses XHR for the initial signin check instead of a browser redirect. When the proxy returns a 302 to the external IdP, the XHR fails to follow it cross-origin. Happy to provide logs or test specific scenarios if it helps. |
|
I think there is heavy confusion here. External idp means no openCloud idp service is running. The routes for sign in and authentication are then completely routed by the external idp. You seem to have mixed the concerns. |
|
Thanks for the quick reply! You are right, there might be heavy confusion on my end. I have been staring at this for hours and might be missing the forest for the trees. What confuses me: when I set Am I missing a config flag that tells the proxy to bypass the internal idp and go directly to the OIDC issuer for the signin flow? Or should this happen automatically when |
|
OC_OIDC_ISSUER sets the idp regardless if is internal or external. check https://your-domain/config.json The authentik IDP should be configured there. If not, the config is not applied. |
|
I'm trying to set up Authentik using these env vars: OC_OIDC_ISSUER=https://auth.mueller-nas.de/application/o/opencloud/
OC_OIDC_CLIENT_ID=web
OC_OIDC_CLIENT_SCOPES=openid profile emailAfter restarting, "openIdConnect": {
"metadata_url": "https://auth.mueller-nas.de/application/o/opencloud/.well-known/openid-configuration",
"authority": "https://auth.mueller-nas.de/application/o/opencloud/",
"client_id": "web",
"scope": "openid profile email"
}So far so good, Authentik appears to be configured.
The login page just shows an endless loading spinner. What should I look at next? What did I miss? |
|
There is a setting |
|
It works now, thank you for the help! The issue was that I misunderstood:
The working combination is: environment:
- OC_OIDC_ISSUER=https://auth.mueller-nas.de/application/o/opencloud/
- OC_OIDC_CLIENT_ID=web
- OC_OIDC_CLIENT_SCOPES=openid profile email
- PROXY_OIDC_REWRITE_WELLKNOWN=true
- IDP_DOMAIN=auth.mueller-nas.deNo idea how I missed this, it's right here: https://docs.opencloud.eu/docs/admin/configuration/authentication-and-user-management/external-idp/#opencloud-configuration. Sorry for the noise and taking up your time with what was ultimately a reading comprehension issue on my side. I don't know if I have a particularly unusual setup. I realize this isn't something the OpenCloud team controls, but maybe the |
|
@DasCarstel Happy to help! Do you have an idea how we can contact the authentik team? |
|
@micbar Everything I know is from this page: https://integrations.goauthentik.io/applications/ and from this section at the bottom of the support article for opencloud:
|
Hm, that I think every client except the desktop app meanwhile works with out it (they query the webfinger endpoint and send the Do you really still see any client (except the desktop app, for which we're working on a fix) sending requests to the |
|
I’ve made quite a bit of progress with my Authentik configuration, which I’ve set up with the help of Codex. I’ve now reached a point where Codex tells me that everything is fine, but this issue highlights the problem. Here is an analysis from Codex; I hope it helps: I can reproduce the issue consistently with OpenCloud behind Nginx Proxy Manager and an external authentik OIDC provider. Environment
Relevant OpenCloud configuration: OC_EXCLUDE_RUN_SERVICES: "idp"
OC_OIDC_ISSUER: "https://<idp-domain>/"
PROXY_OIDC_REWRITE_WELLKNOWN: "true"
PROXY_OIDC_ACCESS_TOKEN_VERIFY_METHOD: "jwt"
PROXY_USER_OIDC_CLAIM: "preferred_username"
PROXY_USER_CS3_CLAIM: "username"
PROXY_AUTOPROVISION_ACCOUNTS: "false"
OC_URL: "https://<opencloud-domain>"
PROXY_TLS: "false"Reproduction
This is reproducible even without existing browser cookies, local storage, or normal browser tabs. Relevant request sequenceTimes below are CEST from Nginx Proxy Manager logs. The OIDC provider flow is successful: The I can provide sanitized complete OpenCloud, authentik, and Nginx Proxy Manager logs if a specific time range or additional log level would help. |
|
Update: OK, it’s working for me after all. I knew I could still log in yesterday. I’m still setting things up, though. Today, however, I’d logged in using my personal user account rather than my admin account. For my personal user accounts, the email address was still listed as the username in OpenCloud. However, Authentik uses a standard username. So, in my case, the username wasn’t entered the same way in Authentik and OpenCloud. |
|
You need role claims. You cannot login without a role. Please check docs.opencloud.eu for external IdP. |
|
Thank you. I found the root cause in my case: it was a username mapping mismatch, not a missing role claim. The affected existing OpenCloud account used an email address as its username because I had originally not created a separate username. In authentik, however, I used a regular username. My configuration maps authentik's After changing the existing OpenCloud account to use the same regular username as authentik, login succeeded. PROXY_USER_OIDC_CLAIM: "preferred_username"
PROXY_USER_CS3_CLAIM: "username"
PROXY_ROLE_ASSIGNMENT_DRIVER: "default"
GRAPH_ASSIGN_DEFAULT_USER_ROLE: "true"I use the default role assignment driver, so users without an existing OpenCloud role receive the default My intention is to keep the existing accounts in OpenCloud, Home Assistant, and Immich, rather than creating new accounts only because authentik was introduced. I also want to retain the option of disconnecting authentik later without having to migrate user accounts again. I have now started to standardize regular usernames across all services. Previously, Home Assistant already used usernames while some OpenCloud accounts used email addresses, which caused this mismatch. Thank you for pointing me to the role configuration. I will keep it in mind if I later switch to OIDC-based role assignments. |
|
I am converting this to a discussion. As not about an actual bug in OpenCloud, but mostly about configuration issues with external IDPs and/or reverse proxys. |
|
Just to let you know: I’d already mentioned that I’d managed to get it working for myself. I’ve now set up an Authentik MFA configuration that works well for my specific use case – including LAN-Speed, Tailscale VPN, Cloudflare, NGINX, AdGuard and WebDAV. Over the last few days, I’ve been trying to document the entire setup as clearly as possible. Perhaps this guide will help someone who wants to set up something similar, or who has encountered the errors mentioned here. My use case is for private use with family and friends. My aim was to keep it as cost-effective and convenient as possible, without ending up paying more than for a 100 GB Google Drive subscription. :) For me, the whole setup currently works for the cost of a domain name alone – and that’s without a static public IPv4 address. I’ve documented the configuration and my experiences here to the best of my knowledge and belief: |
Uh oh!
There was an error while loading. Please reload this page.
Bug: Login succeeds but always redirects to
/access-deniedbehind external nginx proxyDescription
Fresh OpenCloud installation behind an external nginx reverse proxy completes login successfully, but always redirects to:
The UI shows:
The issue happens on both rolling and stable 5.2.0.
Setup
external-proxy/opencloud.yml127.0.0.1:9200PROXY_TLS=falseOC_URL=https://cloud.gonzo64.deWhat works
These endpoints return
200:Container logs show successful callback requests.
Problem
After valid credentials:
200/access-deniedThe frontend repeatedly calls:
which suggests an auth restore loop.
Suspected issue
Looks like a frontend OIDC token persistence / session restore issue after successful callback when running behind external proxy mode.
All reactions