Cloudron Forum

I’ll be happy, when the policy and persistent config are kept on cloudron updates or when I install new app with such redis config and cloudron sets this as an initial config. However, this should also be documented on the add-on page.

I verify on another instance that cloudron did not set the maxmemoryPolicy/persistent config on a deployment, it was necessary to resave the redis service.

Since Cloudron v10 it is possible to set the redis maxmemoryPolicy via manifest.

We use redis for caching and set the allkeys-lru maxmemoryPolicy, but today since cloudron updated to 10.0.4, it seems the policy was reset to his default maxmemory-policy. The app could not caching anymore, because it reached the maxmemory, which can not happen with the policy.

Roll back for GitLab is a no-go thing. Let's hope that Gitlab does not do something in future update release which would prevent using it.

Warning when navigating inside the backend after upgrade to v19.

Database 'main' is using PostgreSQL 16.11, but this version of GitLab requires PostgreSQL 17. Please upgrade your environment to a supported PostgreSQL version. See database requirements for details.

https://docs.gitlab.com/install/requirements/#database

I wonder that is possible to start the app, perhaps GitLab does not block when configured an external DB.

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

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

@girish

resolvconf is not installed. Perhaps purging resolvconf does not uninstall this.

dpkg -s resolvconf
dpkg-query: package 'resolvconf' is not installed and no information is available
Use dpkg --info (= dpkg-deb --info) to examine archive files.

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?

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.

The link behind the ?.

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

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.

Oh sorry.

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

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

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.

@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

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)

@nebulon

Thanks. Works.

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"]
}

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

Yes to use it together with Gitlab app, the user management is not openid as documented in cloudron docs.