Cloudron Forum

I'm currently looking for such a feature. We want to block any request to applications as a security measurement. It would hinder any unauthenticated request to any resource which would create a significant barrier for any application which is not supposed to be publicly accessible.
No request would reach the application if the client does not have a valid Cloudron SSO token.

Nice and practical feature on top of that: create an allow-list for resources or path-patterns which may be excluded from the proxyAuth requirement. This would allow us to selectively publish certain parts of an application.

@james said:

Was not able to reproduce this.

If the issue still persists, please contact support@cloudron.io so we can analyse this issue more detailed.

Thanks for your time. I finally realized that the issue appeared because of our restrictive umask - see Topic 15545 for details. And I already got the response, that I will run into more issues because of that. So - in hindsight - I'm sorry for bothering you because of our custom setup.

Hello @james

@james said:

Where do you see the output of --troubleshoot include your domain?

Where I replaced it with <domain>:

[OK]    Dashboard is reachable via IPv4 (https://my.<domain>)
[OK]    Dashboard is reachable via IPv6 (https://my.<domain>)
[SKIP]  Domain expiry check — whois did not return an expiry date for <domain>

@nebulon Yes. I restarted the "Filemanager" service, I restarted the whole machine. Via Web-CLI I can access the /app/data directories without any issues. When the Filemanager is opened on a Volume ("Volumes" -> "⋅⋅⋅" per volume -> "File manager") it also works fine and shows the content of all the apps in that volume.

@james Thanks. I did scramble the characters before posting the URL. BTW Why does cloudron-support --troubleshoot include my domain?

For all apps which do not use the default storage but a local ext4 volume, the File Manager shows no contents of /app/data. In the browser console I find a 404 response for fetching following URL.

https://my.<domain>/api/v1/apps/cb4e9ec7-8612-41af-bcb7-eba8ef4eec23/files//?access_token=-REDACTED-

For apps with the default stroage location (/home/yellowtent/appsdata/) the File Manager works fine.

cloudron-support --troubleshoot output:

Vendor: QEMU Product: Standard PC (i440FX + PIIX, 1996)
Linux: 6.8.0-117-generic
Ubuntu: noble 24.04
Cloudron: 9.2.0
Execution environment: kvm
Processor: Intel(R) Xeon(R) Silver 4208 CPU @ 2.10GHz
BIOS pc-i440fx-10.1  CPU @ 2.0GHz x 4
RAM: 16370192KB
Disk: /dev/mapper/ubuntu--vg-ubuntu--lv   32G
[OK]    Root disk usage is OK (47%)
[OK]    Memory usage is OK (28%)
[OK]    Clock is NTP-synchronized
[OK]    node version is correct
[OK]    IPv6 is enabled in kernel. Public IPv6 address detected
[OK]    docker is running
[OK]    docker version is correct
[OK]    MySQL is running
[OK]    netplan is good
[OK]    DNS is resolving via systemd-resolved
[OK]    unbound is running
[OK]    IPv4 HTTPS to api.cloudron.io/api/v1/helper/public_ip
[OK]    IPv6 HTTPS to api.cloudron.io/api/v1/helper/public_ip
[OK]    IPv4 HTTPS to auth.docker.io/token
[OK]    IPv6 HTTPS to auth.docker.io/token
[OK]    IPv4 HTTPS to acme-v02.api.letsencrypt.org
[OK]    IPv6 HTTPS to acme-v02.api.letsencrypt.org
[OK]    nginx is running
[OK]    dashboard cert is valid
[OK]    dashboard is reachable via loopback
[OK]    No pending database migrations
[OK]    Service 'mysql' is running and healthy
[OK]    Service 'postgresql' is running and healthy
[FAIL]  Service 'mongodb' container is not running (state: missing)!
[OK]    Service 'mail' is running and healthy
[OK]    Service 'graphite' is running and healthy
[OK]    Service 'sftp' is running and healthy
[OK]    box v9.2.0 is running
[OK]    Dashboard is reachable via IPv4 (https://my.<domain>)
[OK]    Dashboard is reachable via IPv6 (https://my.<domain>)
[SKIP]  Domain expiry check — whois did not return an expiry date for <domain>

======== Summary ========
PASS:  29
WARN:  0
FAIL:  1
SKIP:  1

Failures:
  - Service 'mongodb' container is not running (state: missing)!

For troubleshooting tips, see https://docs.cloudron.io/troubleshooting
To share a full diagnostic dump on the forum, run: cloudron-support --send-diagnostics

• Check for any errors in /home/yellowtent/platformdata/logs/box.log
  -> nothing related found

Thanks for your reply. I understand, that you are not providing support for my custom system environment.
Thus our hardening modifications follow best practice (https://www.cisecurity.org/benchmark/ubuntu_linux -- "Ensure default user umask is 027 or more restrictive")
Anyhow, I think taking care of the UMASK for the cloudron system itself and the managed applications could hardly be a bad thing. You may consider it as an improvement.

Thanks anyway. Looking forward to having a good time using cloudron on our server.

Hello!
I tried to install cloudron on a Ubuntu 24.04 machine with some security-hardened aspects. One of them being running shell-sessions under a umask of 0027.
The installation process got stuck at "Waiting for cloudron to be ready". I checked the service "box.service" and found following error preventing it from starting:

systemd[1]: Started box.service - Box.
box.js[287242]: /usr/bin/env: 'node': Permission denied
systemd[1]: box.service: Main process exited, code=exited, status=126/n/a

Further inspection showed that the local node installation

$ sudo ls -la /usr/local/node-24.13.0/
total 532
drwxr-x---  6 root root   4096 May 23 21:53 .
drwxr-xr-x 11 root root   4096 May 23 21:53 ..
-rw-r--r--  1 1001 1001 330720 Jan 12 18:03 CHANGELOG.md
-rw-r--r--  1 1001 1001 143310 Jan 12 18:03 LICENSE
-rw-r--r--  1 1001 1001  41704 Jan 12 18:03 README.md
drwxr-xr-x  2 1001 1001   4096 Jan 12 18:03 bin
drwxr-xr-x  3 1001 1001   4096 Jan 12 18:03 include
drwxr-xr-x  3 1001 1001   4096 Jan 12 18:02 lib
drwxr-xr-x  4 1001 1001   4096 Jan 12 18:02 share

You can see that the directory /usr/local/node-24.13.0/ has the permission drwxr-x--- which is limiting the usage for other users.

I suggest to set a umask cloudron install process is expecting explicitly at the beginning of the install process.

Output of cloudron-support --troubleshoot

$ sudo cloudron-support --troubleshoot
Vendor: QEMU Product: Standard PC (i440FX + PIIX, 1996)
Linux: 6.8.0-117-generic
Ubuntu: noble 24.04
Cloudron: 9.2.0
Execution environment: kvm
Processor: Intel(R) Xeon(R) Silver 4208 CPU @ 2.10GHz
BIOS pc-i440fx-10.1  CPU @ 2.0GHz x 4
RAM: 16370196KB
Disk: /dev/mapper/ubuntu--vg-ubuntu--lv   25G
[OK]    Root disk usage is OK (40%)
[OK]    Memory usage is OK (6%)
[OK]    Clock is NTP-synchronized
[OK]    node version is correct
[OK]    IPv6 is enabled in kernel. Public IPv6 address detected
[OK]    docker is running
[OK]    docker version is correct
[OK]    MySQL is running
[OK]    netplan is good
[OK]    DNS is resolving via systemd-resolved
[OK]    unbound is running
[OK]    IPv4 HTTPS to api.cloudron.io/api/v1/helper/public_ip
[OK]    IPv6 HTTPS to api.cloudron.io/api/v1/helper/public_ip
[OK]    IPv4 HTTPS to auth.docker.io/token
[OK]    IPv6 HTTPS to auth.docker.io/token
[OK]    IPv4 HTTPS to acme-v02.api.letsencrypt.org
[OK]    IPv6 HTTPS to acme-v02.api.letsencrypt.org
[WARN]  Cloudron v9.2.0 has not been set up yet. Visit https://<IP> to set up the dashboard.
[SKIP]  dashboard checks (nginx, cert, loopback, migrations, services, box, domain, expiry) — dashboard not set up

======== Summary ========
PASS:  17
WARN:  1
FAIL:  0
SKIP:  1

Warnings:
  - Cloudron v9.2.0 has not been set up yet. Visit https://<IP> to set up the dashboard.

For troubleshooting tips, see https://docs.cloudron.io/troubleshooting
To share a full diagnostic dump on the forum, run: cloudron-support --send-diagnostics