Cloudron Forum

@charlesnw I am running open terminal but in another container, i think it's best to maintain Open WebUI with original package

@sponch Still, the plugins can't be issues no matter the new major stable release exist, since the plugins not always part of NC , always test the plugins in clone one, before using in production version

I noticed there's already a new Nextcloud release at version 33, and a while ago I saw it had appeared on Cloudron's Git repository. But as of now, I see that the latest Nextcloud update hasn't been carried forward. May I know if there are any issues or obstacles with rolling out the latest Nextcloud update?

I noticed that the latest OpenWebUI update includes a new feature called OpenTerminal, although I see that the OpenWebUI app on Cloudron hasn't been updated to this latest version yet. My question is: is it possible that when Cloudron updates OpenWebUI to the latest version, it will include OpenTerminal?

@nebulon it works...thanks cloudron team for fast update

@joseph I see that Open WebUI has release 0.8.3 with bug fixes

So i guess anyone who reads it better wait for next update

After the latest Open WebUI update, I'm experiencing issues with the application failing to start. I've already verified that CPU, memory, and storage resources are more than sufficient.

I'm using LDAP for authentication to connect to my Cloudron instance (hosted on a separate machine). My setup includes the latest version of Cloudron running on Ubuntu 24.04.

I've been using Open WebUI on Cloudron for the past two years without any issues, but this is the first time I'm encountering this startup failure. The application consistently fails with the following error logs:

Feb 17 13:10:51 await get_all_models(
Feb 17 13:10:51 File "/app/code/backend/open_webui/utils/models.py", line 305, in get_all_models
Feb 17 13:10:51 get_function_module_from_cache(request, function_id)
Feb 17 13:10:51 File "/app/code/backend/open_webui/utils/plugin.py", line 355, in get_function_module_from_cache
Feb 17 13:10:51 raise Exception(f"Function not found: {function_id}")
Feb 17 13:10:51 Exception: Function not found: autolearn
Feb 17 13:10:51 2026-02-17T06:10:51Z
Feb 17 13:10:51 Application startup failed. Exiting.
Feb 17 13:10:55 ==> Ensure directories
Feb 17 13:10:55 ==> Copying static files
Feb 17 13:10:56 ==> Loading configuration
Feb 17 13:10:56 ==> Cleanup old ollama models
Feb 17 13:10:56 ==> Ensure NLTK_DATA directory at /app/data/nltk
Feb 17 13:10:56 ==> Setting permissions
Feb 17 13:10:56 invalid command \".
Feb 17 13:10:56 ERROR: invalid input syntax for type json
Feb 17 13:10:56 LINE 1: UPDATE config SET data= E'{"version":0,"ui":{"default_locale..."

Has anyone else experienced this issue?

@scooke I use Google Analytics

I have found the way to enable the chat hub, just go to filemanager in Cloudron, open env.sh file and add this "export N8N_ENABLED_MODULES=chat-hub" and you will see the chat module in left sidebar

I already upgraded n8n to the latest version, it went smooth and no significant issues, but one feature that i look for n8n chat hub dont appear in this upgrade,anyone experience differently than mine?

Is there any update regarding to this major next update?I see in Cloudron git the update is already started but remain on hold

It works now

I have tried the best I can according to Cloudron documentation when setting up Cloudron OpenID with Cloudflare Zero Trust, even I delete and create new Client ID but always i got this message

"Failed to verify oidc token with fresh keys
undefined"

What Should I do ?

hai @guacadmin , are you using ubuntu in Alibabacloud?

@nebulon I’ve actually suggested this before: what if cloudron team added a field so that Cloudron admins like me could include a link or instructions for users on how to reset their LDAP password at the location where their user data is stored? I assume not everyone using Cloudron uses Cloudron itself as their LDAP server—some may use a separate external LDAP server. While adding an extra API to trigger password changes or resets on the external LDAP server is indeed a good idea, it might take some time to implement. So, I was just thinking of a more practical, immediate solution: letting each admin using Cloudron take responsibility for providing their own reset link or instructions.

@girish awesome, i believe this will be included in next update.

@jdaviescoates thanks for the citation, yes i refer to that. So, I’ve already upgraded to the latest Cloudron version, 9.07. Now, Cloudron A pulls its user data from Cloudron B via LDAP. I tested the password reset function on Cloudron A by clicking “Reset Password.” After clicking, the password reset window did open as expected. However, after entering the email and clicking the reset button, I never received the password reset email—even though the interface displayed a success message stating that the email had been sent.

Previously, in Cloudron version 8, when I clicked the “Reset Password” button for a user authenticated via LDAP, the system correctly responded with an error message indicating that the user’s authentication source is external (e.g., “The authentication provider for this user is not managed by this Cloudron instance”). Now, in version 9.07, that check seems to be missing or bypassed—instead of rejecting the request early, it proceeds and falsely reports success, even though no email is actually sent.

@nebulon Please don't forget bugs in reset password for LDAP sign in too yah