@jdaviescoates A fresh install of Ubuntu does not have docker, nginx or nodejs. We install specific version of these , so we need to make sure it's not already installed.

I would take a step back: where are you creating the server? If it's a VPS provider, I can test out Cloudron installation there. Otherwise, can you tell me more about your server installation?

@girish probably can yes just hadn't even thought of trying that!

Will give it a go when I get the chance...

@Shai yeah, better to remove it. On ubuntu, installing packages also enables them. So, this might cause problems in the future.

@bmann Yeah, in that case, I'd say just use a provider that allows you to buy extra storage inexpensively and mount it as a volume. BuyVM is the one that comes to mind honestly.

You can also use CIFS or NFS, but I don't know how well I'd trust them as primary storage for an app.

Also, as said, some apps support external S3 (although that limits your capability to fully encapsulate your backups).

Thanks for the reply. I just doubled from 15 to 30. Lets see if this helps.

I'll give it a try. Thank you very much for your help and explanations. 👍

@mdc773 yes. next time around, you can download the backup config that prefills all this - https://docs.cloudron.io/backups/#restore-cloudron

@girish Nice. Wish Cloudron could fix all the other mistakes I make.

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.

@d19dotca I also suspect it's a problem with the iDrive storage. Because the backup problem is not a regular one. If he writes to iDrive support please let me know.

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 !
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).