Cloudron Forum

@girish Will do. It's actually not the first time I've run into the problem and a re-fresh of the API credentials solved the problem, although this is the first time I specifically observed that it was a 500 error vs. a 401.

FWIW, I just installed all of this and tested it. Works great, instructions are clear. The yaml edits referenced by @msbt were quite helpful on the external-registration side.

Look forward to the eventual Jitsi package.

This isn't so much a problem I need help with, but rather sharing something I didn't immediately find in a site search. I fixed my own problem, so now it's a suggestion.

I experienced a certificate error for the domain upon which my Cloudron control panel happily resides. No amount of irritable gesticulating could make it work -- I'd try to force certificate renewals only to see the control panel go offline and prove unable to connect. Logs weren't especially useful, either. I had to reboot the server from the shell to make things work again.

When I tried updating one specific app and it gave me a 500 error on the Digital Ocean side, it occurred to me that the API credentials must have expired. Which, as it happens, proved to be the case. I generated a new set, added it, and viola! life is good.

I wonder if we can have a better way of uncovering expired DNS API connections? Perhaps a check before a certificate upgrade that flags a plain-English error?

No. I saw that helpful button and used it successfully to access the Mongo shell. The problem is that within the shell, I get "error: not authorized" messages for pretty much everything except switching DBs and listing containers.

I'm trying to edit a specific user but no matter what I do, including trying to grant read or executeFunctions privileges to the user ID in

env | grep MONGO

I get the same response:

Error: not authorized on XXX to execute command ...

Is there a magic trick for actually querying the Rocket.Chat database from the Terminal that's not obvious to me?

A bit of thread necro, but I had the same problem. It appears that NodeBB is correctly configured, BUT in the Cloudron portal, by default, the "custom mailbox name" flag in the advanced app configuration settings is set to off. Thus, the email credentials correctly entered into NodeBB led to an account that, by default, was deactivated in Cloudron's mail server.

For others who stumble here:

1. From your Cloudron control panel, click the Configure tool (the pencil overlay over the app icon).
2. In the Advanced tab of the pop-up, ensure that Custom Mailbox Name is checked, and that the name matches the name as configured in NodeBB's email control panel. By default, it's nodebb.app@.

Problem solved, although whether it immediately resolved or whether it fixed when I rebooted Cloudron to install security updates about three seconds later, well ....