Cloudron Forum

I'm really interested in switching over from Synapse-only to this.

As of now just so I'm sure, this is still waiting on some work from @girish, @james and the cloudron team in order for instances that are on 'matrix.mydomain.com' (for example) to work correctly, right?

Yeah my diagnostic skills for things like this need improving

So running netstat -tulpen | grep -i 19132 from inside the docker image does return the expected results. netstat is not installed on Ubuntu by default so I couldn't try that on the host cloudron server (I'm wary of touching anything package-wise on the machine running cloudron because I don't want to mess up any dependencies).

nmap -sU -p 19132 my.cloudron.dev was interesting because it pretty much returns open|filtered on any port when using the lan address of the server but then returns correct open/closed when using the internet facing address of the server (which makes sense because it's going thru my router that way and that's where the port forwarding is).

Anyway, turns out that in my case it was a combination of IPv6 issues (tried to forward 19133 too but never got it working when the game was connecting via IPv6. Ipv4 works fine so I made my DNS entry by IPv4 only) and the enable-lan-visibility settings.

That second part looks like it needs to be enabled even if you're connecting to the server from outside the lan. Maybe I'm mis-understanding the purpose of that setting but basically with it off I couldn't get any connections going.

I'm thinking the app never actually start correctly or shuts down which would explain my issue.

Let me try the netstat command from inside the app and see what that does for me. I'll post the app's log here if I can't find anything wrong.

I'm trying to install a bedrock server but I can't seem to connect to it.

When I port scan the cloudron server, I can see that 19132 is not opened.

What can I do to try and debug this?

This setup will not work for apps on Cloudron that require additional ports to be forwarded, beyond just port 443.

Thank you @hareen for the detailed guide. I’m interested in setting this up using a second machine on my setup at home.

Does this mean an app like gitea which has an ssh port too will not be able to use Anubis for its 443 port and use a straight port forwarding for the ssh port? (I’m a noob with this so this might be a stupid question).

What I had in mind was to have my router port forward 443 to the Anubis server but then keep all the other ports forwarded to my Cloudron server as they are now.

I still think that my well-known file is not being read correctly. So the federation tester reverts back to testing the default federation port, which is 8448 and fails unless I forward it myself to the cloudron's 443 port.

This hypothesis does explain the behavior but what I'm not getting is why the well-known setup on my end would be incorrect. It looks ok as far as I can tell.

Sorry I missed some of your questions above. Yes, I am running synapse on my cloudron server.

@joseph said in Federation testing fails unless port 8448 is forwarded to 443:

Can you check what is listening on your server with sudo lsof -i :8448 ?

When I run this on the cloudron server (I'm assuming that what you meant) I get no output. That would make sense since the Synapse app doesn't listen on 8448.

My only hypothesis right now is that my setup for the well know file is somehow wrong. The error above also mentions No SRV records found. Is that talking about not finding the well-known info at the root?

I think I'm not explaining myself correctly

@joseph said in Federation testing fails unless port 8448 is forwarded to 443:

Port forwarding in your firewall makes no difference.

It does because I'm forwarding 8448 on my firewall to 443 on the cloudron server. I mentioned that above I think

Maybe ignore my previous comment too. AFAICT, your domain works fine and does not contact 8443.

The well-known part is set up correctly. You can try curl -L https://malenfant.net/.well-known/matrix/server to make sure.

As I mentioned above I am checking malenfant.net with the checker and not matrix.malenfant.net.

The reason my domain currently works with the checker is because I have port 8448 forwarded to 443 on my firewall in front of the server.

If I remove the forwarding and run the checker I get the error I mentioned in my first post:

Connection Errors
Get "https://xx.xx.xx.xx:8448/_matrix/key/v2/server": context deadline exceeded (Client.Timeout exceeded while awaiting headers)
Get "https://[xxx:xxx:xxx:xxx:xxx:xxx]:8448/_matrix/key/v2/server": context deadline exceeded (Client.Timeout exceeded while awaiting headers)

which would seem to indicate that the tester does NOT read the well-known file and indeed tries to check 8448.

I just tried right now with the forwarding disabled:

Thanks. That was mostly my understanding of how it 'should' work too.

@andreasdueren said in Federation testing fails unless port 8448 is forwarded to 443:

If you check federation for your base domain, you can see that it actually checks port 443 not 8448.

This is where the results in my original post surprised me. If you look at the error log I got from the federation tester it looks like is does test for port 8448 and ignores the setting I have in the .well-known file which should point it to port 443.

Once I forward 8448 to 443 the federation testers returns no errors.

So my question was, does the tester ignore the well known file or did I set something up incorrectly when I seup the app? Basically do other people get the same error with the tester when using a fresh install of the app with the .well-known file correctly setup.

@andreasdueren said in Federation testing fails unless port 8448 is forwarded to 443:

But https://federationtester.matrix.org/#malenfant.net correctly recognizes federation. Is this with your fix?

Yeah. If I don't forward 8448 then the tester returns the error I put in the original post.

Clouflare proxying is off for both matrix.malenfant.net and malenfant.net in my case.

Does anyone know if the federation tester actually reads the well-known server info as part of the test?

@andreasdueren said in Federation testing fails unless port 8448 is forwarded to 443:

@DidierMalenfant Do you have any app installed on the base domain?

@james said in Federation testing fails unless port 8448 is forwarded to 443:

Also, you have to use the base domain in the federation tester not e.g. synapse.cloudron.club.

Yes to both of those (I can curl https://malenfant.net/.well-known/matrix/server too and the returned json looks correct).

It could very well be that the tester doesn't read the well-known server info but if that's the case then, again, maybe that should be added to the docs so others can know they might see this error.

Or maybe I've done something wrong in setting this up...

I have the synapse app installed and I ended up having to port forward port 8448 to port 443 on my firewall in order to get federation testing to pass.

Otherwise this error would be returned:

Connection Errors
Get "https://xx.xx.xx.xx:8448/_matrix/key/v2/server": context deadline exceeded (Client.Timeout exceeded while awaiting headers)Get "https://[2600:8802:3000:1492:56b2:3ff:fe09:1c9]:8448/_matrix/key/v2/server": context deadline exceeded (Client.Timeout exceeded while awaiting headers)

I have the well known location setup up on the bare domain with port 443 but somehow this is not enough to get the server to pass the federation test.

I don't see any mention of the port forwarding requirement in the docs, although it does mention that the app uses 443 for both user and server communications.

Did I do something wrong in my setup or should this be maybe added to the documentation somewhere?

Thanks! as it turns out, in my case it was the cloudflare proxy causing issues. I had disabled it for IPv4 but forgot to do the same for IPv6 so the results/errors were confusing because of this.

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

I migrated my Mastodon instance from masto.host to a cloudron app and I've noticed that it doesn't seem to be federating correctly.

For example I can only see posts from @macrumors@mastodon.socialon my instance until July 11th and then nothing. If I go directly on mastodon.social all their more recent posts are all there there. I don't see any user facing errors on the website or in the admin section (federation for mastodon.social says "No failures on record").

I added these to my env.production file:

RAILS_LOG_LEVEL=debug
LOG_LEVEL=silly

and rebooted the container. Once the site was back up I searched for @macrumors@mastodon.social in the search bar and grabbed the log after that.

I see this:

2025-08-09T20:45:27Z 2025/08/09 20:45:27 [error] 49#49: *5 connect() failed (111: Connection refused) while connecting to upstream, client: 172.18.0.1, server: , request: "GET /api/v1/announcements HTTP/1.1", upstream: "http://127.0.0.1:3000/api/v1/announcements", host: "malenfant.net", referrer: "https://malenfant.net/deck/search?q=%40macrumors%40mastodon.social"

172.18.0.x seems to definitely be the sub-net that the docker container is on but I don't understand what it's trying to do here.

As a bonus, I'm pretty sure that my posts are not being seen by all my followers either but I only have anecdotal evidence of this at this point.

Anyone with some Masto admin experience able to guide me in the correct direction for diagnosing/fixing this? I'm willing to learn but I don't know where to start...

I was testing cloudron migration for my test/dev server and everything worked fine apart from the file ownership inside /app/data weren't correct after the migration. I had to manually do a chown cloudron:cloudron to fix it.

Since the only app on that server was one of my own, I was wondering if I did anything wrong in the app itself that would cause this to happen.

Should all file ownership be handled by the migration or is it left to the app itself to fix this during its init?

Latest update works! Thanks for the fixes.

I'm going to play with it for a bit but I'll leave a few more things I noticed in case you want to address those too:

• If you do git add --chmod=+x cld.sh locally you can then commit the executable flag with your repo and skip a step in the README.
• The cld.sh script should probably have a set -e line at the top (after the #!/bin/bash) to make sure the script stop executing if something goes wrong with one of the commands.
• Currently everything in /app/data is owned by root and I believe agate itself is launched as a root owned app. It's probably safer to make all the files in in /app/data owned by cloudron:cloudron and launch programs with /usr/local/bin/gosu cloudron:cloudron to run as the cloudron user. I might be off here but that was my understanding of recommended behavior looking at the documentation. Someone else can deny or confirm.

Great job on the app!

Testing it now...

• You need a chmod +x cld.sh in the repo.
• The installation never completes for me. It gets stuck at Waiting for propagation of newsite.malenfant.dev even though the DNS is updated. The app doesn't seem to launch.

Could be something with the DNS on cloudflare... Log shows:

Jul 16 17:28:25 box:dns/waitfordns resolveIp: Checking A for newsite.malenfant.dev at 162.159.38.40
Jul 16 17:28:25 box:dns/waitfordns resolveIp: No A. Checking CNAME for newsite.malenfant.dev at 162.159.38.40
Jul 16 17:28:25 box:dns/waitfordns isChangeSynced: NS davina.ns.cloudflare.com (162.159.38.40) errored when resolve newsite.malenfant.dev (A): Error: queryCname ENODATA newsite.malenfant.dev

but if I ping newsite.malenfant.dev from the command line it gets resolved correctly... odd.

Could it be that the domain is hardcoded in cld.sh?

# Generate self-signed wildcard certificate for all subdomains
echo "Generating self-signed wildcard certificate for *.appx.uk..."
# Extract the base domain (appx.uk) from CLOUDRON_APP_DOMAIN
BASE_DOMAIN="appx.uk"
WILDCARD_DOMAIN="*.${BASE_DOMAIN}"

Nice one!

I think as an option it's a really good idea. I'll look into it if I get a chance.