Cloudron Forum

Okay, I'm at a loss. I tried sending a message today, the same two addresses gave the same DMARC errors. Email > Status is all green checks, https://mail-tester.com gave me 10/10 and https://easydmarc.com seems to indicate that my DMARC is valid.

I'm not sure what to do next. Is there anything else I can do to troubleshoot?

@joseph said:

@beardmancer you can also check via https://mail-tester.com/

I actually did test it in my original message, and the DKIM and DMARC tests both passed.

@ccfu said:

You need to set the reverse IP (PTR) in your VPS provider's network settings and make sure the IPv6 resolves to the mailserver address.

Thanks! It turns out that an IPv6 address is included with my VPS, but it wasn't assigned. Hosting support provided me an address, and now that it's added to Cloudron and a PTR record was set, I have all green checks under email status.

Hopefully this will resolve the DMARC rejections.

Thanks to all for your help.

@james Also, I just used ip -f inet6 -br addr to check for IPv6 addresses and it provided eth0 and another entry starting with br- that has a longer name. I tried setting the IPv6 Setting to Network Interface > eth0, which does successfully detect the address. However, that leaves an error for the PTR6 record under Email status:

@james Thanks for showing me how to us mxtoolbox! I see that I needed to us :cloudron instead of the default :email in my search string.

Under Cloudron > Network, I tried changing IPv6 from "Disabled" to "Public IP" to match the IPv4 setting. However, it doesn't detect an address (see screenshot) and the IPv6 statuses under Email are now red alerts.

I've raised a ticket with my VPS provider (CloudFanatic) to see what they have to say, but is there anything else I can try in the mean time?

I have one contact with an Outlook address that has been undeliverable for awhile, which I just attributed to Microsoft being picky. Recently, however, two other contacts with Yahoo addresses have been undeliverable for me as well.

Outlook rejection:

Access denied, sending domain [IANTOMPKINS.COM] does not pass DMARC verification and has a DMARC policy of reject.

Yahoo rejection:

This mail has been blocked because it failed authentication checks against the sending domains DMARC policy.

According to my Cloudron dashboard everything is good, although IPV6 checks are not green (is that an issue?):

The site mail-tester.com didn't find any issues. However, the site mxtoolbox.com says my DKIM record is not published:

Results from cloudron-support --troubleshoot:

[OK] Root disk usage is OK (41%)
[OK] Memory usage 1s OK (55%)
[OK] Clock is NTP-synchronized
[OK] node version is connect
[OK] IPv6 is enabled in kernel. No public IPv6 address
[OK] docker is running
[OK] docker version is connect
[OK] MySQL is running
[OK] netplan is good
[OK] DNS is resolving via systemd-resolved
[OK] is running
[OK] IPV4 HTTPS to api. cloudron.io/api/v1/helper/public_ip
[SKIP] IPV6 HTTPS api.cloudron.1o/api/v1/helper/public_ip - no public IPv6
[OK] auth.docker.io/token
[SKIP] auth.docker.io/token - no public IPv6 address
[OK] IPV4 HTTPS acme-vo2.api.letsencrypt.org
[SKIP] IPv6 HTTPS to acme-v02.api.letsencrypt.org - no public IPv6 address
[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 'postgresal' is running and healthy
[WARN] Service 'mongodb' is not running (may be lazy-stopped)
[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.iantompkins.com)
[SKIP] Dashboard IPv6 reachability - no public IPv6 address
[OK] Domain iantompkins.com is valid and has not expired address
======== Summary ========
PASS: 26
WARN: 1
FAIL: 0
SKIP: 4
Warnings:
- Service 'mongodb' is not running (may be lazy-stopped)

I'm very much a novice on this and I'm not sure where to look next. What can I do to troubleshoot? I am not using a relay and would prefer not to if possible.

@necrevistonnezr @joseph Ah, got it, thank you for clarifying.

For what it's worth, I was following the upgrade guide for Ubuntu 22.04 (https://docs.cloudron.io/guides/upgrade-ubuntu-22/) which indicates that it should be active. Probably a decent number of people will follow the same trail I did: Cloudron updates to 9.x --> Notification about 20.04 EOL --> Follow 22.04 upgrade guide. If none of these folks need to worry about the collectd step, it might be worth adding a note in the 22.04 guide. The 24.04 guide also mentions collectd.

While it's fresh in my mind and I'm looking at it, is there any reason I should or shouldn't go ahead and upgrade to 24.04?

Description

My Cloudron server recently updated to 9.0.13, so I heeded the expected Ubuntu 22.04 notice and decided to upgrade. I've been successful with every step but one.

When I run the command systemctl status collectd, it shows that collectd is "inactive (dead)". This persists after a system reboot.

Everything is working as far as I can tell. Should I ignore this, or should I do something to make collectd active? Based on cloudron-support --troubleshoot results below, maybe it's an issue with IPv6? That is currently over my head.

Troubleshooting Already Performed

I've restarted the server a few times with no change in behavior. I'm not sure what else to do.

System Details

Cloudron Version

{
  "version": "9.0.13"
}

Ubuntu Version

No LSB modules are available.
Distributor ID: Ubuntu
Description:    Ubuntu 22.04.5 LTS
Release:        22.04
Codename:      jammy

Cloudron installation method

Manual with ./cloudron-setup

Output of cloudron-support --troubleshoot

Vendor: Red Hat Product: KW
Linux: 5.15.0-161-generic
Ubuntu: Jemmy 22.04
Processor' Intel(R) Xeon(R) CPU E5-2695 v4 H 2.10GHz x 4
RAM: 4005200KB
Disk: /dev/vda2 59G
[OK] node version is correct
[FAIL] Server has an IPv6 address but api.cloudron.io is unreachable via IPv6 (ping6 -q -c 1 api.cloudron.io) Instead of disabling IPv6 globally, you can disable it at an interface level. sysctl -w net.ipv6.conf.ethO.disable_ipv6=1
For the above configuration to persist across reboots, you have to add below to /etc/syscti.conf net.ipv6.conf.ethO.disable_ipv6=1 

@james said in Restore one app's backup to another existing app?:

Yes, you first have to either move the destination to a different location e.g. from www.DOMAIN.TLD to www-old.DOMAIN.TLD (save route) or just deleted the destination.

Thanks for that, I didn't consider just changing the subdomain of the main site to move it. I suspect that might leave me with Wordpress database errors, but I guess that wouldn't matter so much.

Ultimately I cloned Main to a new subdomain, and since that clone worked without any issues, I went ahead and deleted the original and cloned staging to the bare domain. I was hoping to minimize downtime by overwriting directly to Main, but honestly the deletion and cloning was so fast it wasn't an issue.

@robi said in Restore one app's backup to another existing app?:

Another option would be to export the WP site using a plugin, and import it into a fresh WP install w/o all the dev/staging cruft (unless you need it for some reason).

You can search the forum for "how to move wordpress" for more information.

I've certainly done it that way before, but I was hoping to avoid extra steps this time and let Cloudron do it. I'm happy to not have to find and replace "staging.domain.tld" with a plugin like I've done on past migrations.

I've used All-in-one WP Migration previously, and it was mostly fine other than the above issue with the database. It was fairly complete and I think any of my staging "cruft" would have been exported and imported. I'm curious to know what plugin you prefer? I'll put it on my list for next time.

I did search the forum of course, but most results are about migrating to a Cloudron app from elsewhere.

I have two Wordpress (developer) apps running on my Cloudron, my main site and a staging site. The staging site is ready and I would like to clone it directly to the existing main site, overwriting everything at the destination. I have a backup of the destination and am not concerned about losing it all. Also, the site is fairly simple.

It seems that I can't do this, I get an error that the destination is in use. This happens even when the destination app is stopped. Do I have to delete the destination app on the bare domain before I can clone the staging site to the bare domain?

Maybe I'm going about this wrong. Is there a better way?

@Beardmancer said in Failed backups and email config issue since 8.0.3 upgrade:

I decided to go ahead and try adding this to /etc/systemd/resolved.conf since it's easy enough to comment out.

DNS=8.8.8.8 1.1.1.1

After doing that and restarting the service with systemctl restart systemd-resolved, things seem to be working correctly. The file /etc/resolv.conf lists nameservers now and a manually-initiated backup just completed successfully. Thanks for the hlep @nebulon !

In the future, is there anything I should look out for to avoid this? I don't know what caused it. Maybe it was the 8.0.3 upgrade, or maybe it was an Ubuntu update? I think I rebooted Cloudron for the latter recently. If there's a configuration I might have setup wrong, I'd love to correct it.

@nebulon The file /etc/resolv.conf contains the following:

nameserver 127.0.0.53
options edns0 trust-ad

I also ran systemctl status systemd-resolved and it said it was running. When I checked /etc/systemd/resolved.conf the DNS line was empty and commented out. I don't really know how to read the output of resolvectl, but it produced 177 lines and none of them looked like nameservers to me.

I don't know how to determine my "own network's nameservers" as the other post suggests. So, should I add the following to my /etc/systemd/resolved.conf?

DNS=8.8.8.8 1.1.1.1

@nebulon said in Failed backups and email config issue since 8.0.3 upgrade:

Possibly a DNS issue. Can you run cloudron-support --troubleshoot via SSH?

Yep, looks like DNS is the only thing that failed:

[FAIL]  DNS is not resolving
Host cloudron.io not found: 2(SERVFAIL)

I don't have a clue why that would be, I have not changed anything lately. Should I try the Sync DNS button under Domains & Certs? My domains are all on Porkbun and are setup the automatic way with an API key in Cloudron if that is relevant.

Hello!

My Cloudron auto updated to 8.0.3 a few weeks ago, and all my backups started failing shortly after. I also started getting a notice that email is not configured properly, though sending and receiving continues to work fine. The specific notifications and a screenshot are below.

This may or may not be related to the update, there were a few successful backups on version 8.0.3 before they started to fail. Is it possible my host changed some configuration? I did not find anything specific to these errors when searching the forum, but I did see some similar issues that were related to IPV4 vs. IPV6. Enabling IPV6 in my Network settings did not help, but I may not have done it right.

I'm very much a novice, just running this to self-host a few small websites and apps. Not sure where to go from here. Is there anything I can try to diagnose or correct?

Backup failed: Upload error: Inaccessible host: <my backblaze b2 bucket>.s3.us-east-005.backblazeb2.com' at portundefined'. This service may not be available in the `us-east-1' region.. Logs are available here.

Email is not configured properly 9:08 PM

<my primary domain>

    PTR DNS record (PTR) did not match.
        Hostname: null
        Expected: my.<my primary domain>
        Actual: null
    Relay error: Connect to port25check.cloudron.io failed: getaddrinfo EAI_AGAIN port25check.cloudron.io. Check if port 25 (outbound) is blocked
    This server's IP null is blocked in the following servers -

Email Status is checked every 30 minutes. See the troubleshooting docs for more information.