Yes that is fine. Just make sure to run cloudron-setup with the correct --version 7.5.2 in your case.

@nebulon great, glad it's already fixed! Then a start/stop of the app will resolve it.

@nebulon Very cool upgrade to the API Docs since the last time I looked. Like @BrutalBirdie said, one should be able to copy and paste the examples into n8n, modify parameters and run it!

@webliska said in 535 5.7.8 Authentication failed - SMTP Error: How do I send you the mail.log? You can put the mail log into https://paste.cloudron.io/ and send the URL here or send me a private message in the forum.

Hello @saivie Could you please check the app logs if the sending produces any errors?

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?

@makemrproper said in Trying to add an sshfs mounted location as a regular file system volume type in Cloudron: When trying to I am trying to add the /mnt/folder to Cloudron as a filesystem volume type, I am getting this error: hostPath must be a realpath without symlinks Just tested this and this works fine here. Is /mnt/folder a symlink? I have a fstab line to mount a sshfs into /mnt/folder . And then I just added Filesystem mount type in Volumes view.

@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.

@neki that is all good.

Makes sense Thank you