Cloudron Forum

I confirm the problem with backup requiring SSHFS remount, on all my servers.

@joseph thanks!

No, no errors inside of docker image logs. /home/yellowtent/platformdata/logs/mail/*.log - from what I can see, that is the same logs I can see inside of Docker - so I would say there are no (error) logs - from all of the perspective, the server looks perfectly normal... except that it doesn't accept user's messages...

I would hope that you bring updated Dovecot to Cloudron 9 and it will self-resolve, but better will just do a restart for the time being...

From time to time, mail server got stuck - it doesn't accept messages to be delivered from the users.

Cloudron v8.3.2 and I would rather postpone update to v9, given the changes under the hood and amount of reported issues here.

My solution so far was manual mail server restart, as it's RAM consumption went up to ~2Gb (with not that many users and mail traffic flow).

Would it be safe to put docker restart mail into the cron at the night? Would it work on Cloudron 9?

Thanks.

I got data lost due to a weird find commands in the shell script; wonder why not to use rsync

In my case it was a Redis service not being active, thanks!

I believe that all related information is on the screenshot.
What I don't like about it - it's that there were no e-mail notification and no notification on that whatsoever!

on top of everything, Element X require livekit & jwt to work; if you are using OpenID connect - you have to use MAS, as Element X will not work otherwise (not now, nor ever).

Yeah, MAS jumped from all of the sudden from 0.2.something to 1.0 - very well... And that is all with 136 issues opened, including the issue when the user won't be created as it should.

I've ejected Synapse from Cloudron and run it independently - it is kind of working (if you don't mind get your hands dirty in the database), but if you don't need Element Calls - I can't see no real benefits.

Not sure if the question was anyhow directed on me, but I hope that rant might be of some use anyway

Apologies and correction.

Cloudron's functionality works just as intended. The problem is in docs in major sites and hence chatGPT as well (which I used to troubleshoot that).

All of the docs, except for NameCheap (thanks, guys!) says that the correct way to combine crt files - is just do cat .. > final.crt which lead to one problem:

-----END CERTIFICATE----------BEGIN CERTIFICATE-----

On the line 37, which, absolutely reasonably, brakes any SSL parser.

Correct way to join CRT files is:

cat STAR.*.crt > ssl-complete-bundle.crt && echo >> ssl-complete-bundle.crt && cat STAR.*.ca-bundle >> ssl-complete-bundle.crt

And you can check if it is valid than with

openssl x509 -noout -in ssl-complete-bundle.crt -checkhost test.`basename STAR.*.crt | sed -E 's/^STAR\.([^.]+(\.[^.]+)?)\.crt$/\1/'`

Guess, it might make sense to document it.

@joseph have the very same problem here.

openssl x509 -noout -in STAR.domain.com.crt -checkhost test.domain.com works on pure (aka 'leaf') CRT file, but fails on a bundle (cat STAR.*.crt STAR.*.ca-bundle > ssl-complete-bundle.crt) - with an intermediate certificate build-in.

And if I upload that pure / leaf certificate, then all apps that are not browsers fails with unable to verify the first certificate kind of error (that particular is from UpTime Kuma) - as an intermediate certificate is missing.

So, I would say that own wildcard certificate functionality is quite broken as of now on Cloudron.

Thanks. I'm fine with an occasional troubles that I will leave alone (after all it was working fine for a few years without any problems), but I was absolutely sure that all 'core' services are monitored thought.

Is there any chance to expect that anytime soon?

I can't think of a work-around solution for a turn-server external check...

Is there any way to have turn healtcheck implemented?

I realized my turn server has been hanging somehow weird with the following messages in the logs:

=> Generating turnserver.conf
=> Ensure permissions
=> Starting coturn
bind: Cannot assign requested address
Cannot bind local socket to addr: Invalid argument
bind: Cannot assign requested address
Cannot bind local socket to addr: Cannot assign requested address
bind: Cannot assign requested address
Cannot bind local socket to addr: Cannot assign requested address

+ I wasn't able to extract them from the web console - it returned zero (empty) log - that is the output that I've received via docker log command.

@ccfu I can not agree on deactivate - the purpose is very useful. I would rather have it working properly!

@nebulon I wish...

Guess I will end up removing it from the database, if it will be disturbing me too much

Regardless - thank you for the tool!!

Star based monitoring works!

I'm not using github stars, so I'm fine leaving with them - just one more question then: how do I remove a manually added entry?

@nebulon it's not that I'm using github automations, so rate limit is unlikely...

I understand the necessity for the logs though - that's why I asked how I can enable debug mode - to get them

Is there some way to enable debug mode to fetch the logs?

@nebulon looks like not...

@joseph apologies, I wish I had time for that

I can enable debug mode, but I can't see no configuration file - happy to follow some reasonable instructions to enable it (I can see debug on the code)

I've added https://github.com/element-hq/synapse manually for the monitoring at 1.120.2 and it picked up no new releases ever since (and the latest is v1.128!)

According to the logs, everything is synced Ok

Apr 26 22:35:48 releasebell/tasks run: start +1h
Apr 26 22:35:48 releasebell/tasks syncGithubStarredByUser: admin +4ms
Apr 26 22:35:49 releasebell/tasks syncGithubStarredByUser: found 1 starred repos +244ms
Apr 26 22:35:49 releasebell/tasks syncGithubStarredByUser: new projects: 0 outdated projects: 0 +4ms
Apr 26 22:35:49 releasebell/tasks syncReleasesByProject: [element-hq/synapse] type github_manual start sync releases, notifications are enabled. Last successful sync was at 2025-04-26T19:35:48.572Z +15ms
Apr 26 22:35:51 releasebell/tasks run: done. Next run in 3600s at Sat Apr 26 2025 21:35:51 GMT+0000 (Coordinated Universal Time) +6ms
Apr 26 22:35:51 releasebell/tasks syncReleasesByProject: [element-hq/synapse] found 0 new releases +2s
Apr 26 22:35:51 releasebell/tasks syncReleasesByProject: [element-hq/synapse] successfully synced +0ms

Could you please, help with that?

Could you please convert that thread into a request to remove 'Cloudron' from the mail templates as well as from translation files, please?