Can you run that via SSH and see what that reports? root@mail:/# df -B1 --output=source,fstype,size,used,avail,pcent,target / Filesystem Type 1B-blocks Used Avail Use% Mounted on /dev/mapper/ubuntu--vg-ubuntu--lv ext4 207953018880 18610241536 180670283776 10% /

@trend-1 said in not all email received: When my server checks with Spamhaus on the incoming message (by making a request?) Spamhaus doesn't like it when this is done via a public/open resolver. Resulting in my server bouncing the incoming message. Cloudron uses an internal resolver (unbound) for exactly this. Have you configured a custom DNS or customized unbound config by any chance? You can verify like this on the server. If you use the system resolver: root@my:/etc/unbound/unbound.conf.d# host 76.67.227.165.zen.spamhaus.org 76.67.227.165.zen.spamhaus.org has address 127.255.255.254 127.255.255.254 is error for NXDOMAIN (from the open resolver that DO uses by default). Now, use unbound: root@my:/etc/unbound/unbound.conf.d# host 76.67.227.165.zen.spamhaus.org 127.0.0.150 Using domain server: Name: 127.0.0.150 Address: 127.0.0.150#53 Aliases: 76.67.227.165.zen.spamhaus.org has address 127.0.0.11 127.0.0.11 means PBL (ISP policy blocks) , so we got a good response.

I have not noticed this issue yet after upgrading to 9.x.

I updated the post already and added a section at top: For the sake of completeness as it may happen to others: We finally identified an issue in the network configuration, that isolated the internal VM network from the public network. Disabling the isolation solved the issue at hand. We are now figuring out another way to isolate the VM itself. you can decide if you wanna decline/resolve it or just publish and directly close it

Hello @SolarSimon Yes you can still use the described method with editing the /app/data/htaccess file. Example excerpt from the /app/data/htaccess file limiting the upload to 1 KB: <IfModule mod_php.c> php_value default_charset 'UTF-8' php_value output_buffering 0 php_value upload_max_filesize 1K <IfModule mod_env.c> SetEnv htaccessWorking true </IfModule> </IfModule> This can then also be checked in https://$YOUR-DOMAIN/settings/admin/serverinfo: [image: 1763578747779-78631002-eb0e-4998-9cdd-560c42ce0d3f-image-resized.png]

@girish Bumped the memory from the default (?) 1GB to 4GB. Right now, it seems like an app backup worked correctly. My Cloudron has quite a lot of stuff, so an global backup takes longer. I'll report back.

@girish thank you, Girish. I already ensured that my server is running security updates using those commands.

Marking as solved due to inactivity.

@derin can you open a separate topic with that request for nextcloud? can you also elaborate on your use case for this (does nextcloud the app support aliases?) ?

@girish same issue here, totally unexpected and unannounced 1of 3 Cloudrons updated itself to 9.0.11 last night and the first backup at 8:00h failed with same errors. Opening the config and safe it (and remount) solved it. Compared to previous backups it's really slow, before 2 minutes for complete backup, now at 30% after 30 minutes. Hope this gets better 🤨

@luckow Maybe some sort of shared hosting? Should be able to support lots of wordpress instances, LAMP stacks and Surfer apps.

Perfect. Everything works as intended. Thank you, @girish, and have a great beginning of your week

This has gone back to normal for a few days in a row, indicating the upgrade didn't produce an issue, but probably the hardware infrastructure at Netcup.

Hello @maellerollet and welcome to the Cloudron forum It sounds like you are running into this issue: https://docs.cloudron.io/troubleshooting/#domain-issues-expiry Please check this documentation and see if this helps to resolve your issue.

Fixed in https://git.cloudron.io/platform/box/-/commit/3e6f3bd807a63e38711ace7e83eb5e2b722299b5 . Thanks for reporting!

Okay, with 9.0.10, backup was able to be completed.

So turns out that potentially the issue is disk space. we ran the process again without changing anything - same result we clean up and enable at least 40 GB of space and relaunched the update process = successful update suggestions: better pre-update space check and verbose messaging about needed space for update

I came here to learn about Hetzner having periodic issues. Thanks @girish ! I'm currently facing a similar issue on a Cloudron 9.x instance and was looking for old threads mentioning the exact same error. Here am I. Damn Hetzner then @girish is there a support ticket open with Hetnzer or anything that we can do?

Hello @jkammerer I understand that backward compatibility is desired. In this specific case it was actually a bug in the previous version that the field could have been left empty in the API call and it worked. People still use pop3 and we have to accommodate for this.