Cloudron Forum

@luckow Tried update with version 3.0.0 and did not work, but now updating to v3.0.1 it worked properly. All seems to be running ok.

The code in question uses df -B1 --output=source,fstype,size,used,avail,pcent,target / to check the rootfs at /. Can you run that via SSH and see what that reports?

@Beardmann such a request needs to be upstream to Roundcube itself - looks like this is the best place for them https://www.roundcubeforum.net/index.php?board=16.0 (why they don't just use Gitsomething I don't know )

@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]

That would indeed explain it, but - and that is probably a question to the Cloudron team - shouldn't Cloudron prevent exactly that?

said in GPX file upload error: @nebulon said in GPX file upload error: Now testing ... Test succeeded after 2 tries: in the watched folder you have to create a folder with the email address of the user, in that folder you can put ie. the gpx files. Exact on every whole hour they get fetched and processed. Now after 5 minutes they are still not removed, can’t find info on that.

I also use seafile and would love to have it on my cloudron