@mehdi you're right, my poor choice of words.. apt is a binary that can call libapt-pkg libraries and provides a subset of interactive options and commands for apt-get/cache by default. apt-get is not limited to those options.

@nicolas There's a feature request to monitor network traffic at the app level. If we had that, we could have narrowed this down more quickly.

This is fixed in Cloudron 6

@yusf Are backups failing by any chance. I wonder why there are multiple backups in a day. How often do you create backups? If it's one week backups from 17th Npv are expected. the ones which are slightly older are probably preserved for various reasons. One thing you can do is Backups -> Cleanup backup. Then in the same view, click on logs and it will tell you why each and every backup is preserved. If you paste the log, I can explain in a bit more detail.

@dreamcatch22 with AWS, I have usually found that it's either a) the cpu credits are kicking in. are you aware of https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/burstable-credits-baseline-concepts.html ? AFAIK, even lightsail has the same limitation (but not 100% sure). b) some machine have a lot of memory but perform very poorly . For example, see the notes in EC2 R5 xlarge (which has 32GB RAM!) but works very poorly with docker - https://forum.cloudron.io/post/17488 Not sure, if either of those apply to you. What instance are you using ?

@nebulon Hi, I have Cloudron running in a VM under Proxmox, and since I (rather poor decision on my part) didn't take a backup of the VM before installing Cloudron, I don't easily have a "restore point". Whenever I install a new VM image, I have to manually configure the networking to use the right bridge, so just a hassle. Was hoping to avoid it, but clearly it's unavoidable. But understood, I ended up just deleting the VM's disk image and remaking it, just took awhile. tldr - my Cloudron install is on a VM on a dedicated server, not a VPS, and no restore point, so can't easily just "rollback".

This is actually intentional as the system waits for the healthcheck.

Support for Ubuntu 20.04 will come with next release.

@d19dotca Yes, the limits are there to protect against the noisy neighbor problem which exists when many processes are competing for the same resources and ONE uses up more than their fair share. Technically we could have all 30 Apps be set to 1+GB on a 16GB RAM system and it would work fine until one App behaved badly. Then the system would be in trouble as the OOM killer would select a potentially critical service to kill. With limits, the system is happy, and the killing happens in containers instead.

So I'm pretty convinced the issue was the way I wrote the CAA records. I think my DNS provider didn't need the double-quotes in there and it caused issues. Reason I say that is because after introducing the CAA records, I suddenly had the certificate renewal errors. Then when using a DNS check tool and I looked up CAA records for Google and Mozilla and more, none of them had the double-quote in there, but mine did. So I am sure that was the issue, as everything worked fine again after I removed the double-quotes. I suspect the double-quotes was being taken literally as a string and so letsencrypt.org is not the same as "letsencrypt.org" in the DNS CAA record. I was able to later find the logs I had seen in the early morning which shows the following which confirms my conclusion: CAA record for <domain> prevents issuance. So for anyone who comes across this later, make sure you're not using double-quotes I guess. haha.

@thibaud I replied to you on support@ but the issue is that there is some long file name. The current rsync+encryption backup has some file name length limitation - https://docs.cloudron.io/backups/#encryption . There is a feature request at https://forum.cloudron.io/topic/3057/consider-improvements-to-the-backup-experience-to-support-long-filenames-directory-names . Run the following command in /home/yellowtent/appsdata to find the large filenames: find . -type f -printf "%f\n" | awk '{ print length(), $0 | "sort -rn" }' | less

Marking as solved since a feature request is open at https://forum.cloudron.io/topic/3057/consider-improvements-to-the-backup-experience-to-support-long-filenames-directory-names

@d19dotca I think the -f flag on install just "cleans up" the installation : it notices that some files required for some packages were removed (in the previous line), so it removes said packages. What actually frees up the space is the rm. The apt-get -f install just makes the system notice that the packages in question are not installed anymore

@vladimir Can you try this change https://git.cloudron.io/cloudron/box/-/commit/bedcd6fccf58830b316318699375bc1f582a5d7a ? The file on Cloudron is /home/yellowtent/box/src/storage/s3.js. Essentially change the timeout from 3000 * 1000 to 0. And also change maxRetries to 10. You don't need to restart anything after the change since the code changes are immediately picked up. (See also https://forum.cloudron.io/topic/3680/backup-issues-with-minio)

@nebulon said in App Install & Uninstall fails with &#x60;Error : Inactive - Error getting IP of postgresql service&#x60;: I doubt this is related to your subdomains. Can you verify that unbound on the Cloudron is running and maybe restart the postgres addon? You are 100% right. The postgres service was simply not running. Silly me, could have checked that myself.

@saikarthik Nope, I just don't like Amazon's ethics. https://www.ethicalconsumer.org/company-profile/amazoncom-inc

@saikarthik Yes, the proxy addon seems good for what you are looking for. However, it's not available yet, it'll only be released with Cloudron 6 (I think the devs estimated about 2 weeks, but it's only an estimate). Also, it does not allow for more fine-grained control, so if you want to restrict only a few things, you'll have to do it manually, and in that case yeah you can take inspiration in the Surfer app for example.

@nebulon Thanks! For anyone else, this is how I did it. In 'Dockerfile', I added the files into the /app/code directory using: COPY public /app/code/temp-public Then, in 'start.sh' I added the following to ensure it only copies files over on first run: if [[ -z "$(ls -A /app/data/public)" ]]; then echo "==> Add public files on first run" cp -r /app/code/temp-public/* /app/data/public/ else echo "==> Do not override existing public folder" fi

@ei8fdb said in Why is my backup drive full?: I've moved the backup directories from /var/backups/ to my external drive. If I want to restore from those backup directories, do I need the contents of the /var/backups/snapshot directory also? The snapshot directory is not required for restoring. BUT it's required for the actual the backups to work (so think of it as a working directory for backups). It's important to not remove that directory when doing backups! Since, Cloudron will use hard links from the actual backups to the snapshot directory, it's not really taking up extra space.

@wu-lee do you know why it had failed to renew previously?