Cloudron Forum

Hmm. I understood the docs like it was a thing in the hosting firms routers. That makes it even more strange, since my router is the same before, during, and after I had this problem.

Hi!

For a couple of hours now, both the Cloudron admin interface and the email services have been unavailable for me, but all apps seems to be running just fine.

Just before this happened, I was trying to add some changes to the DNS for the same domain name as I use for my Cloudron to solve some mail delivery problems.

When I ran

cloudron-support --troubleshoot

and got an error message about Hairpin NAT not working and that the admin domain could not be loaded.

So I went into my registrars DNS configuration and removed the TXT entry I had added for my.<cloudron.domain>, even though I couldn't understand why that would have an impact on the admin interface or email services.

But when I did, both admin interface and email became accessible again. Good. But I still get the Hairpin DNS error and FAIL for loading dashboard admin when troubleshooting from my servers terminal.

Can someone explain what's going on here?

1. How could SPF records have an impact on the services?
2. And how could they become available again, yet cloudron-support claming there is a problem with Hairpin NAT?

So it's IPv6 entries that are handled by Oderland, but Cloudron takes care of the IPv4?

Ah, I see! Thanks!

But I also noticed that it worked if I disabled IPv6 even for the primary domain. Why is that?

Hmm, your terminal command got me thinking: I'm trying to install apps under my Cloudron's primary domain. For primary.tld I've AAAA records configured at my registrar. I thought that Cloudron managed the AAAA records for any subdomains thanks to this setup? But should I add the AAAA record for linkwarden.primary.tld at my registrar as well?

I haven't done that for any of the already working apps, and they run as expected.

It's a Swedish one, Oderland, configured using the Wildcard option. And yes, dns1/2/3.oderland.com all have the AAAA record.

Hi!

I recently moved my Cloudron-installation to a new VPS at Netcup, and after the migration new apps can't be installed anymore.

I get this error for all apps I try:

But as far as I can tell, I've the AAAA record for the domain configured the right way at my registrar:

The IPv6 address is copied from the Network Settings in Cloudron.

What's causing this problem?

Switched to tarball, and it made a huge difference!

I use Netcup as my host, in one of their datacenters in Germany, and do my backups to Wasabi, also in Germany, using rsync. Even though my Cloudron installation is only 40 GB, backups take at least 6 hours. Six apps installed: Mastodon, Ghost, Adguard, FreshRSS, Uptime Kuma, and Umami. Guess the reason is a bunch of small files.

I went with rsync for incremental backups at less storage space. But I am starting to reconsider that, and perhaps switch to tarball.

What backup strategies do everyone else have?

Ah, that make sense. So then I better select Dry run to not have any internal checks fail, change DNS manually, and after that are good to go? The Sync DNS wont work either for Wildcard DNS?

Hi!

I'm in the process of migrating from one VPS to another, and while waiting for the backup of my old installation finish I read through the docs once more and realized that there is one thing I don't understand: What does "Dry run" do?

I get that this is a feature that let me test my Cloudron on the new server before pointing the DNS to it. What I wonder is more like how Cloudron can make those changes in the first place?

I'm using the Wildcard configuration, and in the settings at my registrar point the A records to the IP address of my current VPS. How could Cloudron change those settings if I don't check the Dry run option?

What am I missing?

Hi!

The media cache of my Mastodon installation is growing to big for my VPS. I'm considering moving the media storage to S3 instead of upgrading to a larger VPS. But I can't find any instructions on how to migrate the existing local files (that is the ones me and the other users on my instance has uploaded) to S3. Anyone who has made this and can share how?

Netcup's DNS servers are configured for my Cloudron instance.

I'm on 8.0.6 since Tuesday morning, which incidentally also is when those problem started.

Should I use resolvectl from Uptime Kuma's web terminal?

@joseph Yes, this is what I get using the web terminal.

But could it be that the DNS is going down intermittently?

I've used Uptime Kuna without any problem since April. But for the last 24+ hours I suddenly have started to receive tons of these:

The affected hosts are on .se, and one .social. Some of them are hosted at the same box I run Cloudron on, some on others.

I see that it's not the same error message as in the OP, but similar enough to be related?

According to my logs, my Cloudron was updated to 8.0.4 on August 28, and 8.0.6 yesterday morning. I don't know for sure, but from the graphs it looks like the problem started as soon as that update had been installed. This is what the week graph looks like for or the monitored services with problems:

I rebooted the whole system, and it seems to have solved the problem.

I posted about a problem with Castopod earlier today, but I just realised that my Cloudron instance might have generic cronjob problem: For a couple of weeks, my FreshRSS installation has stopped updating automatically. I've to make a manual refresh every time I want to check my feeds.

Could it be that my Cloudron have some app-wide cron problem?

Thanks!

Hi!

I'm trying to import a podcast into a fresh Castopod installation. I've pasted the URL to the RSS feed, but the process is stucked on 'queued'. Searching Castopod's Discord, the proposed solution is to make sure the cronjobs are properly configured. But as far as I know, Cloudron usually adds all needed cronjobs when you install a new app.

Any ideas for what to do?

Thanks!

Ah, thanks! I hadn't seen the app-mail-folders before.