@webliska Is this resolved now?

Hello @CaeruleusAqua Please assist me in understanding this issue better. I want to figure out if is just a single filename or path and filename causing this issue. For this please go into the web terminal of your nextcloud and go into your /app/data/ folder. cd /app/data/ Please run the following command. It will find the deepest path and the longest filename. With these details I can further debug this issue. find . -type d | awk -F/ '{if(NF>max){max=NF; path=$0}} END{print "Max depth:", max-1, "Path:", path}'; \ find . -type f | awk -F/ '{if(length($NF)>max){max=length($NF); file=$0}} END{print "Longest filename length:", max, "File:", file}' Also can you please provide details about your backup provider?

@jdaviescoates Well, this is what I do for distribution list and it seems to work fine with Gmail addresses. But I have to say it isn't really a replacement for Cloudron lists. I find the current email situation really quite tricky on Cloudron, given: issues with delivery on forwards to some providers like Gmail issues with delivery when using an external SMTP (likely related to point 1) when trying to overcome bad IP rep (which with MS domains is a recurring issue with MS stupid IP range bans). For work I have to now consider moving all our mailboxes out of Cloudron...which I would really want to avoid because of: faff because I love Cloudron and wanna promote it (but my users are getting pissed because of email problems). @staff if you don;t really want to focus of changing the mailing function on Cloudron for now (and I totally respect and understand that this may not be your priority), can you advise on a working solution to use a address@domain.coop (with domain.coop being the Cloudron domain) which can be use as a list, where: some mailboxes on this domain being hosted on Cloudron (so the MX has to remain pointing to the Cloudron server) and while using an external SMTP server to ensure reliable email delivery

From a deeper investigation, it seems that is has to do with backups and not with Syncthing or Photos app. 4 times a day, Uptime Kuma is backed up, and each time the heartbeat table is dumped into syslog, growing the syslog by 1-2GBs each time. More details in https://forum.cloudron.io/post/112261

See: https://forum.cloudron.io/post/52997

Right, as you already figured out, you have to resize the fs manually. https://docs.cloudron.io/storage/#aws-ebs . Cloudron was more of an app deployment platform. Though after many years depending on which problems are often reported, we are putting in server management features (maybe we will add fs resize at some point).

You can check if the server itself is particularly low on memory by running free -m . Can you give nextcloud much more memory (in the Resources section) ? What is it at currently ?

Cloudron uses SRS for mail forwarding. Does SES support SRS? I think off late gmail has also changed behavior wrt SRS. I think @girish is aware of this already, there is no fix currently.

Back from vacation. I had to write a script to search the backups for gitlab backups that had postgresqldump files with actual data. Apparently the last "good" backup that had a good postgresqldump file was back in April (2025-04-24-090000-501/app_gitlab_v1.103.0.tar.gz.enc). I was finally able to get it working by reapeating the restore steps: Install the matching version of Gitlab to the backup version Then restore by importing the backup Not sure how exactly it got to this state, but it's finally back up and running!

Disk space. Ram. Probably the two* main components of a server that will make running Cloudron (or any software, really) a pleasure or a pain. But I think the easy answer isn't necessarily the best - buy a server with lots of disk space and lots of RAM - because use-case factors in alot. Perhaps some sort of pop-up questionnaire at some point in the purchase stream or set up process asking which apps are likely to be used would be one way to give a user a heads-up that their 4GB RAM, 60GB SSD server isn't going to cut it (or in this case an 8GB running Gitlab! Plus, it seems they are running additional software on that server, this "Mesa de Ayuda" which seems to be some kind of helpdesk software... Cloudron clearly advises running only Cloudron on a server and nothing else, so that was utilizing the same minimal 8GB of RAM). That said, I moved my Mastodon app off of my main server which has 64GB RAM and successfully run it on another server with just 4GB RAM plus 4GB swap, plus a Wordpress app, with stable results. I've also run a Presearch node on a 3.5GB RAM server along with Cloudron, and it all worked. *A third would be using Cloudflare. I know why ppl use it, I just don't know why ppl use it.

@ruben.villarreal I got your mail on support@ and I have reset the app installations on our side. Can you please confirm?

I was able to resolve this. I created a subaccount API key that I used for authentication before generating a secret key for the primary API key (by default Mailjet creates a key but not a secret for that key, which is a manual action). Now I just generated a secret key for the primary API key and used this instead of the subaccount key and it worked.

Here my 2cents; I personally host my Cloudron at Hetzner I enabled in front of Cloudron Cloudflare and Enable proxying for new DNS records (that is inside Cloudron at the domain level) Enable Firewall at Hetzner for my Server HTTPS only between my Cloudron and CloudFlare [image: 1756114585161-brave_9vbg9hsube.png] you can find the IP here Why ? So even if someone retrieve the IP (example via mail service) it cannot try to hack any webapps. Of course; I have others Rules at Hetzner Firewall Level; that basically replicate Cloudron's Firewall: SSH, Mails, STUN, TURN, ... After that; you mostly need to choose wisely the apps you deploy; trust the due diligence of these developers. Having a WAF; bring more complexity that would probably slow down the integration of new apps...

Thanks! Can't wait to see the light

@girish Is this use case covered in Cloudron 9?

@ImatBagjaGumilar can you check host -t NS <domain.com> 127.0.0.150 on your server? You can also try to run cloudron-support --troubleshoot to check if DNS is working on the server.

@nostrdev So glad you listened when we chatted about that too! Welcome.

Maybe your system/network from where you were trying to access your server had some long DNS cache pointing to the wrong IP. Glad it worked out in the end though.

Sweet, thanks. I added it to my start script.

@robi I only added the recommended commands: 0 13,23 * * * rm -rf /app/data/public/wp-content/cache/* > /dev/null 2>&1 0 13,23 * * * rm -rf /tmp/magick-* /tmp/imagick* > /dev/null 2>&1