@girish Periodic integrity checks – for example, verifying the backup archive and reporting issues proactively – could help discover corruption early, before a restore is needed. This would give admins a chance to re-run or fix backups in time. What do you think about such a feature?

@Robin do you maybe still have the apptask logs from where it hang? It should give us some indication why the DNS record check didn't succeed during that time. It should show which nameserver returned which IP for the records.

I suppose it can be marked as solved, but I still run into questions and small issues.

@girish IPv6 is enabled on the server but not "in use", since some domains that are added manually don't have v6 and I don't want to run into troubles. Those are mostly Hetzner Cloud servers.

Thanks! I'm going to play around by modifying an existing app and see how far I get.

I will put in a feature request now and we can discuss further in that thread.

In sshd, you should have GatewayPorts yes . If you whitelist the port 11434 as per https://docs.cloudron.io/networking/#whitelist-ports , it should work . I tested this and it works with your commands. But, I don't completely understand it. I found that 11434 also gets open to the world In your example, curl localhost:11434 works.. why? aren't we just binding to 172.18.0.1 ?

this issue has been resolved and the certificates have been renewed and access to the site has been restored. there was an issue with the server dns settings which was causing the certificates to not renew.

TTL issue ? I mean, this symptom lasted a very long time (a full year I'd say). Not seen since early June though. Maybe the "odd DNS issue" then. I guess this can be closed.

@arnej said in Problem with setting up a VPN tunnel from on premises machine to Cloudron in Cloud: there was a problem with the Cloudron internal firewall. Once he changed the settings there, the connection was established with no problem. Could you please elaborate what the issue was? Do we need to fix something? Also, useful for future readers who have a similar issue. I could bet you know the feeling of searching a solution and just finding a "I solved it, thanks" post somewhere and think yourself AND HOW?.

Hello @piedacoulisse For all subscription and payment related issues please contact support@cloudron.io directly! This should be resolved rather fast after you wrote the mail.

Hello @jtippetts I am willing to help and send you a DM.

@humptydumpty Soon™

@ccfu I think that would be the best idea.

@d19dotca said in issue with email delivery going through Cloudron mailing lists.: I think they were using the workaround of creating a mailbox and logging into roundcube to setup mail forwarding, so it kind of acts like the Cloudron mailing list in a way, but seems to be more reliable and doesn’t trigger Gmail’s “mass mail” protections. That's correct and also started using Lismonk for larger distribution lists.

Thanks. I'm fine with an occasional troubles that I will leave alone (after all it was working fine for a few years without any problems), but I was absolutely sure that all 'core' services are monitored thought. Is there any chance to expect that anytime soon? I can't think of a work-around solution for a turn-server external check...

Hello @p44 We were unable to reproduce this issue. Could you open the browser console network tab and when pressing configure in the backup view send us that request payload and response? NOTE!: please redact credentials

@humptydumpty Thanks for your interesting info's. I'm looking around to find an alternative to iDrive e2. After more than 4 days they still didn't give me any infos or updates about what happened...

@jdaviescoates and @girish: Excellent. Thank you. I can work with this. Very much appreciated.