@xarp Cloudron does not update or switch the kernel or enable any kernel features, no . There is no code for this. Could it be your VPS provider has switched this by mistake?

Seems like a valid bug, we can take a look after Cloudron 10.0 . Logged it at https://git.cloudron.io/platform/box/-/work_items/906

yes, correct. the update will replace the file and it will continue to work after the update.

this poor little sausage staples everything you try to install. Doesn't have anything better to do or hasn't gotten anything shit in life, and wants to spoil everything for others again IP and Location Firefox Linux / desktop Berlin, Germany IP: 2001:9e8:1634:7600:1f60:5454:e46c:9e83 31 August 2026, 16:16

@girish said: I have added a 429 check and waiting for "retry-after" in e532401510dc64570f5c0d3d9972429da6268e0f . I guess that's the best we can do on our side . Hi @girish Thanks for this - I appreciate your attempt in trying to help with this. The related server experiencing the issue has been updated to v10.0.2 recently and it seems that this change was part of the update. However, the patch has made the situation worse actually. Since the update, I have been locked out of the related server because the "my." record did not successfully update (or only sporadically, before being scrapped from the DeSEC domain name record table entries shortly after) Attempts to manually add the record to DeSEC entry were also impossible because the DeSEC account was also locked out behind never-ending permanently-resetting with growing threshold waiting times. Not too sure how the Cloudron side is handling this though: It seems like the Cloudron DNS update requests are still batched. e.g. when one record needs updating, all records are updated, no matter if they actually need to. Still seem like Cloudron does not take into account whether or not a record was successfully update. e.g. do DNS record udpate -> if it works great; if it does not, carry on with the next record (thus leaving previous record in limbo) Update task starts at H=x and the next relevant entry is at approx H=x+8 (I suppose this could be due to the threshold retry waiting time) At the moment, the errors on the Cloudron server log oscillate between: reason: 'External Error' reason: 'Database Error' (-> sqlMessage: 'Too many connections',) HTML: 429 too many request HTML: 502 Bad gateway So currently, I feel this is a bit of a mess and I am sorry that this has come down to this. Any idea how this could/should be dealt with? I remain convinced that a more individual approach to DNS record update as well as switching DNS update method to batch HTTP API call would alleviate part of this/the whole issue i.e. only update records that needs updating, prioritze record update ("my." top prio) But I also acknowledge that this seems very specific to DeSEC and might not fit in Cloudron's development plan I hope that this makes sense. Otherwise we will be obliged to move on from DeSEC. @milian.hackradt May I ask what DN server are you using instead of deSEC?

@girish said: @avatar1024 said: Does that means one cannot use an external relay to replace the built in SMTP server if we use mailing lists (or the mailbox + forward implementation in Cloudron 10) - given most likely senders and mailing lists members with use random email providers? Yes, with a typical smart host / relay you cannot keep the original sender on list/forward delivery to Gmail/Posteo/etc. I want to mention that this is for the forwarding feature. Forwarding requires From address to be preserved. A mailing list behaves differently. It rewrites From/Reply-To etc and makes itself the originator of the email. This feature was never implemented in Cloudron. The forwarding feature was incorrectly labeled as mailing list and this misnaming is fixed in Cloudron 10. I guess we have to look into Distribution lists/mailing lists for the next releases, if you are interested in this. But the From address will change, not sure if it will work for your use case. It's usually meant for group@example.com or list@example.com style workflows. Thanks Girish, and yes a mailing list feature will be useful for some of my use case. I guess the point here is that it's a shame there isn't a way to use an external relay as a blanket replacement (i.e. covering all email features including forwarding) to the built-in SMTP server cause those services have added features to ensure reliable delivery (say when the server has a bad IP rep and gets regularly blocked notably by Microsoft stupid IP range blacklist approach).

This is fixed for the next patch release with https://git.cloudron.io/platform/box/-/commit/cd4bb20590899618edc4aff4b1117c81567f0e92 Thanks for the report!

Thanks for your prompt response @girish.

Thanks for the report @d19dotca . It's fixed for 10.0.2. The issue was that when having multiple internal forwards, sieve was adding multiple headers. The haraka code headers.get() was concatenating all the headers with '\n' and this caused a crash since I wasn't expecting haraka to concat it this way. There is a get_all() API which returns an array and I pick the latest forwarder from there.

@girish Hi, thank you. That worked perfectly. Not sure how many people would need that function?

With Cloudron 10, the forwarding logic is based on sieve. So, it's identical to roundcube.

The core issue was a quoting problem. It was mistaking "-" as an argument instead of a folder name. Fixed in https://git.cloudron.io/platform/box/-/commit/04adf5de3470a944cf811a23613bceb9ea520b38

Thanks for the repro! Fixed in feaf73fb7cd60f94d4261c036146a0e8a7bfbf4d

@james today it was only one, lets see, maybe it was a glitch after all

Thanks for the report. I have fixed this with 1cd0140808ccaadc665e9f06b3910a8abbbdc167

I do not know how but I did not receive any notifications about these replies and so I am only discovering them now - thanks for the replies! @james said: Although not intuitive and not documented there is a way to get access to such a user. If user james has a passkey configured, an admin can use the Impersonate user function to set a temporary password. You can use the username and that temporary password to get access to that user account without the need for TOTP or passkey. Then you can disable the TOTP/passkey. This is indeed the way we have been doing until now, but this is hardly scalable and does give the best impressions/feelings for a first time user having an issue at onboarding. It is a solution nonetheless @nebulon said: We can put you on the early update list, but we have found some regressions already, mostly in UI but also with the mail indexer features introduced. So it is not without risk, depending on which features you use. If you want though write a mail to support@cloudron.io with the dashboard domain of that Cloudron. Thanks for the offer - I might get in touch in the next few hours. I suppose if mails/mailboxes are not used on the related server then regression related mails should not be an issue hopefully.

Hello @ninja3 The documentation URLs have changed a little over the time. Here you go: https://docs.cloudron.io/apps#storage

This is now harmonized to username || email (the email is only shown for new users who have not yet set a username) https://git.cloudron.io/platform/box/-/commit/67d7f99da8d4d5e962ddf43b27c3c2861c782de4

This is fixed for Cloudron 10 with https://git.cloudron.io/platform/box/-/commit/2c1e772f456c5d25a9a2175fb1d6efddec8a7a4f