Cloudron Forum

At the moment the workaround is to do this is, is inside the start script.

REDISCLI_AUTH="${CLOUDRON_REDIS_PASSWORD}"  redis-cli -h "${CLOUDRON_REDIS_HOST}" -p "${CLOUDRON_REDIS_PORT}" CONFIG SET maxmemory-policy allkeys-lru

But this way is fragil. When the service is restarted for some reason, the default policy is set.

Now when the maxmen is reached by the app -> 500, because it is not allowed to write anymore.

Depending how old your onlyoffice is:

PGPASSWORD=${CLOUDRON_POSTGRESQL_PASSWORD} psql -h ${CLOUDRON_POSTGRESQL_HOST} -p ${CLOUDRON_POSTGRESQL_PORT} -U ${CLOUDRON_POSTGRESQL_USERNAME} -d ${CLOUDRON_POSTGRESQL_DATABASE} -f /var/www/onlyoffice/documentserver/server/schema/postgresql/upgrade/upgradev630.sql

PGPASSWORD=${CLOUDRON_POSTGRESQL_PASSWORD} psql -h ${CLOUDRON_POSTGRESQL_HOST} -p ${CLOUDRON_POSTGRESQL_PORT} -U ${CLOUDRON_POSTGRESQL_USERNAME} -d ${CLOUDRON_POSTGRESQL_DATABASE} -f /var/www/onlyoffice/documentserver/server/schema/postgresql/upgrade/upgradev710.sql

In case the db schema upgrade is already up2date, the output looks like:

root@78d36e9e-8352-4cd1-a356-42fa5e22702f:/app/code# PGPASSWORD=${CLOUDRON_POSTGRESQL_PASSWORD} psql -h ${CLOUDRON_POSTGRESQL_HOST} -p ${CLOUDRON_POSTGRESQL_PORT} -U ${CLOUDRON_POSTGRESQL_USERNAME} -d ${CLOUDRON_POSTGRESQL_DATABASE} -f /var/www/onlyoffice/documentserver/server/schema/postgresql/upgrade/upgradev630.sql 
psql:/var/www/onlyoffice/documentserver/server/schema/postgresql/upgrade/upgradev630.sql:15: NOTICE:  column created_at already exists.
psql:/var/www/onlyoffice/documentserver/server/schema/postgresql/upgrade/upgradev630.sql:15: NOTICE:  column password already exists.
DO

Based on the git history, cloudron only did the schema migration for 720.sql.

The Dockerfile should fail on docker build in case there new sql files and apply the sql files. atm rerunning the sql files does not exit with exit code > 0. But I believe it is better to store somewhere which sql-files was already applied, just for case sql file would break something on a rerun.

Oh sorry.

The doc is even not up2date. In latest version (9.1.5) the response is (unconfigured):

{"allowlist":[],"blocklist":[]}

At the moment cloudron counts only the usage of /app/data, but not the dumps of the latest backup/rest.

The dumps are part of "Everything else (Ubuntu, etc) 123.0 GB".

Feature-Request:

Display the sum of everything in /home/yellowtent/appsdata/1234/, not just the sum of (/home/yellowtent/appsdata/1234/data).

Or extend the current display. appname 1GB data / 1GB misc (Latest db dump etc.).

Relevant part:

// 
for await (const line of rl) {
        if (!line) continue;
debug(`Current line: ${line}`);
        const cacheEntry = JSON.parse(line);
// ...
}

I added the debug. And yes, line is just invalid json.

Log:

// ...
Mar 14 21:19:59 box:syncer Current line: {"path":"data/storage/app/myfile.txt","stat":{"mtime":1723408804000,"size":26604,"mode":33188}}
Mar 14 21:19:59 box:syncer Current line: {"path":"data/storage/app/myfile2
Mar 14 21:19:59 box:backupupload upload completed. error: SyntaxError: Unterminated string in JSON at position 83 (line 1 column 84) at JSON.parse (<anonymous>) at Object.finalize (file:///home/yellowtent/box/src/syncer.js:184:33) at process.processTicksAndRejections (node:internal/process/task_queues:103:5) at async sync (file:///home/yellowtent/box/src/backupformat/rsync.js:211:5) at async Object.upload (file:///home/yellowtent/box/src/backupformat/rsync.js:309:12) at async Object.upload (file:///home/yellowtent/box/src/backuptask.js:101:37)

More context:

root@5fc22e33-ac60-4f99-bbe3-2ca8cf9e12c7:/# ls app/data/storage/app/attachment/6/0/1/myfile2_ foo.pdf 
'app/data/storage/app/attachment/6/0/1/myfile2_'$'\342\200\251''foo.pdf'
root@5fc22e33-ac60-4f99-bbe3-2ca8cf9e12c7:/# file app/data/storage/app/attachment/6/0/1/myfile2 _foo.pdf
app/data/storage/app/attachment/6/0/1/myfile2\051foo.pdf: PDF document, version 1.5 (zip deflate encoded)

This can happen in this step:

=>  PREV_DOLIBARR_VERSION=`php /app/code/htdocs/install/get-version.php`

Log:

2026-02-07T13:35:00Z ==> Starting Dolibarr
2026-02-07T13:35:03Z #0 /app/code/htdocs/core/class/conf.class.php(561): DoliDBMysqli->query()
2026-02-07T13:35:03Z #1 /app/code/htdocs/install/get-version.php(28): Conf->setValues()
2026-02-07T13:35:03Z #2 {main}
2026-02-07T13:35:03Z PHP Fatal error:  Uncaught Error: Call to a member function query() on false in /app/code/htdocs/core/db/mysqli.class.php:355

A shell script with set -e stops when If an error occurs. The script does not have an error handling in such cases, therefore the lock file is still in /tmp.

With error handling

trap 'echo "Houston we have problem"; [[ -f /tmp/install.lock ]] && mv /tmp/install.lock /app/data/dolibarr/install.lock; exit 1' ERR

When configured rsync the database does not benefit of rsync (not really) therefore it should always be compress to save storage/speed up the backup process.

I believe the current implementation of the API does not support paging.

Zone not found: Hetzner DNS error 200
{
    "meta": {
        "pagination": {
            "last_page": 2,
            "next_page": 2,
            "page": 1,
            "per_page": 25,
            "previous_page": null,
            "total_entries": 29
        }
    },
    "zones": ["25x zones"]
}

@SansGuidon

The fix is not released.

You could back up the app with another backup destination which does not uses rsync or patch the file manually with https://git.cloudron.io/platform/box/-/commit/6e0dc24ecae47ba3175ce1574a86c6724fbc98aa.diff

The link behind the ?.

Old: https://docs.cloudron.io/certificates/#certificate-providers
New: https://docs.cloudron.io/domains#certificates

When I run sudo systemctl --failed I see that the service is not running. (Ubuntu: 24.04.4 LTS (Noble Numbat))

UNIT                       LOAD   ACTIVE SUB    DESCRIPTION
● unbound-resolvconf.service loaded failed failed Unbound asyncronous resolvconf update helper

Logs:

Apr 27 18:05:19 my.example.org systemd[1]: Started unbound-resolvconf.service - Unbound asyncronous resolvconf update helper.
Apr 27 18:05:19 my.example.org resolvconf[870]: Dropped protocol specifier '.unbound' from 'lo.unbound'. Using 'lo' (ifindex=1).
Apr 27 18:05:19 my.example.org resolvconf[870]: No DNS servers specified, refusing operation.
Apr 27 18:05:19 my.example.org systemd[1]: unbound-resolvconf.service: Main process exited, code=exited, status=1/FAILURE
Apr 27 18:05:19 my.example.org systemd[1]: unbound-resolvconf.service: Failed with result 'exit-code'.

I found a related PR https://github.com/NLnetLabs/unbound-manual/pull/55, which is part of

https://unbound.docs.nlnetlabs.nl/en/latest/use-cases/local-stub.html#configuring-the-local-stub-resolver

I am not an expert at the area. But I believe cloudron does not need this service.

I disabled and mask it in one cloudron instance, until now everything seems to working and sudo systemctl --failed is clean again.

sudo systemctl mask unbound-resolvconf.service
sudo systemctl disable --now unbound-resolvconf.service

Is this service required for Cloudron, or is it safe to keep masked?

Please change the title to "Compress database dump when ..."

This is configured in https://example.org/#/email-settings.

Doc https://docs.cloudron.io/email#address-blocklist

Fyi: The frontend uses the same API, so you should see a request to this endpoint.

Use case 1: In one instance I see multiple started, but not finished backup cleaner jobs with the same log message.

box:taskworker Starting task 3335. Logs are at /home/yellowtent/platformdata/logs/tasks/3335.log
box:backupcleaner run: retention is {"keepWithinSecs":604800}
box:shell mounts: mountpoint -q -- /mnt/cloudronbackup
box:database Connection 422 error: Packets out of order. Got: 0 Expected: 7 PROTOCOL_PACKETS_OUT_OF_ORDER

Use case 2: In another instance other error, but also started but not finished.
retention is

{"keepDaily":3,"keepWeekly":4,"keepMonthly":6}

...
2024-11-29T03:30:29.878Z box:tasks update 21410: {"message":"Removing app backup (b178e0a6-ffe8-4ede-976c-c382f998a50d): app_b178e0a6-ffe8-4ede-976c-c382f998a50d_v3.55.0_97d403e1"}
2024-11-29T03:30:30.451Z box:tasks update 21410: {"message":"2024-11-14-030035-138/app_n8n.example.org_v3.55.0: Removing directory /mnt/cloudronbackup/my_example_org/2024-11-14-030035-138/app_n8n.example.org_v3.55.0"}
2024-11-29T03:30:30.523Z box:tasks update 21410: {"message":"Removing directory /mnt/cloudronbackup/my_example_org/2024-11-14-030035-138/app_n8n.example.org_v3.55.0"}
2024-11-29T03:30:30.524Z box:shell filesystem: rm -rf /mnt/cloudronbackup/my_example_org/2024-11-14-030035-138/app_n8n.example.org_v3.55.0
2024-11-29T03:38:00.508Z box:backupcleaner removeBackup: unable to prune backup directory /mnt/cloudronbackup/my_example_org/2024-11-14-030035-138: ENOTEMPTY: directory not empty, rmdir '/mnt/cloudronbackup/my_example_org/2024-11-14-030035-138'
2024-11-29T03:38:00.521Z box:backupcleaner removeBackup: removed 2024-11-14-030035-138/app_n8n.example.org_v3.55.0
...

Use case 2: The Jobs are finished now as a error. Some magic or the there is a hidden timeout.

I would like to see this bugfix already in 8.3.x. Please <3.

Cloudron-Version: 9.1.5
Cli-Version: 8.0.1
Node-Version: v20.20.2

Full error message:

file:///usr/lib/node_modules/cloudron/src/actions.js:1507
                        stdout.resume(); // drain readable side of Duplex/Transform streams so autoDestroy emits 'close'
                               ^
TypeError: stdout.resume is not a function
    at TLSSocket.<anonymous> (file:///usr/lib/node_modules/cloudron/src/actions.js:1507:32)
    at TLSSocket.emit (node:events:536:35)
    at endReadableNT (node:internal/streams/readable:1698:12)
    at process.processTicksAndRejections (node:internal/process/task_queues:82:21)

I do not speak so much JavaScript, therefore I ask my computer (claude ;-)), so do not trust 100% the cause/fix.

Steps to reproduce

cloudron pull --app <location> /tmp/somefile.gz .

Any pull of a single file (remote path without trailing /) crashes with:

TypeError: stdout.resume is not a function
    at TLSSocket.<anonymous> (file:///usr/lib/node_modules/cloudron/src/actions.js:1507:32)

Root cause

In src/actions.js, runExecSession is called with a fs.createWriteStream as stdout. When the socket closes, the code does:

if (stdout !== process.stdout && typeof stdout.end === 'function') {
    stdout.on('close', () => resolve());
    stdout.end();
    stdout.resume(); // drain readable side of Duplex/Transform streams
}

The comment acknowledges that resume() is only meaningful on Duplex/Transform streams. However, the guard condition only checks for stdout.end, which is true for any Writable — including fs.WriteStream. Since fs.WriteStream is a plain Writable and not a Duplex, it has no resume() method.

Fix

Add a check before calling resume():

if (typeof stdout.resume === 'function') stdout.resume();

Workaround

Downgrade to v7.1.2.

Checked this on a cloudron which created 3 month ago. resolvconf not installed, but unbound-resolvconf.service.

@scooke

To download/install OpenCulturas just run composer create-project --remove-vcs drupal/openculturas_project example.org and then create a symlink for public which links to example.org/web. I believe you need to remove the public directory before you can do it.

Then you can install it via browser. Use the credentials from credentials.txt for database. When installed, it is better to replaces the strings in web/sites/default/settings.php with getenv('CLOUDRON_MYSQL_HOST'). So that you can create a copy, and it uses the new credentials and not the credentials from the other app.