@james said: Hello @teiluj The fix is included in Cloudron version 10. Hi @james - The release of the fix with v10, I understood. But I am not certain you can share a date for when v10 will be out, or can you (I see this is the demo server already!)? OK so for the record, the following worked to re-enable the user to access the app: With a local (i.e. non-LDAP-synced) admin user on CSB Disable the LDAP sync on CSB Impersonate the impacted user on CSB While logged in CSB as the impacted user, go to profile and disable TOTP/passkey as required Logout from CSB as the impacted user Login on CSB as the local admin user Re-enable/reset the LDAP sync with CSA This would have been a lot faster, less complicated if an admin user had the possibility to reset TOTP/Passkey for other users. Could this be made as a feature request? Something like the following would be great [image: 1786714504659-ef6a2319-22e8-457d-b4ac-2dff9bd5d545-image.jpeg]

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.

Excellent! Thank you very much @joseph (and also @fbartels)! I was able to alter the mysql dump file in the appsdata directory on the server and restarted the restore. The app started and I was able to fix all other database bugs in the dump directly in the apps database which then was up and running. Now the app has been restored on the new server and everything is working again. Thanks for the support and especially the note about the /home/yellowtent/appsdata/<appid>/mysqldump location.

Fixed - https://git.cloudron.io/platform/box/-/commit/a3ee1c354cbf6789724d3fda0ad64c87e3c72ba0 . Thanks for reporting.

Right, this is already fixed now along with the mysql changes . When services are resized, they are now restarted since start.sh is making decisions based on the allocated memory - https://git.cloudron.io/platform/box/-/commit/9b0f8aea0dbf5788d653392ca83874d0aa803503

Ok, just did it. thanks

yes, direct url is working again. That was it! Applied the one line change on all three servers here and the 60 query test goes from 20/60 to 60/60 on each of them. For reference, temperror was running at 48%, 34% and 18% of inbound mail over the last 24 hours on those three. I will report back once enough new mail has come in to see where it lands. Thanks for digging into this so quickly.

Just to follow up. After more than one year I decided to move the Docker Images back to the virtual machine disk because I upgraded the vm to a instance with larger disk. I never had any issue with running docker images on a Hetzner Volume.

@paradoxbound No worries, I managed to reproduce the issue and have applied a fix. I have to reduce the batch size to 50. I have also provided a FTS status now on the dashboard to see the indexing status.

Thanks for reporting, I have fixed this now. I have also had to make the container rebuild when the memory limit is changed, so that mysql can adjust itself appropriately on start up.

@imc67 I have bumped it up to 20mb. thanks!

Hello @loudlemur Unfortunately I can't do that. Due to license constraints and other things we currently are not looking for contributions to platform code.