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 `Error : Inactive - Error getting IP of postgresql service`: 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?

The appstore server seems to be up normally. Also the warning/error you mentioned is not fatal. Are there any other errors being shown somewhere in the logs?

@savity Worked Perfekt Thanks

Thanks for the detail @girish Noted @nebulon - perhaps if the different stages of the startup process were tagged, one could track this more easily.

@carbonbee So, you are saying that there are backups in S3 that are not listed in the Cloudron dashboard? And those backups are not getting removed?

For completion sake: https://docs.cloudron.io/backups/#restore-email

https://forum.cloudron.io/topic/3682/proxyauth-addon is the new alternative which uses LDAP.

I will mark this as solved for now but I suspect this will come back some day.

@girish this was a different Cloudron than the DNS MX issue which is still persisting ;-/

This is fixed in the next release. Thanks for reporting!

https://forum.cloudron.io/topic/3661/unable-to-uninstall is the same for another app (mastodon).

I will close this because this is planned as part of Cloudron 6.