Cloudron Forum

Just updated to 9.0.2, different message again in the /#/server view and still no graphs:

box:metrics BoxError: Could not get disk stats of mapper/vg0-root
at readDiskMetrics (/home/yellowtent/box/src/metrics.js:121:27)
at async readSystemMetrics (/home/yellowtent/box/src/metrics.js:160:25)
at async pipeSystemToMap (/home/yellowtent/box/src/metrics.js:431:21)

Not using a cloud server on this one, but a dedicated one - shouldn't matter though, right?

Some other notes:

When changing the timezone in /#/system-settings, there's no indication that anything changed, a bit of visual feedback would be nice that it actually saved the changes (for the language you can see that it changed, but a "settings saved/updated" message would be nice to have).

The "Add Backup" button in /#/backup-sites is gone, but the admin user can still see "Schedule & Retention" (which both throws an error "Uncaught (in promise) TypeError: can't access property "id", day is undefined" in the console), "Content" and "Config", which both show the popup but you're not able to change anything (which is good, because those should be not there). And the Remove button shouldn't be there either, also throws an error in the console:

When in the /#/system-update view, while editing the values, the hours-dropdown doesn't show the current values and if I select one, it selects them all.

When trying to select a day, the dropdown just disappears and the console shows "TypeError: can't access property "value", item is undefined"

@james thanks, just tried, the port issue is resolved, thanks The connection delay is still there though, you think it might be worth reporting upstream?

Just updated to 9.0.1, /#/server still doesn't show stats and the trim error got replaced with this one, which is odd, because the disk stats are actually working when clicking on the "Details" button, but the rest of the graphs aren't:

box:metrics BoxError: Could not get disk stats
    at readDiskMetrics (/home/yellowtent/box/src/metrics.js:115:27)
    at async readSystemMetrics (/home/yellowtent/box/src/metrics.js:154:25)
    at async pipeSystemToMap (/home/yellowtent/box/src/metrics.js:425:21)

Browser console says this "Uncaught TypeError: can't access property "blockReadTotal", metric is undefined"

I'm currently testing the SFTPGo app and ran into a few issues:

1. When trying to connect to the FTP server (not SFTP, that works fast as expected), the connection is stuck for 10 seconds at Connection established, waiting for welcome message..., which is getting boring real quick, when you transfer files with separate connections, every action will take another 10 seconds because a new connection is getting established. Single connection mode works fine after the initial connection has been established.

Status:	Connecting to 123.123.123.123:2121...
Status:	Connection established, waiting for welcome message...
[10 second break here]
Status:	Initializing TLS...
Status:	TLS connection established.
Status:	Logged in
Status:	Retrieving directory listing...
Status:	Directory listing of "/" successful

Unrelated issue: Changing ports doesn't seem to work, I tried both, SFTP and FTP port and they both only work in the standard setting (2022 and 2121 respectively), no connection possible after changing the port. The config file looks fine, but nothing's going through.

Chiming in here since I just tested the 9.0.0 setup and ran into some issues (maybe you fixed them already, didn't check):

• After setting up the user and getting forwarded to the dashboard, I got the message "Removing containers for upgrade" at the top which never disappeared and docker didn't start properly. At some point I did a service box restart which seems to have fixed it, all service came back on after that which they didn't before.

• stats aren't working, box.log is getting spammed with

box:cron TypeError: Cannot read properties of undefined (reading 'trim')
    at readDiskMetrics (/home/yellowtent/box/src/metrics.js:117:29)
    at async readSystemMetrics (/home/yellowtent/box/src/metrics.js:154:25)
    at async Object.sendToGraphite (/home/yellowtent/box/src/metrics.js:164:20)

• /#/metrics hovering on the apps in disk usage changes width of the container, not really a problem, but doesn't look great

• /#/users I've added a bunch of users and only 10 are visible, the container has a max-height of 400px and adds scrollbars, even though there's plenty of vertical space available. Also not a problem, but not great ux

• /#/backup-sites the admin-users seems to be able to add backups ("add"-button is visible even though it shouldn't be), when clicking next, I get a 403 error with

body: Object { status: "Forbidden", message: "role 'owner' is required but user has only 'admin'" }

• /#/backup-sites when adding a MinIO destination as admin, prefix is mandatory ("prefix must be a string"), that wasn't the case until now I believe

There were a few more errors which I could't reproduce, so leaving them out for now.

Other than that, great work on everything!

@andreasdueren you're welcome, I forgot to post the Hetzner docs, they also have a bit of information on that. Speeds are fine, never had any issues with various kinds of media.

@andreasdueren yep, I did this to install and configure it:

curl https://rclone.org/install.sh | sudo bash
rclone config

after that, the config will resides in

~/.config/rclone/rclone.conf

and will look something like this (I enabled encryption too, because why not :

[backup]
type = sftp
host = u123456-sub1.your-storagebox.de
user = u123456-sub1
port = 23
pass = hashed_pwd
md5sum_command = md5 -r
sha1sum_command = sha1 -r
shell_type = unix
idle_timeout = 0

[backupcrypt]
type = crypt
remote = backup:backup

mounting:

mkdir /mnt/backup
chown -R yellowtent:yellowtent /mnt/backup
rclone mount backupcrypt: /mnt/backup \
    --crypt-password "verylonghashedpwd" \
    --crypt-password2 "evenlongerhashedpwd" \
    --vfs-cache-mode writes --daemon --transfers 3 --checkers 6 --allow-other

The last bit was the important one, without it mounting wasn't possible. You should now be able to mount the rclone thing as a volume. For whatever reason it shows the red dot, I'm guessing that's because of the fs. However, I haven't had an issue with that in months. Currently I'm mounting it manually on every machine reboot, but there are ways to mount it automatically.

@andreasdueren the setup in this case is based on rclone, is that what you're looking for? Because the regular storage box setup you probably already know of, since you posted in there as well https://forum.cloudron.io/post/32783

thanks indeed @nebulon, good stuff!

@nebulon if you click on an available day and select a timeslot, you get to the detail-view, where the links are at the bottom, next to the confirm button:

thanks @nebulon

Right after installation, Cal.com goes in a restart-loop with the following message

Sep 28 20:52:06 2025-09-28 18:52:06,154 INFO success: api-v2 entered RUNNING state, process has stayed up for > than 1 seconds (startsecs)
Sep 28 20:52:06 node:internal/modules/cjs/loader:1228
Sep 28 20:52:06 throw err;
Sep 28 20:52:06 ^
Sep 28 20:52:06 2025-09-28T18:52:06Z
Sep 28 20:52:06 Error: Cannot find module '../../../../../packages/platform/libraries/app-store.ts'
Sep 28 20:52:06 Require stack:
Sep 28 20:52:06 - /app/code/calcom/apps/api/v2/dist/apps/api/v2/src/filters/calendar-service-exception.filter.js
Sep 28 20:52:06 - /app/code/calcom/apps/api/v2/dist/apps/api/v2/src/app.js
Sep 28 20:52:06 - /app/code/calcom/apps/api/v2/dist/apps/api/v2/src/main.js
Sep 28 20:52:06 at Function._resolveFilename (node:internal/modules/cjs/loader:1225:15)
Sep 28 20:52:06 at Function._load (node:internal/modules/cjs/loader:1055:27)
Sep 28 20:52:06 at TracingChannel.traceSync (node:diagnostics_channel:322:14)
Sep 28 20:52:06 at wrapModuleLoad (node:internal/modules/cjs/loader:220:24)
Sep 28 20:52:06 at Module.require (node:internal/modules/cjs/loader:1311:12)
Sep 28 20:52:06 at require (node:internal/modules/helpers:136:16)
Sep 28 20:52:06 at Object.<anonymous> (/app/code/calcom/apps/api/v2/dist/apps/api/v2/src/filters/calendar-service-exception.filter.js:14:21)
Sep 28 20:52:06 at Module._compile (node:internal/modules/cjs/loader:1554:14)
Sep 28 20:52:06 at Object..js (node:internal/modules/cjs/loader:1706:10)
Sep 28 20:52:06 at Module.load (node:internal/modules/cjs/loader:1289:32) {
Sep 28 20:52:06 code: 'MODULE_NOT_FOUND',
Sep 28 20:52:06 requireStack: [
Sep 28 20:52:06 '/app/code/calcom/apps/api/v2/dist/apps/api/v2/src/filters/calendar-service-exception.filter.js',
Sep 28 20:52:06 '/app/code/calcom/apps/api/v2/dist/apps/api/v2/src/app.js',
Sep 28 20:52:06 '/app/code/calcom/apps/api/v2/dist/apps/api/v2/src/main.js'
Sep 28 20:52:06 ]
Sep 28 20:52:06 }
Sep 28 20:52:06 2025-09-28T18:52:06Z
Sep 28 20:52:06 Node.js v22.14.0
Sep 28 20:52:06 2025-09-28 18:52:06,501 WARN exited: api-v2 (exit status 1; not expected)
Sep 28 20:52:07 2025-09-28 18:52:07,503 INFO spawned: 'api-v2' with pid 47619

Also happens on the demo-server, any idea what's going on?

@marylou not that exact fix, but in theory we could replace certain things as well, provided the image doesn't override them again

There's an active discussion (although on a closed issue) going on, where someone posted a temporary "fix" yesterday: https://github.com/calcom/cal.com/issues/18308#issuecomment-3296191447

@james thanks for digging deeper and figuring out the port thing, I didn't have time yet to debug it myself!

I have two Mirotalks and both stopped working after upgrading past v2.2.22. I'm guessing some changes in this commit didn't work well on migrated instances. Participants can see other people join, but the loading circles never disappear, so no video and/or audio.

However, copying the .env settings, installing a fresh Mirotalk and pasting those settings worked out in the end, but it's not great if the rolling updates crash existing instances.

@james it's a Hetzner VPS (CPX51) and I admit, I'm trying to figure out the limits a bit, there are ~70 apps installed on that one, but none of those seem to be hogging a lot of RAM. Backups run at 1:00 in the morning, crash happened at ~8:00ish. I'll keep monitoring to figure out if there's a pattern, but so far I couldn't spot it.

system graphs:

htop:

This happened 2-3 times now on a MiroTalk SFU instance on a beefy machine with plenty of resources left, there are currently 2GB of RAM allocated to MiroTalk. It doesn't do that every week, but every other I would say. There aren't any calls going on since it happens quite early in the morning, no traffic or anything, logs don't say much (at least for me):

Sep 09 07:51:07 2025-09-09T05:51:07Z
Sep 09 07:51:07 ----- Native stack trace -----
Sep 09 07:51:07 1: 0xe36196 node::OOMErrorHandler(char const*, v8::OOMDetails const&) [node]
Sep 09 07:51:07 2: 0x123f4a0 v8::Utils::ReportOOMFailure(v8::internal::Isolate*, char const*, v8::OOMDetails const&) [node]
Sep 09 07:51:07 3: 0x123f777 v8::internal::V8::FatalProcessOutOfMemory(v8::internal::Isolate*, char const*, v8::OOMDetails const&) [node]
Sep 09 07:51:07 4: 0x146d1a5 [node]
Sep 09 07:51:07 5: 0x146d1d3 [node]
Sep 09 07:51:07 6: 0x148628a [node]
Sep 09 07:51:07 7: 0x1489458 [node]
Sep 09 07:51:07 8: 0x1cc6071 [node]
Sep 09 07:51:07 <--- JS stacktrace --->
Sep 09 07:51:07 <--- Last few GCs --->
Sep 09 07:51:07 Aborted (core dumped)
Sep 09 07:51:07 FATAL ERROR: Ineffective mark-compacts near heap limit Allocation failed - JavaScript heap out of memory
Sep 09 07:51:07 [37:0x12386000] 545929425 ms: Mark-Compact 1014.2 (1043.2) -> 1013.4 (1042.9) MB, pooled: 1 MB, 546.68 / 0.06 ms (average mu = 0.073, current mu = 0.037) task; scavenge might not succeed
Sep 09 07:51:07 [37:0x12386000] 545929953 ms: Mark-Compact 1014.2 (1042.9) -> 1013.4 (1043.2) MB, pooled: 1 MB, 502.80 / 0.00 ms (average mu = 0.062, current mu = 0.049) task; scavenge might not succeed
Sep 09 07:51:08 \npm notice
Sep 09 07:51:08 |
Sep 09 07:51:08 npm notice
Sep 09 07:51:08 npm notice Changelog: https://github.com/npm/cli/releases/tag/v11.5.2
Sep 09 07:51:08 npm notice New major version of npm available! 10.9.2 -> 11.5.2
Sep 09 07:51:08 npm notice To update run: npm install -g npm@11.5.2
Sep 09 07:52:06 => Healtheck error: Error: Timeout of 7000ms exceeded
Sep 09 07:52:06 => Healtheck error: Error: Timeout of 7000ms exceeded
Sep 09 07:52:06 => Healtheck error: Error: Timeout of 7000ms exceeded
Sep 09 07:52:06 => Healtheck error: Error: Timeout of 7000ms exceeded
Sep 09 07:52:06 => Healtheck error: Error: Timeout of 7000ms exceeded

Any idea what's going on there or what logs I could check for more info? After it dies it becomes unresponsive and 20 minutes later Cloudron sends the down notice via email, then I can react and restart it.

Thanks a bunch for the list @d19dotca! Quick question about the rest of the setup though: Do you still have entries in the Email ACL DNSBL Zones or is that empty because everything is handled in the custom rules? Like those:

zen.spamhaus.org
bl.mailspike.net
noptr.spamrats.com
dnsbl.sorbs.net

Or is that empty on your side?