gurulee

I'm still on the rock solid 6.12.15...is your upgrade to 7.1.4 still stable with now issues?

No....I'm got the itch though! I very apprehensive about my custom docker networks with vLAN's breaking during the upgrade. I do not want to rebuild anything.

@Juancamiloso this is what works for me in Authentik: Redirect URIs strict: https://jellyfin.mydomain.com/sso/OID/r/authentik strict: https://jellyfin.mydomain.com/sso/OID/redirect/authentik

I'm Authentik 2025.2.4 and preparing the supported upgrade path to the latest stable. First step was to move to Postgresql 16. I just upgraded from Postgresql 12.5 to 16 successfully. 1. Backup the Postgresql 12.5 databasedocker exec -it <Postgres12.5_container_name> pg_dump -U <user> -d authentik --no-owner --no-privileges > /mnt/cache/appdata/backups/authentik_db_fresh_backup.dump2. Prepare the New PostgreSQL 16 DatabaseEnsure your new PostgreSQL 16 database is completely empty before restoring the new backup. docker exec -it <Postgres16_container_name> psql -U <user> -d authentik -c "DROP SCHEMA public CASCADE; CREATE SCHEMA public; GRANT ALL ON SCHEMA public TO authentik;"Bash docker stop <authentik_core_container_name> <authentik_worker_container_name> docker exec -it <Postgres12.5_container_name> psql -U user -d authentik -c "DROP SCHEMA public CASCADE; CREATE SCHEMA public; GRANT ALL ON SCHEMA public TO authentik;"3. Restore the Backup to PostgreSQL 16docker exec -i <Postgresql16_container_name> psql -U user -d authentik < /mnt/cache/appdata/authentik/backups/<authentik_db_backup_name>.dump4. Edit the Authentik server Postgresql to new IP 5. Run the Authentik Database Migrationsdocker exec -it authentik ak migrateThis command will update your restored database schema to be compatible with the new Authentik containers. 6. Start the Authentik ContainersYou can now start both containers. The core and worker containers will run on a fully migrated and up-to-date database.

My current Triliumnext docker variables are: TRILIUM_OAUTH_BASE_URL TRILIUM_OAUTH_ISSUER TRILIUM_OAUTH_ISSUER_ICON TRILIUM_OAUTH_CLIENT_ID TRILIUM_OAUTH_CLIENT_SECRET The Triliumnext login screen looks good, but the login button directs me to https://trilium.mydomain.com/ and then it redirects to accounts.google.com for some ODD reason. Anyone have some ideas why its not going to Authentik?

@Espressomatic I don't feel like waiting since the PR was submitted back in September of 2023... LOL I already use wireguard with my opnsense (road-warrior always on full tunnel) and vaultwarden is locked down to trusted internal IP ranges with NGINX. I simply want to add an additional layer of security with MFA and bring it into my existing pool of apps within Authentik for a single IdP / Auth provider ;-)

I'm now using fork: https://github.com/Timshel/vaultwarden , which does not have an issues or discussion section on the GitHub page...so I'm posting here if that's okay; These are my Vaultwarden docker container variable settings: SSO_AUTHORITY=https://authentik.mydomain.comapplication/o/vaultwarden/ SSO_CLIENT_ID=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx SSO_CLIENT_SECRET=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx SSO_ENABLED=true SSO_SCOPES=email profile offline_access My Authentik redirect_uri is regex: ^https://vaultwarden\.mydomain\.com/sso-connector\.html$ ☝️(I verified the request_uri via browser dev tools looking at header) However, when I attempt to login with SSO, I get familiar error from Authentik: "The request fails due to a missing, invalid, or mismatching redirection URI (redirect_uri)." **********UPDATE******************************** Looking at the Vaultwarden debug logs, I see what appears to be the culprit: [2025-07-26 14:05:54.038][request][INFO] GET /identity/connect/authorize?client_id=web&redirect_uri=htt Which is the redirect_uri is getting truncated. But with the Timshel fork of Vaultwarden, there is not documented variable for the redirect_uri that I can see on Github in the https://github.com/Timshel/vaultwarden/blob/sso-support/SSO.md file.... I've even tried variables 'OIDC_REDIRECT_URI' AND 'SSO_REDIRECT_URI' in the container, but the environment variable is still not being correctly passed to or picked up by the running oidcwarden (Timshel fork of vaultwarden) container. From docker console: # printenv SSO_REDIRECT_URI https://vaultwarden.mydomain.com/sso-connector.html # ANOTHER UPDATE WITH RESOLUTION: Update: Found the issue! The redirect URI in the request is http://localhost/identity/connect/oidc-signin, but this doesn't match my actual Vaultwarden domain. The Problem, Vaultwarden is sending redirect_uri=http%3A%2F%2Flocalhost%2Fidentity%2Fconnect%2Foidc-signin (URL decoded: http://localhost/identity/connect/oidc-signin) but Authentik expects the actual domain where Vaultwarden is hosted. Solution: I need to configure the correct domain in Vaultwarden settings. Add this environment variable: bashDOMAIN=https://your-actual-vaultwarden-domain.com ------------ After adding the 'DOMAIN' variable to the docker, I got past the Authentik 'Redirect URI Error'. Now I'm just weighing the master password policy for the extra vault unlock master password prompt after successfully authenticating to Authentik...

Agreed, that would make the most sense 😎. Existing PR: https://github.com/dani-garcia/vaultwarden/pull/3899

Learned that this version does not support OIDC and that I have to use this fork instead: https://github.com/Timshel/vaultwarden

Hey all! I am trying to get Vaultwarden configured to use Authentik for SSO. However, after setting all the below docker container variables and restarting the docker, I still do not get the option to login with SSO from the Vaultwarden login screen. It still displays the normal login page. SSO_ENABLED: "true" SSO_OVERRIDE_PASSWORD_LOGIN: "false" SSO_TYPE: "openidconnect" SSO_OIDC_AUTO_DISCOVER_URL: "https://authentik.domain.com/application/o/vaultwarden/.well-known/openid-configuration" SSO_OIDC_CLIENT_ID: "MY_CLIENT_ID_FROM_AUTHENTIK" SSO_OIDC_CLIENT_SECRET: "MY_CLIENT_SECRET_FROM_AUTHENTIK" SSO_OIDC_REDIRECT_URL: "https://vaultwarden.domain.com/sso/oidc-signin" SSO_OIDC_SCOPES: "openid profile email" SSO_ROLES_ENABLED: "false" ======== My Vaultwarden is behind Swag / NGINX reverse-proxy, I don't believe this impacts anything with SSO. Can someone help me fix this?

I also forced the Jellyfin login page to redirect to Authentik for authentication using Swag / NGINX with this in my jellyfin.subdomain.conf file: # --- Force SSO on login page --- location = /web/ { return 302 https://your-jellyfin-domain/sso/OID/start/authentik; }

I was able to enforce login with SSO (Authentik) and disable Jellyfin manual login, and hide forgot password using this Jellyfin custom CSS code under Branding: a.raised.emby-button { padding: 0.9em 1em; color: inherit !important; } .disclaimerContainer { display: block; } /* Hide manual login form */ .manualLoginForm { display: none !important; } /* Hide 'Forgot password' button */ .btnForgotPassword { display: none !important; } ==== I did not need to use Authentik include or explicit location blocks in my Swag / NGNIX subdomain conf file.

I would like to share my progress and an update on this. I went back to the Jellyfin 'sso-auth' plugin instead of the LDAP plugin. Login with SSO from Jellyfin using Authentik now works! Next step is to enforce only SSO logins from Jellyfin by disabling local logins. My plan is to configure: Jellyfin SSO-Auth (completed) Hide the password login UI Use SWAG (NGINX) to redirect all login attempts to Authentik’s SSO endpoint. Stay tuned...

Hey all! Is this plugin still supported in 6.12.15 and will it be supported in 7.1.x ? I recall the plugin 'Fix Common Problems' flagged it as not supported for certain versions... Also what are some alternatives to this plugin that can keep new data on cache for x days and then move it to array after x days old?

So I got the Authentik and Worker dockers configured, and I have successfully setup SSO for Immich docker app with Swag ngnx. However, when I try to follow the same methodology for Jellyfin using the jellyfin plug-in SSO-auth, I get request URI error from Authentik when trying to log in with openid. I also tried the jellyfin Ldap plug-in and I keep getting connection refused on Port 636 or 389 in the Jellyfin logs when testing within the plug-in setting. Also, it appears that the authentic docker does not have the host to contain a port mapping for 636 or 6636. When I try to add the host to container Port mapping in the docker, the container Port field is missing from the form. I prefer to use the SSO-auth plugin method (oicd), but I need help figuring out why I keep getting the request URI error. I do have the proper request URI added in the Authentik provider for Jellyfin... All my docker apps that will be handled by Authentik for SSO are reverse proxied with Swag and (ngnix). Any help or guidance would be greatly appreciated.

I am seriously considering upgrading from 6.12.15 > 7.1.4. But before I do so, I wanted to see if anyone else had an identical upgrade path that went smoothly? I currently rely on Macvlan and custom bri networks for dockers with static IP's. Also, anything out of the ordinary to call out before I move forward with upgrade?

There was no mention to clone the repo outside of just installing the Netbox docker from the app store. The compose for Netbox is correct and is defaulted to '/mnt/cache/appdata/netbox' This is how I'm going into the console of Netbox, pretty straight forward ;-)

Please take my word for it, the file(s) do not exist in that path within the Netbox docker console. I also removed and re-added docker, but same issue persists. Any ideas?

128GB 💪

@bmartino1 I still get an error when in console of Netbox and the path appears to be empty too: root@46541a6c463b:/# /opt/netbox/netbox/manage.py createsuperuser bash: /opt/netbox/netbox/manage.py: No such file or directory root@46541a6c463b:/# ls app build_version config dev etc init lsiopy mnt package root sbin sys usr bin command defaults docker-mods home lib media opt proc run srv tmp var root@46541a6c463b:/# cd opt root@46541a6c463b:/opt# ls root@46541a6c463b:/opt# ls root@46541a6c463b:/opt#

Now am still getting this after disabling Redis password in the docker config and as well as configuration.py. In the webUI I get this: In the dockers logs I get: RESOLVED the above two issues: I found two separate lines in configuration.py for Redis password that need to be commented out. BUT now when I try to login, I get this error:

I'm very interested in this project. I ran into install issues with Postgresql16 and up, 15 appears to work. Also, how come there is no WebUI link off of the docker menu; instead it just offers Console option. So I got passed the errors in the log after downgrading to Postgresql15, edited the adv. view of the docker to remove required from Redis password, and then I edited configuration.py to # the same Redis password line. I'm still unable to get to the webUI on port 8000, but I see the startup process in the log is still ongoing with a bunch of 'Applying ipam....', 'Applying dcim....'. Is the startup typically this long the first time?

Thank you! This helped me get the same issue resolved.

I had a similar issue, for me, it is related to a home-assistant unraid integration. Here is the bug issue for the it: https://github.com/domalab/ha-unraid/issues/66 Suggested workaround was using a user script to filter-out associate syslog entry not resolving: https://github.com/domalab/ha-unraid/wiki/Troubleshooting#ssh-session-log-spam

Is this plugin flagged in the upgrade assistant or fix common problems plugin if it's a known issue?