Thanks for the repro! Fixed in feaf73fb7cd60f94d4261c036146a0e8a7bfbf4d

The mail relay requires STARTTLS - https://docs.cloudron.io/email/#relay-outgoing-mails . Is that enabled in Proxmox?

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

@girish - thanks for this. I am looking forward to try these changes. Can I ask: has polling/batching DNS updates been considered or is this simply not possible in this situation? Thanks again,

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

@nebulon said: The demo is really just one shared Cloudron so it very much depends on what other users currently clicking around are doing So I though too - I have seen/had my fair share of installed and uninstalled apps on the demo server - but being logged out every few seconds is a new experience. I am also under the impression that concurrent sessions for the same user are possible. Is this different on the demo server (i.e. am I potentially logging someone out if I log into the cloudron server) or is there a max number of parallel running session? The alternative is someone/something having scripted a "logout from all"/clearing sessions (as well as uninstalling apps) which I guess is more likely. Unfortunately, this renders the cloudron demo server simply useless at times. Nonetheless and to avoid any misread: I am much appreciative of having a demo server to test the apps or debug once in a while - thanks for this.

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

Hello @teiluj We are already started rolling out Cloudron 10 slowly as a pre-release update. Maybe you can check if you could update your server already.

Hello @odie These log lines are normal. Glad to read a simple service restart resolved the issue.

@nebulon Aboslutely nothing you can do on your side about that, limitation of windows. I tried to use NFS shares from the cloudron server but windows only supports NFSv3 not NFSv4 and that results in dynamic ports having to be opened on the firewall or a host of services have to be assigned static ports. Even after all that the NFS mounts on windows also don't consistently remember their passwords (even when checking the boxes that indicates remember password). I have given up and done what I didn't want to do which is install samba on the cloudron host and serve the directory via CIFS from there. All the clients are connected via a samba user and it will persist accross reboots without issue. The biggest downside is that I am now running something extra on the cloudron server that isn't intended to be there but until there is some way to host samba as an app or some other app on cloudron that supports cifs I don't see any way to work around the issue of needing windows clients to be able to write to a location via native filesystem apis that apps running on cloudron can also access without depending on a server other than cloudron itself to host those files.

Hello @gautam8459 You have provided none of the required information, and thus we can't help at all. Please provide the output of cloudron-support --troubleshoot and describe your set up more detailed. You can also upload the log file of the failing restore at https://paste.cloudron.io/

Works here. Can you check the value with the instructions at https://forum.cloudron.io/topic/2969/how-can-i-increase-the-maximum-size-of-an-email-with-the-build-in-smtp/2 . Maybe try restarting mail server? Services -> Restart ?

hi @nozy i replied from support. Using the backup should be straightforward . https://docs.cloudron.io/backups#move-cloudron-to-another-server is the necessary docs. The license will automatically move, yes. (it moved with the domain name during migration and is not IP based) Feel free to ask any question here and we can help.

The opportunistic-TLS point is fair and I'll concede it — on port 25 a weak cipher beats a plaintext fallback, and internet.nl's model implicitly assumes an enforcing world (DANE, MTA-STS) that doesn't match how inbound mail actually works. One correction on the Node side though, because it affects the "we track Node's defaults" reasoning. Read off the running mail container: # node -p 'require("tls").DEFAULT_CIPHERS' ...:ECDHE-RSA-AES256-SHA256:DHE-RSA-AES256-SHA256:HIGH:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!SRP:!CAMELLIA That list names 12 suites explicitly and then ends with the HIGH: catch-all, which expands it to 58. Every flagged suite arrives through the catch-all — not one of them is named in Node's own list: with HIGH: without ECDHE-ECDSA-AES256-CCM8 yes no ECDHE-ECDSA-ARIA256-GCM-SHA384 yes no ECDHE-ECDSA-AES256-SHA yes no So upgrading Node doesn't move this. The list has had the same shape for years, and Node 24 in Cloudron 10 will produce the same test result that Node 22 does today. And the compatibility argument, while true, covers a narrower set than the whole list. The long tail of old MTAs lives on the CBC-SHA1 suites. ARIA is a Korean national standard and CCM_8 is a short-tag variant from the IoT world — no MTA in the wild speaks only those. Just noting where the observation stands; the trade-off is yours to make.

Fair enough — you're right that it isn't exploitable. The client sends signature_algorithms and the server picks from the intersection, so nothing modern ends up on SHA-224 unless it explicitly asks for it, which is exactly what my test did. Where it still bites is compliance rather than security: organisations measured against the NCSC guidelines get it reported on every scan, and internet.nl states they expect to reclassify it from phase out to insufficient in a future update — at which point it stops being a recommendation and becomes a failed subtest. That's the only thing that really changes the calculus, and whether it's worth pre-empting is your call. Same algorithm turns up on the mail server for the same reason, which is in the other thread.

That makes sense, I hadn't looked at it that way. The page cache gives the memory back and shared_buffers doesn't, which matters a lot more on a box with thirty containers than on a dedicated database server — and the 25% guidance assumes the latter. What might still be worth it is effective_cache_size, which doesn't allocate anything and only tells the planner how much cache it can expect. On three of my servers with 8, 8 and 10 GB limits it reads 4GB everywhere, straight from boot_val — it doesn't track the limit at all. Deriving that one from the memory limit would improve plan choices without reserving any RAM. No rush on this one, it's much smaller than the MySQL case. It just seemed inconsistent that the buffer pool now follows the memory limit while the planner hint doesn't.