Cloudron Forum

@msbt

I haven’t fully tested an encrypted Matrix room yet, but I checked the Cloudron image and it does not look like mautrix[encryption] is missing. The package installs Hermes with the matrix extra, and in the pinned upstream version that resolves to mautrix[encryption]==0.21.0. I also checked the running container: mautrix 0.21.0 is installed, olm imports successfully, and the native _libolm.abi3.so from python-olm is present.

So if E2EE is failing, the next thing to check is probably Matrix E2EE configuration/key state rather than missing dependencies: MATRIX_E2EE_MODE / MATRIX_ENCRYPTION, stable MATRIX_DEVICE_ID, crypto store state, recovery key/cross-signing, and the gateway logs. I used to run hermes (locally, not on cloudron) with encrypted Matrix but ended up migrating to Telegram for features and ease of reliability. Encryption with Matrix for these things is a mess to set up.

@creative567145 @robi

Just pushed an app update, this should resolve, the kanban issues.

@creative567145 Sorry about that I was traveling, looking into this now.

@James Was this resolved or why is twenty not marked unstable anymore?

@TheMeerkat Nice! Nothing against nginx but have you considered caddy?

@mrchrisjones Yes, this looks like a CORS issue. Have you checked the upstream documentation? I'm a bit surprised you got Cloudflare R2 working. I thought I remember trying it back when I packaged this and there were compatibility issues.

Personally I'm using replication with B2, Hetzner and Scaleway (in this order).

@mrchrisjones That pretty much points to failing on email/OTP delivery, not on Backblaze B2 or browser encryption key generation.

172.18.0.1 looks to be Cloudron’s internal mail relay address. Ente/Museum is trying to send the signup OTP email through Cloudron’s mail addon at 172.18.0.1:2465, and that connection is timing out:

dial tcp 172.18.0.1:2465: connect: connection timed out

So /api/users/otp hangs because Museum cannot reach the SMTP relay.

You don’t need the cloudron command on your Mac. In the Cloudron web UI, open the Ente app, then use the app’s Terminal/Console and check:

env | grep CLOUDRON_MAIL

If the internal Cloudron SMTPS relay is unreachable, you can try overriding Museum’s SMTP config directly in:

/app/data/config/museum.override.yaml

I just pushed a package update which supports these changes. Please update to the latest version (0.6.100). The new image should include the ENTE_SMTP_* support.

Example for an external SMTP server using implicit TLS:

smtp:
  host: "smtp.example.com"
  port: "465"
  username: "smtp-user"
  password: "smtp-password"
  email: "ente@example.com"
  sender-name: "Ente"
  encryption: "tls"

Then restart the Ente app.

Important: Ente/Museum supports tls/ssl for implicit TLS, or no encryption. It does not support STARTTLS, so port 587 usually will not work unless the relay also accepts plain SMTP there. For most external relays, use port 465 with encryption: "tls".

The Cloudron app email UI may not show much here because apps normally talk to Cloudron’s internal mail relay, and Cloudron then relays externally. The log you shared shows the app cannot connect to that internal relay.

I’d first check the app logs while reproducing the signup failure, because the “generating encryption keys” message is likely just where the frontend fails after submitting the generated keys to the backend.

Can you run this while trying to create the account again?

cloudron logs --app <your-ente-app-domain> -f

Also please open the browser DevTools → Network tab and check which request fails after “generating encryption keys.” I’d expect a failed request to /api/users... or a mail/verification-related endpoint. The HTTP status and response body there would be very useful.

The most likely causes are:

1. Cloudron mail/sendmail is failing, so Ente can’t send the verification email.
2. The frontend is calling the wrong API origin.
3. S3 config is incomplete or invalid.

You can also check the startup config log with:

cloudron exec --app <your-ente-app-domain> -- tail -n 200 /run/ente/logs/startup.log

If the logs mention SMTP/mail errors, this is probably a Cloudron mail configuration issue rather than an encryption-key generation issue.

@mrchrisjones before I spin up a new test instance to try to reproduce this, could you please respond to these questions:

• did you set up s3 compatible storage?
• And if so, which one?
• Also, is there anything in the logs that pops up when you try to register?
• what browser are you using
• if you are on a Mac, do you have Lockdown Mode enabled?
• could you share here or in a dm the domain so I can test the login flow my end?

Nice! I'm using Nova which has this function. It's not open source though.

@James I think this is starting to be stable enough to be included in the list

The version of MySQL you are using (8.0.44-0ubuntu0.24.04.2) has reached its end of life (EOL). We strongly recommend that you upgrade to a current version, as continuing to use this version could expose you to security vulnerabilities and bugs that have been fixed in newer versions of MySQL.

@Joseph No, the problem here is that to receive mail, I need to be able to route Port 25 to the app. But I think it's always reserved by the internal mail server?

@sponch I don't think so. Looks like cloudron is blocking Port 25 which is needed for receiving mail. Running into the same issues with my attempt at packaging stalwart

@josephcosta said:

I had to open ports in /home/yellowtent/platformdata/firewall/ports.json and restart the firewall to have access to smtp, imaps, ...

OK thank you I'll check out the port issue

Updated and modified for community app: https://git.due.ren/andreas/mautrix-whatsapp-cloudron/-/raw/main/CloudronVersions.json?ref_type=heads

@josephcosta Please update to 0.16.26, should work now.

@josephcosta Hmm. I'll check it out later today or tomorrow. Thanks for testing!

@josephcosta Yes, openID isn't working yet. working on that. But the package should auto create admin credentials you can extract from the env. At least it does for me. Doesn't it have a STALWART_RECOVERY_ADMIN=admin:xxxxxxxxxxxxxxxx entry already?

I'm experimenting with packaging this. Please help me test it: https://git.due.ren/andreas/stalwart-cloudron/-/raw/main/CloudronVersions.json?ref_type=heads