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

@johnbolt You should try a forced refresh (ctrl + shift + R on most browsers), to avoid cache issues

@girish said in [BUG] Automount fail on reboot with Ubuntu 20.04: Currently, there is no solution to use DNS names in mounts don't worry, I understand that is an exception and probably not a priority, thanks for the consideration

@girish Thanks! This ended up being a combination of issues I believe. So throttling on the backups due to using rsync, encryption, and file names ended up being too long (only a few) So I've changed some settings around and it seems to have been resolved. I appreciate the help from both @robi and yourself.

Update: It is due to the VPS provider blocking ports 80, 443.

baobab is available on Ubuntu, and it's GUI app has that capability. Other options here: https://serverfault.com/questions/386784/linux-trigger-a-real-time-alarm-on-a-low-disk-space-condition but if the C code listed in the answer there is the approach, might as well do something similar in the box code. Similar here: https://www.linux.com/training-tutorials/get-disk-space-email-alerts-your-linux-servers/ Having it be a part of the standard system health check would be

@girish ah so that’s because I was messing with dind for GitLab runner... whoops. Thanks for taking a look!

I really like the blackllist checking being built-in. Frankly, I'd also be a fan of getting notifications about it. I suppose UX-wise, perhaps this is the appropriate sort of thing to trigger a yellow status on email.

@eivlil01 said in Using my own certificates: @girish I'm using the DNS based challenge, but for a wildcard entry. Cloudron only supports http based challenge for wildcards, or DNS based challenge but then it creates one entry per app. Ah, I see what you are saying now. So you have a wildcard DNS entry pointing to the server but also use DNS automation to get wildcard certs. Indeed, Cloudron does not support that.

Strange. @alkomy let us know if this reappears. Wonder what the root issue was.

@girish so I created a new WP install on a different cloudron for the domain, https://slappersonly.co -- everything seems in order now, even for people who had errors before. Meanwhile I switched the older WP install to a new domain on the original cloudron https://slaps.vip .. there do not seem to be any issues for either domain now. Not too terribly inconvenient as the 2 sites serve different purposes for the same brand, but bizarre nonetheless.

The root cause for this was the Cloudron server had the hostname as "box.domain.com" (same as the relay). Debian/Ubuntu has a quirk that it will put the hostname in /etc/hosts to resolve as 127.0.1.1. This meant that when we try to set it as relay, it resolves to 127.0.1.1 instead of the actual IP. To add to the confusion, I suggested using the host command which does not use /etc/hosts (i.e the nsswitch mechanisms) and uses only the DNS. If I had suggested using ping then we would have narrowed down the issue more quickly... Anyway, the fix is simply to hostnamectl set-hostname somethingelse.domain.com and also edit /etc/hosts (for some reason, hostnamectl doesn't change hosts file even after reboot, ).

@jlx89 You can just create that directory. It's customizable now with notfound.html - https://docs.cloudron.io/branding/#custom-pages