@jdaviescoates said in Cloudron seems to have changed to set-up ?all SPF records instead of ~all - why?: whereas only my newer ones have ?all I checked some domains on my Cloudron and noticed one has -all where all others have ~all. Then I realised that one was a recently transferred domain that was already 'working' and obviously the previous hoster had it like this, Cloudron didn't touch it when "importing" it.

The posted error logs do not seem to be related as far as I can tell. But anyways if some food solves it, even better, hopefully also stays that way

Not sure what you mean with "redirect" here, but the code checks if the DNS A (and AAAA if you use ipv6 also) are in sync at all configured nameservers for this domain. So basically you just have to make sure that you have setup A records for my.heavendigital.com.br pointing to your server IP. Then after some time, depending on your DNS provider, this should succeed.

@girish Much appreciated

I never thought of this use-case. Using sftp inside a Cloudron app to move data away. Unique, I must admit. Testing inside a LAMP app to the new unstable SFTPgo app. mkdir -p /tmp/testing; cd /tmp/testing ssh-keygen -t ed25519 -f /tmp/testing/this -q -N "" # put the publickey into my profile in sftpgo.cloudron.dev sftp -i this -P 2022 elias.hackradt@sftpgo.cloudron.dev:/ sftp> put /app/data/tcl.zip [image: 1740783672764-e26df4a0-195d-43cb-9f69-46f3fa8516d4-image-resized.png] Seems to be working Sorry, where was I? Ah yes, your issue The error message OpenSSL version mismatch. Built against 30000020, you have 30100070 indicates that the version of OpenSSL used to build the sftp or related binary (such as ssh, libssh, openssh) is different from the version of OpenSSL currently installed on your system. Specifically: Built against 30000020: This means the binary was compiled against OpenSSL version 3.0.2 (I think don't pinpoint me on the semver). You have 30100070: This means your system currently has OpenSSL version 3.1.7 (same again, don't pinpoint me on the semver, not used to the 30100070 format). This mismatch can cause compatibility issues because the binary expects a specific version of OpenSSL but finds a different one at runtime. Running this in my LAMP App: openssl version OpenSSL 3.0.2 15 Mar 2022 (Library: OpenSSL 3.0.2 15 Mar 2022) and ssh -V OpenSSH_8.9p1 Ubuntu-3ubuntu0.4, OpenSSL 3.0.2 15 Mar 2022 Reveals, there is no issue inside the LAMP app. @chetbaker Could you maybe run openssl version, ssh -V and ldd $(which sftp) in your app with the id 23f10ac0-d9a3-4a1d-8265378464d7b1caasdasdas0 and post that output? Also can you tell us what app 23f10ac0-d9a3-4a1d-8265378464d7b1caasdasdas0 is? Since most apps are inherited from the Cloudron base image, that should be the same everywhere. So this error might be rather unique to your app. Could it be that your app is a custom packaged app? Since you are comfortable using the cloudron-cli, is this by chance an issue from your custom packaged app?

You can also follow this great guide and set up an automated blocklist update: https://forum.cloudron.io/topic/3795/firewall-spamassassin-automatic-list-update/41?_=1740739173375 Might mitigate some (few) of these annoying spam attacks.

Somehow, this issue resolved itself overnight. I mean yea nice, it solved itself, but I wanted to understand whhhyyyyyy. Anyway. #SOLVED

For the future generations: better do ln -s /usr/bin/resolvectl /usr/local/bin/resolvconf to avoid messing with system's and cloudron settings Or use netplan's WireGuard capabilities.

@NCKNE added in https://git.cloudron.io/platform/box/-/commit/f78f6634fa29e0ca638f482c8e4f941c885e6301 . It hasn't run through our CI yet, but maybe that works for you already . You can patch server at /home/yellowtent/box/src/externalldap.js .

Thank you for your answer. So I have to figure out how to redirect port 443. As it stands, I can't, but I'll try to find a way, thank you and good luck!

@im-fabian can you reach out at support@cloudron.io ? I think we have debug further with access to the server. thanks!

there are also some posts from @d19dotca a while back about fine tuning spam rules

@girish said in Ubuntu sub-version not updated?: but be careful of those kernel updates thanks for explaining, I'm on NetCup RS and during the upgrade procedure from 20.04 to 22.04 I remember seeing kernel updates going by and all went fine. I'll think twice before updating especially if it's not really needed.

@RedzzDragon it looks like mongodb is not running . If you click on the logs button, maybe it gives a hint as to why it's not running . There is a very small chance that you are using a server/CPU that does not support mongodb . Modern mongodb requires CPU to have AVX support. If this is the case, the logs will tell you as much. (And to host WP, you don't need mongodb, it's fine if it's not running)

@DualOSWinWiz do you think "Encrypt DNS" in your router mean DNSSEC ? If that is the case, an idea is to just disable DNSSEC in unbound instead of for your domain . https://docs.cloudron.io/networking/#unbound .

fyi: As soon as I have moved platformdata back to the “original” storage, everything works as expected the error disappeared. I also had to move the appsdata & boxdata back to get a fully functional Cloudron instance again.

Do you have the "Enable proxying" flag enabled in the Domains -> Cloudflare configuration ? This whole discussion only applies if you have that flag changed. Cloudron does not touch the proxying flag if that is disabled. When enabled, it will set the proxying flag when adding new cloudflare DNS records. This is set only when adding and in all other situations that flag is left untouched . It does this for both ipv4 and ipv6 records.

@titi49600 thanks for the update. Did you have to run any command to adjust the mtu? If you post it here, it will help future readers.

No need to delete, just mark as solved . Will help future users who might hit the same (even if incorrect or unreproducible) issue.

@girish When we initially changed the default data directory and restarted the entire Cloudron server, something went wrong. As a hotfix, we applied some basic permissions, which probably broke PostgreSQL. However, we don’t know which permissions were wrong, as I didn’t log them at the time. This morning, we tried changing the default data directory again, but instead of restarting the whole Cloudron, we restarted all services individually, and this time we didn’t get any errors.