Quick update - The issue had nothing to do with Cloudron server and everything to do with the Nginx Proxy Manager host sitting in front of the Cloudron server. Good time to mention that NPM in front of a Cloudron server is not an officially supported Cloudron setup. Yet, with this being said, once Websockets relay was enabled on NPM proxy host, everything fell into places. Many many thanks for @nebulon and the cloudron team for their support as always.

Sorry for this delayed response. Just wanted to confirm that everything worked right after contacting you. Thank your very much for this quick reply and for your great support. Appreciate it.

The issue here was server DNS related . The upgrade to Cloudron 8 left the system in a broken state where DNS was not working. Fixing up /etc/systemd/resolved.conf to have DNS servers resolved the problem.

Just purge contents of the folder or delete the folder and recreate it with the same permissions. Other bits of Linux sometimes put logs there.

node.js has a "happy eyeballs" quirk. This causes premature network errors when there is no ipv6 and ipv4 is slow. I have fixed this in https://git.cloudron.io/cloudron/box/-/commit/aefa481c43603d284346d58497b6ff5b462efd88

Hello and thank you for your feedback. I put this idea on hold for the time being after learning that Okta has had several security breaches in the past. I am reconsidering which solution I want to use at all. Thanks anyway

Thanks!

There is currently no generic way to do this from Cloudron side. Depending on your backup storage you are using, you probably can download directly from there.

@jdaviescoates said in OnlyOffice is unresponsive after update to 1.18: @imc67 said in OnlyOffice is unresponsive after update to 1.18: config key config key? Secret (key) in the Config folder

thanks, made a snapshot and got rid of the most important/obvious logs, cheers Unsure about the 90 days though, many of my servers have logs until the day they were created.

As far as I understand those CVEs they are not relevant in that context. For the first, we don't use those affected configs and the second is for the ssh-agent. Given that the Ubuntu team usually knows what they do and are working closely together with upstream projects, there seems no need here to go beyond their recommendations of versions they push out via security updates.

@jdaviescoates I am interesting to figure out the workaround if I could just define the new SMRP port in the server configuration. Alternatively, Is it possible to implement some kind of port forwarding rule that can circumvent the port 25 block?

It worked! Thanks!

And I would appreciate if this fix get published soon. I need to update it, because I accidently did not renew but delete the API key and there is no way back. (Really not "no bullshit" like years ago @gandi) @girish

There is no artificial limit or so. It depends on the resources your server has and here on the capacity and maybe speed of the filesystem.

If Hairpin NAT is not working, please refer to https://docs.cloudron.io/troubleshooting/#hairpin-nat

@fbartels So sorry, but was short on time and opted to reinstall the cert. to get back to what seems like normal - and so, I have no information to share in-terms of troubleshooting. That said, and if /or when this happens again, I'll take the time to properly investigate NB, for what it's worth, I am using Cloudflare API key, of which has always worked without issue in Cloudron, though for some unknown reason, the cert appears to have expired and would no longer renew. And so I performed as roll-over oin the API/Key side of things, then reissued, and everything appears to be back to normal

Welcome here @mistahgreek ! See https://docs.cloudron.io/backups/#old-local-backups for this issue

Glad it worked out in the end. With the next release we will have a better error handling to find those issues faster.