Makes sense Thank you

here too, having this problem since about 10 days... little bit annoying...

What's strange about this to me is I seem to be unaffected (so far at least), and I'm looking in Cloudron mail pages quite frequently. Not sure why but I am throwing this out there in case it has something to do with the region IP of the Cloudron servers? I'm located in Canada, in case that matters at all. I just wonder if there's a pattern for this perhaps with certain countries affected more than others, etc. Though I guess ultimately if Cloudron isn't properly accounting for blocked connections to Spamhaus and seeing a blocked connection as a listing, then that should still be fixed in the code if that's true. Sorry, ignore me I think, as I misunderstood the problem. I thought this was around Cloudron detecting that the IP of Cloudron was on the blocklist, but that would have no bearing on rejecting emails so I think I misunderstood. Sorry about that.

@Njara When I run the dig NS cofident.net @127.0.0.150 on one of my Cloudron servers, I get. dig NS cofident.net @127.0.0.150 ; <<>> DiG 9.18.30-0ubuntu0.24.04.2-Ubuntu <<>> NS cofident.net @127.0.0.150 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 27068 ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 1232 ;; QUESTION SECTION: ;cofident.net. IN NS ;; ANSWER SECTION: cofident.net. 294 IN NS dns102.ovh.net. cofident.net. 294 IN NS ns102.ovh.net. ;; Query time: 0 msec ;; SERVER: 127.0.0.150#53(127.0.0.150) (UDP) ;; WHEN: Fri May 23 12:58:07 UTC 2025 ;; MSG SIZE rcvd: 86 This section is missing on your part: ;; ANSWER SECTION: cofident.net. 294 IN NS dns102.ovh.net. cofident.net. 294 IN NS ns102.ovh.net. Now I am looking into your generated details https://paste.cloudron.io/imomagiruq

@mathieuepitech Great analysis! @staff will be very interested about this for further improvement to circumvent such scenarios.

@skeats you could attempt it yourself. The app is already broken so what can go wrong. There is no guide for a manual restore since this is something that should not be necessary. But in this case, sadly is. If you are not comfortable doing the following, you can contact support@cloudron.io and link this topic in the request. But you will still need to upload the backup to the cloudron server into a given location from the support. Now to the gist of it. The idea would be to install a new Lampstack app. (What is lampstack? Do you mean the LAMP app? Or is this a custom app? I just assume now you are talking about the LAMP app) Copy the extracted backup to your Cloudron server e.g. /tmp/manual-restore/ In that backup included is the Database as an .sql file and the /app/data/ files. To import the Database you would need to follow either https://docs.cloudron.io/guides/import-mysql/ and then copy all files of /tmp/manual-restore/ app-backup/data/into/home/yellowtent/appsdata/APPID/data/` This would be the "manual" way.

The first thing to do would be to update to the latest Cloudron version. Version 7.7 was released over a year ago. It doesn't look like an SSL issue though. Where was the Wordpress site you are trying to restore from? The same Cloudron or a different server? If it is a different server it might make more sense to install the LAMP app, extract the files to /app/data/public (checking that the files are owned by www-data), uploading the database dump via PHPmyadmin and then amending the database details in the wp-config file.

This got fixed after rebooting the server and repairing all apps. For some reason, the server ran out of file descriptors

Backups can only be configured by the superadmin/owner (the first user you created) . Looks like you are the admin

hey @CadeHenschen there are very specific documentations and step-by-step guides for distribution upgrades: See here: https://docs.cloudron.io/guides/upgrade-ubuntu-20/

@BrutalBirdie think you missed Edit2: Yep its works fine now.

Thanks for the insight and glad it worked out for you in the end!

@affinity @girish as in set them a global profile which then get picked up by any apps via ENV VARs? Then you'd just need an app restart.

Thinking about it some more, changing the dashboard domain before the IP switch is probably not the best idea as it would require an A record change in the DNS. The dry-run method would appear to be the best way to go.

Reinstalled from a backup. I lost a few apps but the critical one are back with all data. This post can be closed. Thank you all for fast replies.

This most likely just looks like a port forwarding issue. Are port 80 and 443 forwarded properly to your VM?

Just started reading your topic and as I read I add comments @jtippetts said in Need help fixing my Cloudron install. Probable database issue.: I was following ChatGPT Oh, no @jtippetts said in Need help fixing my Cloudron install. Probable database issue.: Then I installed mysql workbench onto the computer in my office that is running cloudron Nothing should be installed alongside Cloudron. Cloudron can be viewed as a Server Distribution like Ubuntu itself. You would not install CentOS next to Ubuntu. This should only be done if you know 100 % what you are doing. And since you wrote you followed ChatGPT, I assume you lack that knowledge Let's take this as a learning. Before following ChatGPT, who only has a vague Idea of Cloudron, come here, the Forum You can ask almost anything here and people are happy to help. Adding to that, other people will learn from your questions as well! Win-Win for everyone! What you should do now? Well, you could tinker and try to make it work? But I agree with @timconsidine, his advice is safe and sound and will prevent some headaches for you