I remember now. We have this issue with the DNS server (unbound) we use which doesn't work properly with just IPv6 with our configuration. We are working on getting away from unbound altogether because of various other issues, so will get to do this after that.

I apologize, I've been really busy. Ended up just being a combination of me setting conflicting DNS records and issues with Let's Encrypt ACME verification. I fixed both and everything is working properly now.

Great! Thank you so much for the detailed and helpful answer

I can confirm.Thank you!

@andreasdueren yes, usually that means the passphrase is wrong.

@Dont-Worry the apps run as containers and each container has it's own file system (completely different from the host filesysted). It is a sort of sandboxing for security. What this setup means is that, even if your disc is attached to the machine, the app containers won't see it! It will be available on the host ubuntu itself but not to the apps. Cloudron Volumes is a mechanism to expose these discs on host to the apps. Hope that clarifies! But if I could use it as a classic disc, I should mount it as a Cloudron volume If I understood correctly. Right, and there is no way around not creating a volume.

You can also check apt list --upgradable | grep security if those are actually security updates.

@girish said in Firewall IP blocking: IPv6 not possible: I guess this post was before we had IPv6 support. IPv6 is supported in the firewall by now. Indeed

For anyone coming later, Ubuntu server use's netplan for configuration via files in /etc/netplan and you should not configure networking directly via systemd-networkd .network files. More details here. In my case if I ran sudo cat /etc/netplan/00-installer-config.yaml I got the following: # This is the network config written by 'subiquity' network: ethernets: enp2s0: dhcp4: true optional: true version: 2 The specific issue was that I had optional: true which I had done when I first setup this system as I originally had it setup to use wireless while doing the initial configuration and then switched to hard wired once I deployed it. Changing optional: true to optional: false, then removing the .network file I had put in /etc/systemd/network, and then rebooting I can now see that cat /run/systemd/network/10-netplan-enp2s0.network no longer has RequiredForOnline=no. Apparently the default is to require the network adapter to be in a routable state so now with the correct netplan configuration I get the right generated systemd-networkd configuration which properly waits for the interface to be routable before trying to mount volumes and all volumes mount as expected without intervention. The root cause behind this issue was me making a configuration change I meant to be temporary but then forgot to reverse and then because I didn't understand netplan my troubleshooting was in the wrong places.

There is a bug in Cloudron that it parses swap info incorrectly when there are no swaps in the system. This is fixed in https://git.cloudron.io/cloudron/box/-/commit/b66e77a2d8930381c95153b041d7c3edd331364a

@nebulon that solves the problem. Thx. I totally get the warning, however: due to budget restraints I have to do it that way.

@girish Thank you, Girish! After I updated the node, this error went away.

@susankhanal said in cloudron not accessible using domain name outside the network: doing curl my.domain.com gives HTML lines from inside the network but doing curl outside the network it says unable to connect Before debugging further, I would double check the HTML output. Can you check if that looks like Cloudron dashboard code? Also, is my.domain.com resolving to an internal IP or an external IP? If it is resolving to an external IP, then most likely port forwarding is not working properly in the router.

Ah great you managed to get this going!

Glad it worked out in the end, and thanks for sharing the insights here!

Seems to fine here atleast. And we are not seeing any outages at https://status.cloudron.io/ either . Please re-open this if this is still a problem.

Hi, I just wanted to follow up on this. We found the relating issue in this case which resulted in several different problems. In that case, it was bug in a firmware update on a firewall and not related to Cloudron and can be marked as resolved. Thank you anyway for your help.

@pathab ah nice, great you found the root cause!

@jdaviescoates Good catch! This is a UI bug that it doesn't show deleted apps. The backups are there but the UI is unable to find an app to create a link to and decides to remove it entirely. Fixed in https://git.cloudron.io/cloudron/box/-/commit/49941a34b935c28570514c59598bbf58b93d41a1 . With this, clicking on deleted app will just put you in the eventlog (hopefully that gives some information what that app was).

@girish Thanks for the quick reply, . In case anyone else needs this on 22.04, I followed these steps and was able to get the system to boot with full disk encrypted drive with the private key coming from the tpm and no password needing to be typed. I don't think this uses the same libraries as the new option in 23.10 so I expect that when 24.04 comes out I will do a fresh OS install to use the better supported FDE TPM integration from that version going forward but as a stop gap I am happy with this for now.