Thanks guys! Yeah it's a weird issue for sure and likely very rare, so it's probably not a big deal. If it helps for reproducing it, here's a few notes: 27 apps installed at the time of backup/restore Backup & Restore used tgz format with OVH Object Storage in BHS region Backup from a LunaNode m.8 model in Toronto region Restored onto OVH b2-7 model (though since upgraded to b2-15) in BHS3 region LunaNode instance (source) was running Ubuntu 18.04 at backup time, and OVH instance (target) was running Ubuntu 20.04 at the time of restore. When I restored, I very nearly ran out of disk space on the included disk, leaving only ~ 1.5 GB of space remaining. When restoring initially, it failed to restore because of the issue I reported earlier, though doubtful this is a root cause. Immediately moved the boxdata to external disk afterwards though, so plenty of space free soon after the restore was done once I moved boxdata off (20 GB in emails alone so it takes up a lot of space). Hopefully those notes above help in some small way. No worries though if you can't reproduce it, I imagine it's a very rare scenario and could have even been completely unique to me somehow. Hopefully others can chime in though if they experienced anything similar where cron wouldn't run at all (whether a restore involved or not, as I'm still not 100% certain it had to do with the restore though I presume it did).

@kallados indeed it has to be adjusted to your own account name. cloudron here refers to our account at the docker hub. The chown is for the unix user named cloudron on your system. Nothing to do with the docker hub registry service.

@fossy As mugero said, you really have no reason to worry about the services. They use a negligible amount of resources when they are not actually used!

@infogulch said in Changing from wildcard to provider-based dns configuration left apps and my.example.com unassigned after wildcard was deleted: That makes a lot of sense. Curious, does Cloudron log when it encounters an existing DNS record that it should not overwrite? It will show the error in the UI. If you try to install an app into a subdomain that has a DNS entry, it will error and give you an option to "overwrite" the DNS record.

@svallory Accept self-signed certs and login to dashboard. Once logged in, I would first go to settings and check for updates/update all the way to Cloudron 6. This is because LE made a change in the last few months which makes cert renewal fail on Cloudron side. Once updated, Domains -> Renew all certs.

@girish Will do

I was totally in the wrong here. I just looked at the wrong section it turned out Sorry for taking up your time.

@nebulon said in Managing SSL certs via Cloudron CLI: you have to "forget" the page in your browser yes, or visit the site in an incognito session. Clearing these entries from the profile in Chrome is slightly more complicated, but doable as well. https://msutexas.edu/library/clearhsts.php

@staypath Continuing my conversation with myself Posting this here in case anyone else comes across this with the same question: I found that configuring fail2ban to use systemd was the trick: [sshd] port = ssh #logpath = %(sshd_log)s #backend = %(sshd_backend)s backend = systemd enabled = true maxretry = 1 bantime = 14d

@mastadamus If you use namecheap API, you don't need port 80. This is because Cloudron will use Let's encrypt DNS automation to get certs. Note that this will require you to sometimes type "https://" explicitly in some browsers because some browsers will default to connecting on port 80 and then the redirect will take it to the https site. In addition, Cloudron has HSTS, so future connects will directly be to 443 and no redirect dance.

Turns out the domain expired. Nothing related to Cloudron. Please mark this as resolved.

@d19dotca OK, I have scheduled https://git.cloudron.io/cloudron/box/-/issues/737 for 6.2, let's see.

@chymian-0 Did you whitelist the ports or did you use iptables/ufw directly? We only support https://docs.cloudron.io/networking/#whitelist-ports

One other note, the .sql file originally failed to upload due to the dump having the following line: Create SCHEMA public; I commented that out and the import ran fine. I'm guessing there is a command to dump the Postgres DB without a create statement but someone smarter than me probably knows it. I haven't used Postgres a day in my life until yesterday so I'm still getting to know it. I have only used MySQL, Maria and MS SQL and all of those have an option to dump without the create statement, but I figured it was just easier to comment that line out of the SQL file instead of looking up the command and doing a new dump.

@yusf OK, thanks, when you find time, feel free to reach on the support mailbox.

This sounds like it should be a part of the build package and/or the registry package, depending on use case.

@girish it's been solved. I did a docker logout and tried again. Got the error again but this time the error was a bit more detailed. Tried it again and it worked. Thanks!

Thank you all for your answers! Yes i was curious if cloudron did something special with the networking. I will contact the network administrators and try to fix the issue with them.