This is strange. I haven't encountered this issue before. I do have a static IP. I'm comparing the records to the ones that are working on Namecheap. The A Record IP address is the same, and so is the AAAA Record. So I'm not sure what I could change. Currently the error I'm getting when I navigate to the website is that there is a self-signed security certificate. I just tried re-establishing the domain on Cloudron and refreshing the certificates, but we are still stuck at the "Waiting for propagation" stage when installing. In my browser, the website is on the page that says "You are seeing this page because the DNS record of magicmountaintalks.org is set to this server's IP but Cloudron has no app configured for this domain." Update: After a few minutes of trying the install, it reverts back to the "The certificate is not trusted because it is self-signed" error. And if I refresh the certificates, I can access the installed app, but the Cloudron backend is treating the install as having failed, so I can't do any administrative tasks. That seems to me like more likely a Cloudron issue than Namecheap, since the site is accessible. Is there anything else you can recommend I try? Thank you.

It might need more memory for this

Done via support

You should see a summary in the email header just after the X-Spam-Status one, which explains how it came to this (ham) score. This should looks something like this, with different scores of course: X-Spam-Report: * -0.0 SPF_PASS SPF: sender matches SPF record * -0.0 SPF_HELO_PASS SPF: HELO matches SPF record * -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature * -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's * domain * 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily * valid * -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% * [score: 0.0000] * -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at https://www.dnswl.org/, no * trust * [87.253.236.95 listed in list.dnswl.org] * 0.0 HTML_MESSAGE BODY: HTML included in message

(moving to support since this is not surfer related) This was a translation bug and already fixed in the repo, but didn't make it into the 9.0.5 release just yet. https://git.cloudron.io/platform/box/-/commit/a78799973dc2c988edf4e68f73f962d305d252f8

Hello, in my case, the emails are going through google first. I have one email in google workspace for delivrability, my internal emails in cloudron. my MX record: MX mydomain.com smtp.google.com my spf record: v=spf1 include:_spf.google.com a:mail.mydomain.com ~all technically it works but I still get an error in the DNS Status: MX record Hostname: @ Record type: MX Expected value: 10 mail.mydomain.com Current value: 1 smtp.google.com what should i put in the SPF to make it work without error ? thanks in advance !

IMAP (are people still using POP?

Hello @3246 Yes, as stated in the information text in AdGuard: Allowed clients A list of CIDRs, IP addresses, or ClientIDs. If this list has entries, AdGuard Home will accept requests only from these clients. Emphasis on only.

Yes, that did it! Thanks Nebulon.

zfs is on the host. cloudron uses non-cow inside the vm.

Indeed the latest Immich version we have packaged is 2.1.0. The reason it isn't offered as an update is, because your Cloudron is not compatible with it yet. Newer Immich versions require the vectorchord Postgres extension, which is only part of Cloudron 9, which in turn is only available for users who want to early test it for the moment. But we will be start rolling it out to all users slowly this or next week.

It worked! Thanks.

We merged the change now for 9.0.4 so this is supported from next patch release on.

Thanks @zohup !

Hello @Dont-Worry If you have some custom DNS setup and Cloudron is struggling with it you can choose no-op as the DNS provider. This will skip all checks and verifications and just assumes, you know what you are doing.

@SansGuidon Yes, it's because of that syslog file. Thanks to your post, I was able to fix it. It seems like v8.3.2 (Ubuntu 24.04.3 LTS) is the only one with the error.

If the apps were still reachable, then possibly the healthcheck just got stuck, we have seen this in the past Cloudron 9 has some improvements in that area, so hopefully this will not be happening then.

@CaeruleusAqua which S3 provider are you using?