Yes I have DKIM setup. Thanks for the “relaxed” incantation. I’ll try that.

@girish said in resolvconf failed by Install to Cloudron: Did I understand correctly, that cloudron-setup is failing and that the error you posted is from /var/log/cloudron-setup.log ? What's the log lines before the error ? See if you can fix those errors manually and run cloudron-setup --redo . It's not me this time, but I've hit this before yes cloudron-setup does not work at all on Netcup VPS vServers because they are running some custom minimized version of Ubuntu. See also this previous thread https://forum.cloudron.io/post/74252 Netcup said on Twitter they would look into it here https://twitter.com/netcup/status/1711394283347960098 but presumably they haven't fixed it.

For these kind of setups, it's easiest if you use one of the automated DNS options (i.e not manual or wildcard). Setup service1.domain.tld as one of the automated DNS options. Not sure where domain.tld is already hosted but it's not one of the options we support, you can always create a zone called service1.domain.tld and put host the zone is one of the DNS services. In your proxy, forward https://service1.domain.tld AND ``https://*.service1.domain.tld` (hope it supports wildcard) to Cloudron VM. It should work with valid certs with the above setup.

@genies305 you can just email us at support@cloudron.io

To close the thread here, the issue was simply that update to 7.5 was failing because @squareclouds 's cloudron is still on ubuntu 18 . One must upgade to Ubuntu 20 first before updating to 7.5.

Yay ! [image: 1698858691667-screenshot-2023-11-01-at-17.10.55.png]

@girish Ha ok, makes sense, will try setting up the relay and update the thread. Thx!

@girish Thank you. Your solution did the trick. But we needed the ipv6 to be functional. So what we did to make it work was > reinstall Ubuntu 22.04 LTS OS and didn't install unbound in advance. All is good now.

Okay, I figured out what my problem was. I had some failed backups from yesterday, when I tried to get hardlinking working (and I also had a permission issue with the MySQL dump). As of such, I cleared the backup disk manually, and then triggered a backup cleanup in the Cloudron UI. Then I tried to back up again, however, I believe that Cloudron keeps an index of files it has already backed up to keep things speedy (which is nice). As of such, even though the other files no longer existed, it was only backing up the changes. To solve it, I just changed the backup method to a different method, and then changed it back again, which cleared the index. Thanks for all your help on this :).

@d19dotca said in Backup to ext4 disk mount, using rsync, fails on first full backup but succeeds in all future ones.: Setup a new public cloud instance at OVH Create a block storage disk and attach it to the public instance created in step 1 Format the block storage disk and mount it according to this article: https://docs.ovh.com/ca/en/public-cloud/create_and_configure_an_additional_disk_on_an_instance/#using-linux Install and restore Cloudron from old server via DigitalOcean Spaces latest Cloudron backup ID Once Cloudron is running off latest backup, change backup configuration to file system using rsync non-encrypted with hardlinks, then initiate the first backup to the new location. This is where it failed for me. Hey, I know this is quite old, but I just had this issue too (v7.4.3), and I think I know what the issue is. So the Backup type is 'Filesystem (Mountpoint). Cloudron tries to hardlink between one device (primary boot, or one particular mountpoint) and the other (another mountpoint). Hardlinking isn't supported between devices sometimes though, so the hardlink fails. This issue seems to occur even with encryption though. Just a heads up in case anybody runs into this issue. Solution in the main time is to just not use hardlinks.

@girish I am just finding this thread. I would suggest adding these options: { name: '7 daily, 4 weekly, 3 monthly', value: { keepDaily: 7, keepWeekly: 4, keepMonthly: 3 }}, { name: '7 daily, 4 weekly, 6 monthly', value: { keepDaily: 7, keepWeekly: 4, keepMonthly: 6 }}, The first option is a common backup cycle (I think) and the second option allows for 3 more months of retention (and is halfway between the first and the current 12 month option).

This then means, that the system is using cgroups v2 now. I have updated the main docs section at https://docs.cloudron.io/packaging/cheat-sheet/#memory-limit for a start to make an app compatible with cgroup v1 and v2 (I guess in your case its sufficient to only support v2 now.)

Thanks ! It's working !

@andreasdueren i think I just followed their documentation: https://goauthentik.io/docs/providers/ldap/generic_setup

Hey all, reinstalled and then did a restore to fix things. Had a few trouble with restore, but was able to work them out. Also wrote a quick rsync command to take the emails from lost+found and restore them to their proper directories, so no emails lost :).

@saikarthik no worries

Sweet and thanks, I figured as much :). I'll have to check out the partition table change. Thanks so much for your help on this.

@nebulon said in Is it safe to upgrade my Cloudron?: It is a suboptimal behavior of the updater to show this flag for all updates as soon as we put a testing release out. Aha!

We had quite a few similar issues with namecheap in the last week on support. Check if your domain really only has no other DNS records reported via host <yourdomain> if there are multiple records reported, you have to ask namecheap support about this.

Thank you, Girish, for diagnosing and solving this bug so quickly! Backups are working again. If somebody else has this issue and needs to do the patch, you would go to the operating system for your server and find the file there and edit it. Cloudron also have a support tool inside Cloudron which enables you to temporarily grant ssh access to your server, which would let Cloudron's brilliant team patch it for you.