Cloudron Forum

caspear

Without the DNS entry mail from cloudron ends up with

ARC-Authentication-Results: i=1; mx.google.com;
       dkim=pass header.i=@smtpcorp.com header.s=a1-4 header.b=38VpoA5C;
       dkim=pass header.i=@permamed.org header.s=s1004192 header.b=IvzZvAEF;
       dkim=permerror (no key for signature) header.i=@permamed.org header.s=cloudron-0d9262 header.b=cSc2yqyX;
       spf=pass (google.com: domain of bounce.3wqhqixyft3pua6=46muc2596w7f=34l98tc3oj4uzw@em1004192.permamed.org designates 158.120.86.203 as permitted sender)

Once I add the entry I get

ARC-Authentication-Results: i=1; mx.google.com;
       dkim=pass header.i=@smtpcorp.com header.s=a1-4 header.b=hge5ICDL;
       dkim=pass header.i=@permamed.org header.s=s1004192 header.b=HnqT1ibh;
       dkim=pass header.i=@permamed.org header.s=cloudron-0d9262 header.b="bpPl/+t5";
       spf=pass (google.com: domain of bounce.w5qkkdyfnaxsxb7=ojoiat7bxbcy=pc4cfvy7huru7n@em1004192.permamed.org designates 158.120.86.203 as permitted sender)

caspear

Send an email through the Cloudron and look at the mail headers in the mail you end up with.

It will include DKIM signature from Cloudron, which fails to validate if the DNS entry is missing.

DMARC reports will also list it as an issue, if you have that configured.

caspear

When external SMTP relay is configured Cloudron still signs all outgoing mail with DKIM, but the UI hides the DNS entry it wants.

Without the matching entry some mail servers then reject the mail because of the DKIM failure.

Please either:

Do not sign the mail when using external relay to send mail
Expose the expected DKIM DNS entry to the end user so that they can configure it

The half-way house does not work.

As a workaround I disabled external relay to reveal the DNS entry, created the DNS entry, and then added the SMTP relay back again.

caspear

I changed nothing, but it is working today.

I imagine what is happening is that the upstream storage drops connections occasionally and cloudron simply passes that on to the user instead of having a retry loop in the background.

So, I still believe this functionality would benefit from being more robust, as before it would manage 20-50MB per go before drop, and if the thing was in a retry loop it would be able to get the archive out by just resuming downloads.

I realise it is annoying having to deal with people who insist on unreliable storage... but it is what we have.

caspear

Sometimes it breaks almost instantly, at other times it manages to go for a few seconds and get to 20-30MB before crashing.

caspear

2026-03-05T16:02:10.196Z box:apphealthmonitor app health: 30 running / 6 stopped / 0 unresponsive
2026-03-05T16:02:39.547Z box:server ==========================================
2026-03-05T16:02:39.549Z box:server            Cloudron 9.0.17  
2026-03-05T16:02:39.549Z box:server ==========================================
2026-03-05T16:02:39.550Z box:platform initialize: start platform
2026-03-05T16:02:39.551Z box:tasks stopAllTasks: 0 tasks are running. sending abort signal
2026-03-05T16:02:39.551Z box:shell tasks: /usr/bin/sudo --non-interactive /home/yellowtent/box/src/scripts/stoptask.sh all
2026-03-05T16:02:39.665Z box:locks releaseAll: all locks released
2026-03-05T16:02:39.671Z box:reverseproxy writeDashboardConfig: writing dashboard config for thedigitalcircle.org
2026-03-05T16:02:39.687Z box:shell reverseproxy: /usr/bin/sudo --non-interactive /home/yellowtent/box/src/scripts/restartservice.sh nginx
2026-03-05T16:02:40.402Z box:platform onActivated: starting post activation services
2026-03-05T16:02:40.402Z box:platform startInfra: checking infrastructure
2026-03-05T16:02:40.403Z box:platform startInfra: infra is uptodate at version 49.9.0
2026-03-05T16:02:40.403Z box:platform onInfraReady: platform is ready. infra changed: false
2026-03-05T16:02:40.403Z box:apps schedulePendingTasks: scheduling app tasks
2026-03-05T16:02:40.451Z box:apptaskmanager started
2026-03-05T16:02:40.452Z box:cron startJobs: starting cron jobs with hour 15 and minute 28
2026-03-05T16:02:40.499Z box:cron handleBackupScheduleChanged: schedule 00 00 23 * * * (Europe/London)
2026-03-05T16:02:40.503Z box:cron autoupdatePatternChanged: pattern - 00 00 1,3,5,23 * * * (Europe/London)
2026-03-05T16:02:40.508Z box:cron Dynamic DNS setting changed to false
2026-03-05T16:02:40.510Z box:dockerproxy start: listening on 172.18.0.1:3003
2026-03-05T16:02:43.334Z box:shell system: lsblk --paths --bytes --json --list --fs --output +rota,fsused,fsavail
2026-03-05T16:02:50.227Z box:apphealthmonitor app health: 30 running / 6 stopped / 0 unresponsive

caspear

On Cloudron admin UI go to My Apps page.
Press the little cog button in the top right corner of an App.
Select "Backups" in list of pages that appears.
In the list of backups that comes up press the thee dots button to the right of the most recent backup.
Press "Download".
Observe a download start.
Observe the download stop.
Observe a red "Cloudron is offline" bar come up on top of the page.
Observe Cloudron restart itself.
Attempt resuming the download.
Observe Download break.
Observe Cloudron restart itself
...

Is this sufficient detail or would you like me to include some screenshots?

caspear

Only post Cloudron or server issues in this topic. Use the specific app category for app issues.

Please include a detailed description of the problem. Include screenshots when applicable.

Attempting to download a backup archive of a service ends up with the whole cloudron crashing, the download stopping, and a message in the log to appear that reads:

Cloudron started with version 9.0.17

Backups are running without issues and the configured storage is

Storage: scaleway-objectstorage (tgz) at Amsterdam (NL-AMS) / dc1 / backups

Run cloudron-support --troubleshoot on your server and post the output here like this:

root@cloudron-1:~# cloudron-support --troubleshoot
Vendor: Hetzner Product: vServer
Linux: 5.15.0-157-generic
Ubuntu: jammy 22.04
Execution environment: kvm
Processor: AMD EPYC-Rome Processor x 16
RAM: 32086348KB
Disk: /dev/sda1       187G
[OK]	node version is correct
[OK]	IPv6 is enabled and public IPv6 address is working
[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]	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
[OK]	Service 'mongodb' is running and healthy
[OK]	Service 'mail' is running and healthy
[OK]	Service 'graphite' is running and healthy
[OK]	Service 'sftp' is running and healthy
[OK]	box v9.0.17 is running
[OK]	Dashboard is reachable via domain name
[OK]	Domain thedigitalcircle.org is valid and has not expired

Check for any errors in /home/yellowtent/platformdata/logs/box.log

Delete everything above before making a new post.

caspear

Confirmed fixed.

You are wonderful.

caspear

Description:
When using the LimeSurvey Cloudron app:

Accessing /admin/index.php works correctly.

Accessing /admin alone redirects to http://example.app:8000/admin/ and hangs.

This happens because the LimeSurvey rooturl configuration is not automatically set to the Cloudron public URL. The redirect uses the internal service port instead of the public domain.

Steps to Reproduce:

Install LimeSurvey on Cloudron.

Navigate to https://<your-domain>/admin.

Observe the redirect to internal port :8000 and failure to load.

Navigate to https://<your-domain>/admin/index.php — page loads correctly.

Expected Behavior:
/admin should redirect to the correct public URL and load the admin interface.

Additional Notes:

Setting rooturl manually in application/config/config.php fixes the issue, but the config is reset when the service is restarted.

Suggestion: Cloudron should automatically set and persist rooturl based on the app’s public domain.

caspear

We need the functionality quite badly - is there anything that I can do to expedite the bump?

caspear

Please bump PHP to 8.2 to resolve this issue in Leantime:

https://github.com/Leantime/leantime/issues/2970

Thanks!

Cloudron makes it easy to run web apps like WordPress, Nextcloud, GitLab on your server. Find out more or install now.

Cloudron Forum

caspear

Posts