Cloudron Forum

Ghost recently made a UI for this https://ghost.org/changelog/signup-spam-protection/

@jdaviescoates i didn't know about the lifecycle settings, tried it and it reduced total size by 90% after a few days

@joseph i think this was around the time i switched from aws to backblaze, but i understand it didn't transfer pre-existing backups, only starting fresh, although i could be wrong. will try deleting everything if needed, but so far the previous solution works for me

i gather that there may be some things left beyond the retention policy, but it seems like everything or many/most things are kept forever. some of the dates in /snapshots go back to june/july of last year, over 6 months, and i have maybe only ever made a special manual snapshot or said 'keep this' once or twice. i expect most of these should be deleted by now, do i have the wrong idea?

my backblaze storage bill seems to be increasing every month and i think it's due to cloudron backups. my retention policy is 1 month but it seems like older backups / snapshots are not getting deleted:

i'm confused also looking at this directory as the main folder seems time-based and the subfolder /snapshot seems app-based. this subfolder seems to also have many old versions beyond retention policy.

manually cleaning this up is very cumbersome in backblaze as their checkboxes are not html but pictures or something, so one must literally click all of them. i tried cloudron's 'cleanup backups' which seems to only consider ones within my 1 month retention policy. not sure if it's aware of the files beyond that.

Feb 07 08:01:17 box:backupcleaner applyBackupRetention: 2025-01-21-040001-622/app_XXXXX_v2.26.0 keep/discard: referenced
Feb 07 08:01:17 box:backupcleaner applyBackupRetention: 2025-01-20-100002-716/app_XXXXX_v2.25.0 keep/discard: preserveSecs
Feb 07 08:01:17 box:backupcleaner applyBackupRetention: 2025-01-20-040001-314/app_XXXXX_v2.25.0 keep/discard: referenced
Feb 07 08:01:17 box:backupcleaner applyBackupRetention: 2025-01-19-040001-285/app_XXXXX_v2.25.0 keep/discard: referenced
Feb 07 08:01:17 box:backupcleaner applyBackupRetention: 2025-01-18-040001-307/app_XXXXX_v2.25.0 keep/discard: referenced
Feb 07 08:01:17 box:backupcleaner applyBackupRetention: 2025-01-17-040001-202/app_XXXXX_v2.25.0 keep/discard: referenced
Feb 07 08:01:17 box:backupcleaner applyBackupRetention: 2025-01-16-040001-480/app_XXXXX_v2.25.0 keep/discard: referenced
Feb 07 08:01:17 box:backupcleaner applyBackupRetention: 2025-01-15-040001-449/app_XXXXX_v2.25.0 keep/discard: referenced
Feb 07 08:01:17 box:backupcleaner applyBackupRetention: 2025-01-14-040001-497/app_XXXXX_v2.25.0 keep/discard: referenced
Feb 07 08:01:17 box:backupcleaner applyBackupRetention: 2025-01-13-100004-538/app_XXXXX_v2.24.0 keep/discard: keepWithinSecs
Feb 07 08:01:17 box:backupcleaner applyBackupRetention: 2025-01-13-040001-279/app_XXXXX_v2.24.0 keep/discard: referenced
Feb 07 08:01:17 box:backupcleaner applyBackupRetention: 2025-01-12-040001-348/app_XXXXX_v2.24.0 keep/discard: referenced
Feb 07 08:01:17 box:backupcleaner applyBackupRetention: 2025-01-11-040001-615/app_XXXXX_v2.24.0 keep/discard: referenced
Feb 07 08:01:17 box:backupcleaner applyBackupRetention: 2025-01-10-040001-315/app_XXXXX_v2.24.0 keep/discard: referenced
Feb 07 08:01:17 box:backupcleaner applyBackupRetention: 2025-01-09-040001-222/app_XXXXX_v2.24.0 keep/discard: referenced
Feb 07 08:01:17 box:backupcleaner applyBackupRetention: 2025-01-08-040001-314/app_XXXXX_v2.24.0 keep/discard: referenced
Feb 07 08:01:17 box:backupcleaner cleanupAppBackups: applying retention for appId 1bba7e1f-a2f5-4bd9-b2be-3a60d0153669 retention: {"keepLatest":true,"keepWithinSecs":2592000}

i didn't find any solutions in these related topics:

• Backups before retention policy not being deleted. Bug?
• Scaleway backups retained > retention policy
• Backup retention time

any suggestions?

@nebulon said in "fatal: not a git repository":

Have you tried to use a subfolder in /app/data/ for this? This is where data is kept persistently in Cloudron.

Been using this folder and seems like it has had no issues for a week or two now thanks for clarifying

I have been pulling an external git repository via n8n into the container's /tmp folder and have pushed changes successfully via an active workflow. At some point the workflow fails because of a fatal: not a git repository error and I'm not sure why this happens.

When navigating to the .git folder via the container's web terminal in Cloudron, the data inside looks like this:

total 104
drwxr-xr-x  8 cloudron cloudron  4096 May 14 12:00 .
drwxr-xr-x  7 cloudron cloudron  4096 May 14 12:00 ..
-rw-r--r--  1 cloudron cloudron     5 May 14 07:08 COMMIT_EDITMSG
-rw-r--r--  1 cloudron cloudron    92 May 14 07:08 FETCH_HEAD
-rw-r--r--  1 cloudron cloudron    41 May 14 07:08 ORIG_HEAD
drwxr-xr-x  2 cloudron cloudron  4096 May  3 10:17 branches
-rw-r--r--  1 cloudron cloudron   333 May 14 07:08 config
drwxr-xr-x  2 cloudron cloudron  4096 May 14 12:00 hooks
-rw-r--r--  1 cloudron cloudron 56770 May 14 07:08 index
drwxr-xr-x  2 cloudron cloudron  4096 May 14 12:00 info
drwxr-xr-x  3 cloudron cloudron  4096 May  3 10:18 logs
drwxr-xr-x 52 cloudron cloudron  4096 May 14 07:08 objects
drwxr-xr-x  5 cloudron cloudron  4096 May  3 10:18 refs

When cloning/pulling the repo fresh to a new folder, it looks slightly different but I'm not sure what would make it behave differently.

total 116
drwxr-xr-x  8 cloudron cloudron  4096 May 19 07:10 .
drwxr-xr-x  7 cloudron cloudron  4096 May 19 07:10 ..
-rw-r--r--  1 cloudron cloudron     5 May 19 07:10 COMMIT_EDITMSG
-rw-r--r--  1 cloudron cloudron    92 May 19 07:10 FETCH_HEAD
-rw-r--r--  1 cloudron cloudron    23 May 19 07:10 HEAD
-rw-r--r--  1 cloudron cloudron    41 May 19 07:10 ORIG_HEAD
drwxr-xr-x  2 cloudron cloudron  4096 May 19 07:10 branches
-rw-r--r--  1 cloudron cloudron   333 May 19 07:10 config
-rw-r--r--  1 cloudron cloudron    73 May 19 07:10 description
drwxr-xr-x  2 cloudron cloudron  4096 May 19 07:10 hooks
-rw-r--r--  1 cloudron cloudron 57218 May 19 07:10 index
drwxr-xr-x  2 cloudron cloudron  4096 May 19 07:10 info
drwxr-xr-x  3 cloudron cloudron  4096 May 19 07:10 logs
drwxr-xr-x 14 cloudron cloudron  4096 May 19 07:10 objects
-rw-r--r--  1 cloudron cloudron   114 May 19 07:10 packed-refs
drwxr-xr-x  5 cloudron cloudron  4096 May 19 07:10 refs

I found one answer suggesting to copy .git/ORIG_HEAD to .git/HEAD in the broken repo, but that didn't change anything and creates another fatal: detected dubious ownership in repository at XXXXX error.

As it functions for weeks and then suddenly stops, I wonder if it's not an n8n issue and something that happens at the Cloudron or OS level. If there are any guesses about that I would appreciate it.

For now I just manually delete the folder and pull again, but this defeats the purpose of using an automation system; I can also delete as part of the workflow, but wanted to avoid pulling a large amount of data everytime.

@girish said in App Proxy set host header:

@rosano so your plausible is running with a different domain with https and you are proxying from cloudron with another domain name ?

they recommend setting the Host header to plausible.io, for example with nginx. I suppose that's what the App Proxy was doing before the update. I imagine it's not the direction Cloudron is going, in which case a hostable fork of the previous version would be amazing.

@girish said in Cloudron 7.6 released:

app proxy: Host header is set to match the proxy domain instead of the target domain

I think this change broke my App Proxy for Plausible analytics. Would be nice to have the previous behaviour (or fork the older version).

good finds here! will check out the first one's podcast too.

@jdaviescoates thanks for mentioning that, yes i think there are tons of self-hosted solutions out there and i would like to highlight what is possible with one-click (as not everyone can deal with github READMEs). hope to improve easy indie and maybe integrate with apps from that other topic ️

@girish said in Questions about Cloudron Gogs Config File Settings:

It seems the config docs (https://gogs.io/docs/advanced/configuration_cheat_sheet) is now broken.

source still available https://github.com/gogs/docs/blob/b3379ec57b24f2a9a079c0cd9fede86fec6e3a99/en-US/advanced/configuration_cheat_sheet.md

@Kubernetes i'm having difficulty making time to do a PR, feel free to copy

I understand GitHub Pages and Surfer can only point domains at the root, so they host one 'site' at a time. Is there a best practice for hosting multiple static sites on a single Cloudron app? Is it possible to map multiple domains to separate directories in Surfer?

In the topics Best App to Set up Static websites? and Best Choice for Static Website I didn't see something similar.

@nebulon seems also that the swap file was commented out in /etc/fstab (again not sure why/how) so it doesn't persist across restarts, and I guess the script you posted wouldn't affect this.

# /apps.swap  none  swap  sw  0 0

After uncommenting and reboot now, there seems to be a swap file via swapon:

/apps.swap file 3.7G 1.8M   -2

And all apps are running / stopped as expected, nothing hanging thanks for your patience and help .

I wonder what about this could have to do with the latest Cloudron update as I didn't touch anything in the last days and everything seemed to be fine.

@rosano I might have misread #Port 22 as Port 22 as it seems to have been commented out (not sure how/why). Uncommenting and rebooting enables ssh login via ip address again. Computers are hard

still working via support, but just want to note that ssh doesn't time out when replacing the IP address with the cloudron domain:

ssh root@my.example.com

@girish sent, number 18901.

@girish I was able to reset via Hetzner console yes, but I ran everything through their 'web console' not SSH. Would you able to use this root password from your end?

@girish mail is stopped, clicking restart shows the same error as my initial post. might have to do with argument "NaN" for "-m, --memory" flag: invalid size: 'NaN'?

swapoff seemed to not do anything, but sudo rm /apps.swap did and I was able to run the script which seemed to be successful. After reboot via the Cloudron console and also power cycle on Hetzner, I'm still in the same place: 8 apps Running, 1 app stuck on Restarting, 3 apps stuck on Stopping, timeout when connecting via ssh.

@Kubernetes glad you like it. which repo specifically? and isn't that really a matter for the admins? I don't mind if they use it.