Cloudron Forum

Environment:

• Cloudron Version: 9.1.3

Description:
I’ve noticed a minor UI bug on the dashboard regarding how External Links are handled by the "Search App" filter. The search function appears to scan the underlying URL string but completely ignores the custom display label assigned to the link.

This becomes an issue when linking to local services via raw LAN IPs (e.g., a local NAS) where the service name isn't inherently in the URL.

Steps to Reproduce:

1. Create a new External Link on the dashboard.
2. Set the URL to a raw IP address (e.g., http://10.69.10.104:5000/#/signin).
3. Set the Title/Label to something distinct, like Synology DSM.
4. Go to the dashboard and type "Synology" into the Search App field.

Expected Behavior:
The search filter should match the query against the custom label ("Synology DSM") and display the tile.

Actual Behavior:
The search returns no results because it is only parsing the 10.69.10.104 URL string.

Current Workaround:

• Modifying the URL to use local DNS (e.g., http://synology.local:5000) inserts the keyword into the URL string, causing the search to successfully find it.

Would be great to see the custom label added to the search index in a future release!

@joseph quick question, does the cloudron backup include the custom.conf file if it exists on the server?

Disregard, it was a firewall issue on my DMZ VLAN. Please close/delete this topic.

Environment:

• Hardware: Mini PC (Bare-metal)
• OS: Ubuntu 24.04.4
• Cloudron Version: 9.1.3
• Internal IP: 10.69.69.69
• Router/DNS/Firewall IP: 10.69.69.1
• Cloudron Mailserver: my.domain.tld

Problem Description:
I recently migrated my Cloudron installation from a Synology VM to a bare-metal install. Since then, Paperless-ngx cannot connect to the internal Cloudron Mail server via the public FQDN (my.domain.tld) to ingest email attachments for processing.

Diagnostics:

• nc -zv 10.69.69.69 993 from the app terminal succeeds.
• nc -zv my.domain.tld 993 from the app terminal does not receive any response.
• Per the paperless mail.log [ERROR] [paperless_mail] Error while retrieving mailbox Paperless: [Errno 110] Connection timed out.
• Inside the container, the domain resolves to the Public IP rather than the local IP, leading to a loopback failure on my UniFi UDM SE.
• Attempts to override this via /etc/unbound/unbound.conf.d/custom.conf have not been successful in getting the container to prioritize the local IP.

# Forward all queries to the network's internal DNS 10.69.69.1. 
forward-zone:
  name: "."
  forward-addr: 10.69.69.1

Request:
What is the recommended Cloudron-native way to force apps to resolve the Mail server to the local host IP (10.69.69.69) to avoid Hairpin NAT issues, specifically for a bare-metal installation?

Note:
I already have a local DNS A record set up on the Unifi UDM SE that points the local IP (10.69.69.69) to domain.tld.

Updated and confirm that it is working, thank you!

I am testing the new unstable release of Docmost and encountering a consistent 400 Bad Request error when attempting to use the file attachment feature in the editor. The upload fails immediately, regardless of file size (tested with files as small as 30kb).

Environment:

Host: Cloudron 9.1.3
App: Docmost 0.70.3

Steps to Reproduce:

1. Install the unstable Docmost app.
2. Open any document and attempt to insert an attachment or image.
3. Select a small file (e.g., 30kb).
4. The UI throws an upload error, "Error processing file upload."

App Logs:
The logs show a clear BadRequestException indicating the storage backend is either unconfigured or inaccessible:

2026-03-22T16:08:56Z {"level":"error","time":"2026-03-22T16:08:56.462Z","pid":92,"hostname":"914b186f-aa30-4c30-929d-c63219d35ecf","req":{"method":"POST","url":"/api/files/upload","ip":"X.X.X.X","userAgent":"Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/26.3.1 Safari/605.1.15"},"context":"AttachmentController","err":{"type":"BadRequestException","message":"Error uploading file to drive","stack":"BadRequestException: Error uploading file to drive\n    at AttachmentService.uploadToDrive (/app/code/apps/server/dist/core/attachment/services/attachment.service.js:176:19)\n    at async AttachmentService.uploadFile (/app/code/apps/server/dist/core/attachment/services/attachment.service.js:68:9)\n    at async AttachmentController.uploadFile (/app/code/apps/server/dist/core/attachment/attachment.controller.js:89:34)","response":{"type":"Object","message":"Error uploading file to drive","stack":"","error":"Bad Request","statusCode":400},"status":400,"options":{},"name":"BadRequestException"},"msg":"Error uploading file to drive"}
2026-03-22T16:08:56Z {"level":"error","time":"2026-03-22T16:08:56.462Z","pid":92,"hostname":"914b186f-aa30-4c30-929d-c63219d35ecf","req":{"method":"POST","url":"/api/files/upload","ip":"X.X.X.X","userAgent":"Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/26.3.1 Safari/605.1.15"},"context":"AttachmentService","msg":"Error uploading file to drive:"}

Expected Behavior:
The app should successfully accept the file and store it in the designated local storage path within /app/data/.

Temporary work-around for anyone experiencing the same issue:

1. Access the SQL DB via the Cloudron App Terminal
2. Manually elevate the user via SQL:

UPDATE tc_users SET administrator = 1, userlimit = -1 WHERE email = 'user@domain.com'

3. Do whatever admin tasks you need to do, noting that admin permissions will be removed at next login or app restart.

The bug must be relatively recent because I was able to add a device on March 5th when I was running Traccar 6.12.0. Cloudron instance was updated to 9.1.3 on March 7th.

Today I went in to add some more devices and experienced the aforementioned issue.

Environment

• Cloudron Version: 9.1.3
• App: Traccar 6.12.2
• User Management: Enabled (Cloudron SSO)

Description

When a user logs in via Cloudron SSO, their administrative permissions within Traccar are automatically reverted to a standard "User" status. Even after manually elevating the user in the database (setting administrator = 1 and userlimit = -1 in the tc_users table), the changes are overwritten the moment the user authenticates via SSO or the app is restarted.

This creates a persistent "Write Access Denied" state for the primary administrator, preventing the management of devices, geofences, or server settings.

Steps to Reproduce

1. Install Traccar on Cloudron with User Management (SSO) enabled.

2. Login via SSO (Initial status is a standard user).

3. Manually elevate the user to admin in the Traccar UI.

4. Confirm Admin access is active in the Traccar UI (Settings and Server menus are visible).

5. Log out and log back in via Cloudron SSO, or restart the app.

6. The user's administrator status in tc_users is reverted to 0x00, and administrative access is lost.

SQL: SELECT email, administrator FROM tc_users WHERE email = '[redacted]';

Expected Behavior
The Cloudron SSO sync should respect existing administrator flags within the Traccar database.

I was attempting to send user invitations via the Stirling-PDF app but noticed the SMTP settings are currently unconfigured. Looking at the package, it appears that Managed SMTP isn't currently enabled for this app.

Could we update the Cloudron app to include the Cloudron SMTP app relay? This would allow the app to automatically use Cloudron’s built-in mail server settings via environment variables, rather than requiring users to manually configure external SMTP credentials within the app UI.

Thank you @James for your support with this. I was looking at creating a bug report for Penpot but noticed that @brutalbirdie has already done it. Thanks all !

https://github.com/penpot/penpot/issues/8590

Yes it is reproducible on Chrome, but Firefox works fine. I think we have a similar issue with Cubby: https://forum.cloudron.io/topic/15150/dropping-folders-flattens-the-folder-content-on-upload

Wonder if they (Filemanager and Cubby) are using a similar mechanism in the background

Hi @James , noted, will send you a DM with the link to the HAR file shortly. Thanks in advance for your assistance!

Additionally, when I open the penpot homepage, there is an orange dialog box that briefly opens in the window and then immediately disappears before I can see what it is about. I will try to troubleshoot it this weekend.

There is a 400 Error on OIDC POST:

Mar 11 11:37:00 172.18.0.1 - - [11/Mar/2026:08:37:00 +0000] "GET /api/rpc/command/get-profile HTTP/1.1" 200 95 "-" "Mozilla (CloudronHealth)"
Mar 11 11:37:10 172.18.0.1 - - [11/Mar/2026:08:37:10 +0000] "GET /api/rpc/command/get-profile HTTP/1.1" 200 95 "-" "Mozilla (CloudronHealth)"
Mar 11 11:37:20 172.18.0.1 - - [11/Mar/2026:08:37:20 +0000] "GET /api/rpc/command/get-profile HTTP/1.1" 200 95 "-" "Mozilla (CloudronHealth)"
Mar 11 11:37:25 172.18.0.1 - - [11/Mar/2026:08:37:25 +0000] "GET / HTTP/1.1" 200 163106 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/145.0.0.0 Safari/537.36"
Mar 11 11:37:25 172.18.0.1 - - [11/Mar/2026:08:37:25 +0000] "GET /js/config.js?version=develop HTTP/1.1" 200 129 "https://[REDACTED_PENPOT_DOMAIN]/" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/145.0.0.0 Safari/537.36"
Mar 11 11:37:26 172.18.0.1 - - [11/Mar/2026:08:37:26 +0000] "HEAD / HTTP/1.1" 200 0 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/145.0.0.0 Safari/537.36"
Mar 11 11:37:26 172.18.0.1 - - [11/Mar/2026:08:37:26 +0000] "GET /api/main/methods/get-profile HTTP/1.1" 200 79 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/145.0.0.0 Safari/537.36"
Mar 11 11:37:26 172.18.0.1 - - [11/Mar/2026:08:37:26 +0000] "GET /rasterizer.html HTTP/1.1" 200 536 "https://[REDACTED_PENPOT_DOMAIN]/" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/145.0.0.0 Safari/537.36"
Mar 11 11:37:26 172.18.0.1 - - [11/Mar/2026:08:37:26 +0000] "GET /js/config.js?version=develop HTTP/1.1" 200 129 "https://[REDACTED_PENPOT_DOMAIN]/rasterizer.html" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/145.0.0.0 Safari/537.36"
Mar 11 11:37:26 172.18.0.1 - - [11/Mar/2026:08:37:26 +0000] "GET /api/main/methods/get-profile HTTP/1.1" 200 79 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/145.0.0.0 Safari/537.36"
Mar 11 11:37:26 172.18.0.1 - - [11/Mar/2026:08:37:26 +0000] "GET /api/main/methods/get-teams HTTP/1.1" 401 135 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/145.0.0.0 Safari/537.36"
Mar 11 11:37:27 172.18.0.1 - - [11/Mar/2026:08:37:27 +0000] "POST /api/main/methods/logout HTTP/1.1" 400 218 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/145.0.0.0 Safari/537.36"
Mar 11 11:37:27 172.18.0.1 - - [11/Mar/2026:08:37:27 +0000] "GET /fonts/WorkSans-VariableFont.ttf HTTP/1.1" 200 362304 "https://[REDACTED_PENPOT_DOMAIN]/css/main.css?version=develop" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/145.0.0.0 Safari/537.36"
Mar 11 11:37:30 172.18.0.1 - - [11/Mar/2026:08:37:30 +0000] "GET /api/rpc/command/get-profile HTTP/1.1" 200 95 "-" "Mozilla (CloudronHealth)"
Mar 11 11:37:32 172.18.0.1 - - [11/Mar/2026:08:37:32 +0000] "POST /api/auth/oidc?provider=oidc HTTP/1.1" 400 138 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/145.0.0.0 Safari/537.36"**
Mar 11 11:37:40 172.18.0.1 - - [11/Mar/2026:08:37:40 +0000] "GET /api/rpc/command/get-profile HTTP/1.1" 200 95 "-" "Mozilla (CloudronHealth)"
Mar 11 11:37:50 172.18.0.1 - - [11/Mar/2026:08:37:50 +0000] "GET /api/rpc/command/get-profile HTTP/1.1" 200 95 "-" "Mozilla (CloudronHealth)"
Mar 11 11:38:00 172.18.0.1 - - [11/Mar/2026:08:37:30 +0000] "GET /api/rpc/command/get-profile HTTP/1.1" 200 95 "-" "Mozilla (CloudronHealth)"

Hi @nebulon , I just tested this on 9.1.3 and am still experiencing the issue.
Browser: Safari, Brave Browser
OS: Mac OS Tahoe 26

I upgraded from 9.0.17 to 9.1.3 yesterday and everything went smooth as butter! Thanks to the Cloudron team for the awesome work!

@James many thanks for the tips. I have followed the instructions and was able to confirm that the app's CLIENT_ID and CLIENT_SECRET exist in the Cloudron internal MySQL database.

I will try to find some time this week to do some more troubleshooting and report back if I am able to resolve the problem.

I ran curl -v https://<your-cloudron-dashboard-url>/.well-known/openid-configuration from the Penpot terminal and it connected just fine. So maybe it is not network related. More investigations to follow.