Cloudron Forum

@girish Yes, all sorted, thank you for asking.

Thanks to @robi's suggestion all we needed to do was the following:

• in terminal window for our WordPress app, at /app/code/wp-content/uploads we created a symlink (ln -s /media/ovitest ovitest) and then updated its permissions, just in case (chown -R www-data:www-data ovitest)
• then we could access the mp4 at https://<our_web_domain>/wp-content/uploads/ovitest/Red-cloud.mp4

Thank you very much all; we did enjoy finding the fix in the end. And of course we will make good use of it as we can now keep 10-20 GB of data, or even more, outside the WordPress data container, so out of the backup, but still reference this content on our website, which is great.

Hi Cloudron Forum!

We have 3 websites hosted on Cloudron, I'll detail some email scenarios where we'd appreciate some advice / guidance from those of you who have been there already.

domain1
Manual DNS setup in Cloudron, but in Email | Status tab all is green (MX / DKIM / SPF / DMARC / PTR / outbound SMTP direct / IP address not on a blocklist)
Email relay on Outbound tab is via Built-in SMTP server
When emailing an Office 365 / Exchange Online mailbox our emails get delivered to Junk Mail; analysing the email header there is only 1 issue: DKIM Authenticated (this according to mxtoolbox); namely, from the mxtoolbox report:

dkim:domain1:cloudron-<domain1_domainkey>
DKIM public record (in green)
v=DKIM1; t=s; p=MIG...<long alphanumeric string>
DKIM signature (in red)
v=1; a=rsa-sha256; c=relaxed/simple; d=domain1; s=cloudron-<domain1_domainkey>; h=from:subject:date:message-id:to:mime-version; bh=<some body hash string>=; b=<some other long alphanumeric string>=
PS: The failed test is "DKIM Signature Body Hash Verified" and the result is "Body Hash Did Not Verify".

Why would the DKIM Authenticated element be flagged as an error? Our DKIM record is correct, so the DKIM email signature should be derived from it without any issues; the email in question is DMARC Compliant, but still it ends up in Junk on O365.

As an aside, I must note the email was sent with rich text formatting; if the email is sent to Hotmail in plain text, the email headers check out perfectly, green all round, yet the outcome is the same, still gets labelled as spam. Now, why would plain text or rich text have any bearing on the DKIM Authenticated element passing or failing as far as mxtoolbox analyse headers is concerned, to me this makes no sense at all. But it does seem to suggest the outcome is driven by something else, not just the technical setup per se.

If from Roundcube webmail we email any icloud.com address we get this bounceback message:

Final-Recipient: rfc822;<name>@icloud.com
Action: failed
Status: 5.7.0
Remote-MTA: mx02.mail.icloud.com
Diagnostic-Code: smtp;554 5.7.0 Blocked - see https://support.proofpoint.com/dnsbl-lookup.cgi?ip=<our IP address>

So whilst Cloudron says our IP address is not on a blocklist, icloud.com must have us blocked, right? Is O365 blocking us as well?

Let me link the 2 scenarios together with a surprising outcome; we have a free Mailchimp account for domain1 (we email our paying members), where domain1 is verified and authenticated as an email domain. From there we can send to icloud.com just fine (likely because Mailchimp is the sender on our behalf, so emails don't go out from our IP address) and we can deliver emails to O365 Inboxes too (the surprising element being that if you analyse the O365 email headers it's a Christmas tree of red lights: DMARC fail, SPF fail, DKIM fail, yet it gets to Inbox?!). What's the moral of this story? Mailchimp good, our Roundcube webmail bad? I'm specifically interested in deliverability to O365 and other enterprise grade email systems. Our emails get to Junk in Hotmail too, regardless of plain text or rich text, which is what makes me think that sender reputation or being blocked are just as, if not more important than our technical setup being correct, which it is.

Finally, on domain3, same setup as domain1 with the exception of a GoDaddy automatic Domain / DNS setup in Cloudron, we get pretty much the same issues, outgoing emails go to Junk. The plain text "trick" when emailing O365 does not yield a perfectly clean mxtoolbox email headers analysis, but then it seems this is not enough any way for a successful Inbox delivery. We have tried to relay through a free Mailjet account on domain3, but this was a waste of time as ultimately we discovered that the underlying Mailjet mail server was blacklisted on 2-3 sites hence the waste of time.

So, how can we send legitimate emails out successfully from Cloudron and have them reach recipients' Inboxes? We are not spammers, nor are we selling anything, so I'm keen to cover all the bases and tick all the boxes. The emails we want to send are directed at specific people to raise awareness of various topics (one email and that's it, pretty much); they engage with us, fine, they don't, fine again, bu I mention this because we can't use Mailchimp as the T's and C's of that platform (as well as others presumably) are that you can only email subscribers (and our intended audience are not subscribers, but one off / hand picked people) or else you fall fault of spam rules and legislation, hence why we are staying clear of that.

Are there other free mail relay services which can be relied upon? Or does one need to get a paid service for that level of service and end result, i.e. Inbox deliverability? At the moment, given the hit and miss results and baffling analysis of email headers, I must say I'm not really sure.

Thank you for reading and thank you in advance for any ideas / advice you have; hopefully this post proves helpful to others as well.

THI Staff

It seems we found a way forward, using a different mail relay provider; fundamentally the process is the same, but if there is a difference in the technical implementation then it is the fact this new provider requires CNAME records to be created instead of TXT records for SPF and DKIM as was the case for MailJet; and the emails land in the inbox now. Moral of the story perhaps being that if you fail once, get up and try again.

That worked @girish
cloudron-support --troubleshoot found a certificate which does not exist and so removed a conf file
nginx started promptly
After which the Cloudron apps could be restarted just fine
Thank you once again for your help

@girish said in What's coming in 8.0:

w00t, I have fixed the long-standing issue of backups getting stuck (usually, it would says @0Mbps) . Fix is in 8.0.1 (not released).

@girish Bingo! We might be affected by that very issue: backups getting stuck @0Mbps (in the middle of a managed WP version upgrade, all be it a minor upgrade)
Just logged this ticket
https://forum.cloudron.io/topic/12123/wordpress-app-container-stuck-on-updating-from-package-version-3-7-2-to-3-7-3

If the fix is to upgrade to Cloudron v8.0.1, I'll need to look at that because just like @eddowding we are currently running v7.7.2 (due to our, let's say, lack of human resources and time)

Thank you, guys! Great forum and community here, and not for the first time!

@luckow Thinking about it, maybe it was Postal that I came across before and didn't save that webpage; it certainly wasn't on postalserver.io, the webpage had a different design and look and feel, but the content and complexity of the technical setup seems pretty similar; thank you again.

Hi Cloudron guys and forum

One of our website certificates is failing to renew; we have 2 websites hosted on Cloudron, both with the same setup, both on GoDaddy, one is fine, the other isn't (expired certificate error).

We renewed all certificates manually in Cloudron 3 times today, the Renew section shows all green, yet under the Event log we can see the certificate for one of the website is failing to renew / apply.

This is something for Cloudron to fix, right? And how do we log a formal support call with Cloudron as I really don't want to share sensitive details here?

Thank you all.

THI Staff

I've just sent an email with the supporting information to support@cloudron.io
Thank you in advance

@girish All sorted; schoolboy error on my part. Thank you again

For future readers, the error was that the domain was not hosted on GoDaddy

Correct; we were hosted on GoDaddy, but created a subdomain for another website, which we moved to another hosting company, we moved the domain there in the process and then forgot to update the Cloudron domain setup to change the provider from GoDaddy to Cloudflare.

Great support by the way, I must say; I work in IT support myself, but web hosting is not my main expertise

@girish said in WordPress app container stuck on updating from package version 3.7.2 to 3.7.3:

This happens with apps which contains files that change their size when the backup is going on. ... Maybe you have some plugin that writes to somewhere periodically?

Thank you @girish Great advice and just the clue we needed. We figured out what that was, stopped it and then we could take a WP backup manually; and then we were also able to update to the latest packaged WP version 3.8.0

Thank you once again; your prompt help is much appreciated

You can mark this ticket as resolved; cheers!

Hi All

Could you help with the following issue please?

Short version
Following a successful Cloudron platform upgrade, all our apps now display the following error:
Error : Nginx Error - Error reloading nginx: reverseproxy exited with code 1 signal null

The apps / services run ok; the only issues are 1) no backups were taken since the Cloudron platform upgrade, likely due to the app error status and 2) the apps can't be stopped / restarted likely due to the same error.

The underlying cause must be related to certificates, I would guess, so upon checking the renew certificates log I found these telling lines:

Apr 08 02:15:47 box:shell nginx: [emerg] cannot load certificate "/home/yellowtent/platformdata/nginx/cert/_.<our_website>.<our_cloudron_domain>.cert": BIO_new_file() failed (SSL: error:02001002:system library:fopen:No such file or directory:fopen('/home/yellowtent/platformdata/nginx/cert/_.<our_website>.<our_cloudron_domain>.cert','r') error:2006D080:BIO routines:BIO_new_file:no such file)
Apr 08 02:15:47 box:shell reverseproxy: /usr/bin/sudo -S /home/yellowtent/box/src/scripts/restartservice.sh nginx errored BoxError: reverseproxy exited with code 1 signal null
Apr 08 02:15:47 at ChildProcess.<anonymous> (/home/yellowtent/box/src/shell.js:137:19)
Apr 08 02:15:47 at ChildProcess.emit (node:events:519:28)
Apr 08 02:15:47 at ChildProcess._handle.onexit (node:internal/child_process:294:12) {
Apr 08 02:15:47 reason: 'Shell Error',
Apr 08 02:15:47 details: {},
Apr 08 02:15:47 code: 1,
Apr 08 02:15:47 signal: null
Apr 08 02:15:47 }
Apr 08 02:15:47 box:taskworker Task took 347.55 seconds
Apr 08 02:15:47 box:tasks setCompleted - 8714: {"result":null,"error":{"stack":"BoxError: Error reloading nginx: reverseproxy exited with code 1 signal null\n at reload (/home/yellowtent/box/src/reverseproxy.js:188:22)\n at process.processTicksAndRejections (node:internal/process/task_queues:95:5)\n at async checkCerts (/home/yellowtent/box/src/reverseproxy.js:698:9)","name":"BoxError","reason":"Nginx Error","details":{},"message":"Error reloading nginx: reverseproxy exited with code 1 signal null"}}

Interestingly <our_website> is the only domain set up with manual DNS configuration in Cloudron, but this has been the case for years and it worked/works, until the latest Cloudron platform upgrade. But sure, the renew certificates log above is correct, there is no cert file at /home/yellowtent/platformdata/nginx/cert/_.<our_website>.<our_cloudron_domain>.cert but it should not be looking for one locally on our server, should it?

Longer version
The Cloudron platform upgrade from v8.2.4 to v8.3.1 was successful on 29/03/2025. Our last Cloudron app backups are from 29/03/2025 as well.

Our Cloudron apps now have a status of:
Error : Nginx Error - Error reloading nginx: reverseproxy exited with code 1 signal null

Starting up development instances of Cloudron apps (which are not running normally) gets a status of "Starting - Configuring reverse proxy", which after it sticks around for way too long, errors out with the same message as above. Trying to repair the app with the "Retry start app task" leads nowhere other than the same error being displayed again. And we can't stop any of these apps either, but they are nevertheless running.

All the renew certificates logs since 29/03/2025 have an error red x next to them; the relevant log output is mentioned above. Why is the reverse proxy getting stuck looking for the certificate of <our_website> which we have on manual DNS setup in Cloudron? And how do we tell it to not check this certificate any more? I'm guessing this is where the issue is.

Funny enough, according to the Cloudron event log, the certificate install for www.<our_website> succeeded on 01/04/2025 (proving the manual DNS setup has worked for years), this is 3 days after the Cloudron platform upgrade on 29/03/2025 but obviously the reverse proxy doesn't know / isn't happy with the certificate for <our_website> for whatever reason.

Can you advise how we fix this please? Thank you in advance.

THI Staff