@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.

@robi That's my understanding, yes. That it will persist to containers. The article I liked in the earlier comment has the sysctl command to set vm swappiness. But as mentioned earlier, fine tuning these things should be done after investigating and understanding those settings because they usually end up having unexpected side effects.

What is the output of ls -l /media/bernat/owncloud ? drwx------ 20 www-data www-data 4096 Nov 8 09:18 owncloud Thanks @girish I thought it was permissions.

It also seems like they need the posts up for a short time to get credit for their work. If the credit is not reliably received, they will move on elsewhere. Break the incentive.

@girish I have reports that this just happened again.

@girish Thanks, this fixed the issue! However, during subsequent testing I found that Redis goes down approx. 30% of the time when I stop the app. For testing I am using Scrumblr but I have seen similar issues with GitLab too. Is this an issue locally for me on my VPS, or could there be something else going on? Cheers, Ross