Strange indeed, but I blocked the VPS Port 25. Whilst blocked, I restarted Kuma and Tiny but to no avail. All up and running now with 25 unblocked.

@girish Are you saying that the user manually updated the node version, which I assume is the one that Cloudron that installed, and it installed that version so that it works, but then had this issue because they did something that they aren't advised to do (which is manually update)??? It might be worthwhile to highlight the fact (on the homepage or in the install instructions) that Cloudron manages the VPS for the user so that new users don't keep doing this, _running apt-get update on their own!

This brings up a good point.. for the power users out there, there could be an un/official guide on how to mindfully and safely run other services alongside, provided Cloudron services take priority. It would certainly make things more efficient and less blackbox. No support required, yet also a useful link to point folks to who will do it anyway. Many birds, one stone.

@warg Yes, that crash happens when the server becomes unresponsive . So, the code restarts itself. If it happens often, it's something to investigate. But the root cause can be network or VM related.

And I have deleted Jitsi for the moment. Not being used much currently. Will reinstall when I have time to get my head securing it. So will close this now.

@BrutalBirdie great suggestion, thanks for that!

@girish Yes

@TheNils If you write to us on support@cloudron, I can debug further. It's not clear what's going on.

@DeBossNow The content is based on the app. In the docs screenshot, it's an emby installaton. Where in yours it looks like it is mastodon app. What is shows is just the contents of the /app/data directory. Only the files you see above are editable. If you want to see application files (source files), you have to use the web terminal - https://docs.cloudron.io/apps/#web-terminal . Note that application files are readonly and cannot be changed.

@DeBossNow I am glad you got it resolved, but just to clarify: The MX record is for incoming email. It needs to be set to any domain name that resolves to your server, i.e. has a valid A record. If both my.currentdoain.de and currentdomain.de resolve then you can use either for incoming mail. The mismatch was not with the MX record but between the mailserver domain set in Cloudron and the PTR record of the server. At no point did I or anyone else tell you to change the MX record, and no, the PTR error had nothing to with the MX record. I can therefore only assume that you interpreted MX as being something it is not. For outgoing mail you need a valid PTR record that matches the mailserver domain. You also need a valid SPF record and a valid DKIM entry. Because you set up Cloudron via the Linode app you have presumably told Cloudron to use Linode DNS, which is why it is updating / overriding certain settings. If you do not want it to do that you need to set DNS to manual for the resepctive domain(s). The bottom line is: The PTR record and mailserver domain have to match. Where you make the changes depends solely on the domain you want to use for email, i.e. where the entry needed updating to match. Btw, I stated every time that you needed to check / update the mail domain in Cloudron, not in the Linode dashboard.

@DeBossNow it would really help if you could give more context on what you refer to when pasting plain text from presumably the Cloudron dashboard. If this is somewhere from the app configure UI, is the app in error state or which state is it in? Is the repair button enabled for that app and if so, have you tried to click that?

@girish I recall you making that run automatically.. Should it run more frequently?

Thanks for the hint, I have added all the supported ones to that list now https://docs.cloudron.io/installation/

@ccfu @warg TIL that OpenVZ stands for Open Virtuozzo ! From https://en.wikipedia.org/wiki/OpenVZ . Added to our docs page then.

I had a similar problem recently. Here's what I had to do in order to be able to programmatically update DNS records for a domain in Google Cloud DNS: verify domain ownership: https://cloud.google.com/endpoints/docs/openapi/verify-domain-name. I did this by inputting a special DNS TXT record into DNS for the domain. in my case, I was using a Google Cloud Service Account with Terraform (not Cloudron) to modify DNS records in Google Cloud DNS, so in additional to verifying domain ownership, I had to actually add the Service Account I created as a verified owner of the domain as well. After doing these two things, I was able to programmatically update DNS records for the domain using the Service Account. So, assuming you've created a Service Account at Google, given it the "DNS Administrator" role, and added the Service Account email as a verified owner of the domain, you should be good to go. I just tested it with my Cloudron and it all worked. I'm attaching a screenshot of the Google domain verification screen showing where I added the Service Account as a domain owner. Hope this helps.[image: 1682509131953-cleanshot-2023-04-26-at-07.28.52-resized.jpeg]

@m3pilot not sure what's happening here, something seems totally wrong (like some mismatched node version). Are you able to contact us on support@cloudron.io to debug this further?

@tonimad said in Cloudron and different webmail: Dedicated server with large calacity of space. Here, on this server, I have my Afterlogic Pro webmail installed. One simple question, why would AfterLogic be necessary to run, since you want to migrate to Cloudron and run the email service on it? Cloudron is ready to run all email services out of the box, and that includes webmail as well without any further configuration necessary other than installing the snapmail web app from the repository.

@girish you hit the nail on the head. that was 100% what was going on but odd that it only started doing it recently. honestly, if I could use anybody else but Cloudflare, I would. #takingsuggestions