Update solved the problem. Will dig into the monitoring problem, which indeed seems to be not cloudron related. Thank you for the reply.

@firmansi You can change the memory limit in a couple of places: The service (mysql) in Services -> MySQL . Bump the limit there The app's memory limit . App -> Resources.

@robi said in Backup failed: ENOENT: no such file or directory, open '/mnt/cloudronbackup/my.uniteddiversity.coop-netcup/snapshot/app_08388b1d-12c7-42c2-b6bd-a5c5be5cfcbb.tar.gz': It's odd that backups ran fine until they didn't with that same default all this time. What would make backups use more memory over time? It would be interesting to know a little more about that, indeed.

Good to know it should work. I will try it again later. Can't reboot now in the middle of the day. Maybe something got cached in the browser then.

@girish said in Apps stopped functioning post failed updates: However this does not resolve the fact that apps seem to not be responding externally/internally. Yet again my cloudflare changed its SSL/TLS encryption mode from Full (strict) to some other setting and broke my ssl side of things causing sites not to load. Tested other domains I have and those worked so the only setting remaining was that. Fixed my issue there. @girish said in Apps stopped functioning post failed updates: Interesting solution. How did you end up discovering this ? Is this because of some local network related issue ? In terms of this the only thing I can think of is maybe getting rate limited so I had to slow down... I was updating multiple apps all at once when the updates all failed.

Probably upstream but not in Ubuntu packages

@necrevistonnezr said in Update from 7.4.3 to 7.5.2 fails on Ubuntu 18.04.4 with no notification/ clear reason.: @jdaviescoates Shouldn't the EOL of Ubuntu 18.04 last May be enough "notification", despite LTS? heh, yeah, I guess it should! This is a Cloudron I set up for others ages ago which I've barely looked at since, hence the oversight!

Thanks. I’ll give it a shot!

@Benoit /api/v1/cloudron/status is the correct path for health check. It only returns the version now and nothing else. There is no errorMessage anymore . That field was used for provisioning time status (i.e setup and restore time). That is available via /api/v1/provision/status . The errorMessage was related to errors during setup and restore and was never used to signal any post installation errors.

@girish don't know what happened but the auto-backups are working again

I try to avoid puttting screenshots in our docs because they become obsolete in 6 months. Given the amount of 3rd party services we integrate with, it's impossible for us to track UI changes across all the services. I just link to the docs like in https://docs.cloudron.io/backups/#linode-object-storage If something is really super popular, I make a "guide" with screenshots.

worked

@girish yes.

@avatar1024 there is crash in cert renewal indeed. A fix is coming in 7.5.2

Just to be clear though, this will just restart the box process which just takes a few seconds and its not an actual server reboot. A slightly bigger issue is, that the certs won't renew automatically until the fix is out, this can be done manually until that using the renew all certs action in the domains view. So if you are on 7.5 at the moment just click that button in the next few days.

@xarp in the past I had built a custom php app that did exactly what you’re asking for. A simple registration page for a Cloudron user. I plan on implementing some form of group allocation and eventually subscription/payments. If you’d like we can talk about me making you a custom version of the app

@girish Yes, all sorted, thank you for asking. Thanks to @robi's suggestion all we needed to do was the following: in terminal window for our WordPress app, at /app/code/wp-content/uploads we created a symlink (ln -s /media/ovitest ovitest) and then updated its permissions, just in case (chown -R www-data:www-data ovitest) then we could access the mp4 at https://<our_web_domain>/wp-content/uploads/ovitest/Red-cloud.mp4 Thank you very much all; we did enjoy finding the fix in the end. And of course we will make good use of it as we can now keep 10-20 GB of data, or even more, outside the WordPress data container, so out of the backup, but still reference this content on our website, which is great.

Just wanted to say I've also hit just this issue. Cleaning up the nginx app config files did the trick but I wonder if this can be avoided in the future? Or may be it has already be addressed and I'm only hitting it because of some legacy stuff from previous Cloudron version? (this instance is currently running 7.5.0 but hasn't had a fresh install in a long while).

@3246 very strange, I just tried a restore of Cloudron with SSFS now and it works. Not sure what's the best way to proceed here, but if you are blocked by this, can you write to support@cloudron.io and we can debug fruther ?

Not sure if relevant to your situation, but to bypass specific DNS entries you can also do: local-zone: example.com typetransparent local-data: "my.example.com A 172.18.0.1"