Closing this since no more user details were given.

Closing this issue for now since no further details where provided.

Hello @JueBam Did you get this resolved or is further assistance required?

@girish @james Thanks!

@David-0 the Service Account Username should be set to cn=admin,ou=system,dc=cloudron and Service Account Password should be the Bind password. There are two separate LDAP servers - internal one and an external one. The external facing one can be authenticated against by the one and only "virtual admin user" i.e the admin CN above. Cloudron admin and Cloudron users don't have the permissions to search for other users in the external facing server.

Given the confidential nature of this, please write to us at support@cloudron.io if they need some information on our side.

Fixed here - https://git.cloudron.io/platform/box/-/commit/ac7001b96e176e540ede9bb81e3fcb17ae7f6416

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

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