Cloudron 9.0 (beta) bug reports
-
@girish Thanks! After running
sudo -u yellowtent cp -aRlv /media/WD4TB/CloudronBackup/snapshot/mail /media/WD4TB/CloudronBackup/2025-11-10-230001-644/mail_v9.0.7
without error, backups went through without error, as well.
Is there something that can be done to prevent such an error? -
Mostly stable yes, we are still busy fixing small things and the next patch release is just around the corner and after that we likely will start pushing it out slowly for autoupdates as stable.
-
-
@firmansi said in What's coming in Cloudron 9:
@nebulon Please don't forget bugs in reset password for LDAP sign in too yah
not sure I get what you mean by that. Is there some bug somewhere and if so do you have more information on that?
-
J jdaviescoates referenced this topic on
-
@nebulon I think @firmansi is referring to this https://forum.cloudron.io/topic/14359/cloudron-9.0-beta-bug-reports/87?_=1762939432122 (not that that is particularly clear to me)
@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.
-
ah thanks for the clarification. We haven't looked into this yet. Given that LDAP has no such built-in feature, we probably need some extra API to trigger a password reset on the directory provider (which will of course then only work if it is also a Cloudron). For that case though I think the better approach would be to somehow make that work with OpenID instead of LDAP, but no code has been written for that either.
-
Possibly a bug - Maybe more of a specification/documentation situation.
I updated one of our servers from v8.3.2 to v9.0.7 yesterday. The overnight S3 backup to a local device failed with the following error:
Backup endpoint is not active: Error listing objects. code: undefined message: self-signed certificate HTTP: undefinedUp until now, the server was configured to backup to a s3-v4 compatible storage location using
httpsand allowing self signed certificate.While troubleshooting, changing the s3 endpoint from
httpstohttpand updating the cloudron config accordingly resolved the issue and allowed for backup to proceed.
To note:- the (local) address and port of the S3 endpoint have not changed
- I regenerated the self signed certificate and made another attempt but got no luck here either.
I am not clear whether
httpsid part of the s3 specifications or not. However,httpswith S3 worked fine with 8.3.2 so it is:- either a bug in v9.0.7
- or a change / normalization within cloudron for which a more meaningful error message (or form validation) and/or documentation would be helpful.
Hopefully this helps.
-
@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.
-
Possibly a bug - Maybe more of a specification/documentation situation.
I updated one of our servers from v8.3.2 to v9.0.7 yesterday. The overnight S3 backup to a local device failed with the following error:
Backup endpoint is not active: Error listing objects. code: undefined message: self-signed certificate HTTP: undefinedUp until now, the server was configured to backup to a s3-v4 compatible storage location using
httpsand allowing self signed certificate.While troubleshooting, changing the s3 endpoint from
httpstohttpand updating the cloudron config accordingly resolved the issue and allowed for backup to proceed.
To note:- the (local) address and port of the S3 endpoint have not changed
- I regenerated the self signed certificate and made another attempt but got no luck here either.
I am not clear whether
httpsid part of the s3 specifications or not. However,httpswith S3 worked fine with 8.3.2 so it is:- either a bug in v9.0.7
- or a change / normalization within cloudron for which a more meaningful error message (or form validation) and/or documentation would be helpful.
Hopefully this helps.
-
@firmansi I have fixed this now in https://git.cloudron.io/platform/box/-/commit/29e2be47d0da86e77105db47d6c73b601c0fc472 . I think what you meant is below correct?
-
ah thanks for the clarification. We haven't looked into this yet. Given that LDAP has no such built-in feature, we probably need some extra API to trigger a password reset on the directory provider (which will of course then only work if it is also a Cloudron). For that case though I think the better approach would be to somehow make that work with OpenID instead of LDAP, but no code has been written for that either.
@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.
-
Possibly a bug - Maybe more of a specification/documentation situation.
I updated one of our servers from v8.3.2 to v9.0.7 yesterday. The overnight S3 backup to a local device failed with the following error:
Backup endpoint is not active: Error listing objects. code: undefined message: self-signed certificate HTTP: undefinedUp until now, the server was configured to backup to a s3-v4 compatible storage location using
httpsand allowing self signed certificate.While troubleshooting, changing the s3 endpoint from
httpstohttpand updating the cloudron config accordingly resolved the issue and allowed for backup to proceed.
To note:- the (local) address and port of the S3 endpoint have not changed
- I regenerated the self signed certificate and made another attempt but got no luck here either.
I am not clear whether
httpsid part of the s3 specifications or not. However,httpswith S3 worked fine with 8.3.2 so it is:- either a bug in v9.0.7
- or a change / normalization within cloudron for which a more meaningful error message (or form validation) and/or documentation would be helpful.
Hopefully this helps.
-
Trying to install an app that utilizes Cloudron’s user directory but unable to restrict access to specific users or groups.
-
J joseph referenced this topic on
-
Hi all! Congrats on v9!
One bug I discovered so far - Backup Sites is completely missing from Backups -> Sites and only displays the latest System backups?
-
Hi all! Congrats on v9!
One bug I discovered so far - Backup Sites is completely missing from Backups -> Sites and only displays the latest System backups?
Update: I can briefly see 'Backup Sites' if I refresh the page quickly, however it disappears and only displays the above screenshot.
Browser console issue;
-
Update: I can briefly see 'Backup Sites' if I refresh the page quickly, however it disappears and only displays the above screenshot.
Browser console issue;
-
@dylightful are you on 9.0.10 ? I thought we fixed this bug.
Can you give the output of
mysql -uroot -ppassword -e "select schedule from box.backupSites"(run this on server via ssh, please).@girish said in Cloudron 9.0 (beta) bug reports:
mysql -uroot -ppassword -e "select schedule from box.backupSites"
Yep version 9.0.10;
Command response below. Interestingly the backup looks to have been successful, however I still cannot see the 'Backup Sites' section of backupsroot@my:~# mysql -uroot -ppassword -e "select schedule from box.backupSites" mysql: [Warning] Using a password on the command line interface can be insecure. +--------------+ | schedule | +--------------+ | 00 00 * * * | +--------------+ -
@girish said in Cloudron 9.0 (beta) bug reports:
mysql -uroot -ppassword -e "select schedule from box.backupSites"
Yep version 9.0.10;
Command response below. Interestingly the backup looks to have been successful, however I still cannot see the 'Backup Sites' section of backupsroot@my:~# mysql -uroot -ppassword -e "select schedule from box.backupSites" mysql: [Warning] Using a password on the command line interface can be insecure. +--------------+ | schedule | +--------------+ | 00 00 * * * | +--------------+@dylightful thanks! fixed in https://git.cloudron.io/platform/box/-/commit/c5f97e8bb0368e515027a33721c3b4002de54ff6 . Yes, it's a UI issue and not a backend problems. The UI had a bug parsing that cron schedule (not sure why it has a double space but maybe there was a bug in some old UI).
-
@dylightful thanks! fixed in https://git.cloudron.io/platform/box/-/commit/c5f97e8bb0368e515027a33721c3b4002de54ff6 . Yes, it's a UI issue and not a backend problems. The UI had a bug parsing that cron schedule (not sure why it has a double space but maybe there was a bug in some old UI).
@girish Thank you! Looking forward to the next update!
