Hello @Shai The second level domain, also known as @ in most DNS providers e.g cloudron.io has a different propagation time then third level domains aka. example.cloudron.io. This could take up to 24 hours or more, depending on the hosters default TTL for the domain or what you've set. Might even be resolved now when you retry it after 7 hours.

@james make sense! thanks for your thorough explanations

Thanks for reporting. I have added a rule in the firewall for outbound turn - https://git.cloudron.io/platform/box/-/commit/83d7535d84791cf27e0d1ded5fe700233947a1d9

Hello @aurelien-c When I run: # Ask Cloudflare about the PTR dig -x 164.172.73.196 +short @1.1.1.1 # Ask Google about the PTR dig -x 164.172.73.196 +short @8.8.8.8 I get no answer. This indicated that no PTR record has been set. From the documentation https://docs.cloudron.io/email/#ptr-record The PTR record is set by your VPS provider and not by your DNS provider.. For example, if your server was created in Digital Ocean, you must go to Digital Ocean to set the PTR record. @aurelien-c said in "Email not configured properly" with PTR4 issue: The troubleshooting section of the docs do not appear to bear fruit about this. Did you read the docs.cloudron.io/email/#ptr-record or docs.cloudron.io/email/#troubleshooting? And, did you configure the PTR in your Hoster?

@p44 Perfect Thanks for the follow-up.

@Beardmancer said in Restore one app's backup to another existing app?: I'm curious to know what plugin you prefer? I'll put it on my list for next time. You found it then. Only other I've used is Updraft Plus export -> import.

It's going well so far in my testing. Updated about 6 domains with the newer DKIM selector today. It'd definitely be nice to have this configurable though in the UI so we can change it in one sweep to a new DKIM selector of our choosing.

@girish I had the same problem with 2 apps (one recently automatically upgraded[n8n] and another installed now [archivebox] and both reported "Starting" in the dashboard despite working URLs (status really = "Running'). systemctl restart box cleared up the dashboard. But in checking box.log, I can see where about 2 days ago, box:apphealthmonitor app health {running, stopped, unresponsive} stopped running. I did not see an error, just nothing in the log. After systemctl restart box, the entry began appearing in box.log. The only unusual aspect of my Cloudron is that I have been experimenting with a privately hosted app. FYI, that app was "Running". Hope this is helpful in figuring out what is going on.

Hello @leemuljadi I am happy to hear this worked out as intended. If there is anything we could improve in the documentation please let me know.

Makes sense Thank you

That is very abnormal. Please send a mail to support@cloudron.io and link this topic in your ticket.

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