"You have been disconnected" on fresh docker installation

For a while, Jitsi Meet was running fine. We had multiple meetings without a problem. Problems started when I updated the install.

Straight upon joining a meeting, people are greeted with: “You have been disconnected.”.

Javascript logs:

[JitsiMeetJS.js] <getGlobalOnErrorHandler>:  UnhandledError: null Script: null Line: null Column: null StackTrace:  Error: Strophe: Websocket closed unexcectedly
[connection.js] CONNECTION FAILED: connection.otherError

Docker Prosody logs

c2s5652a77d2130                                              info       Client connected
c2s5652a77d2130                                              info       Client disconnected: closed 

SSL Has been set-up correctly. The domain name in .env is entered correctly (no (double) quotes). Firewall setup is correct. The reverse-proxy (nginx) is working. The docker host address has been set to the public IP. I am out of ideas…

Anybody has a clue?

Edit: I tried doing a fresh deployment, following the official docs, but it ended up in the same error. I triple-checked the things mentioned above.

Unfortunately, I can’t help, but I guess it’s the same problem that I have (Problems with Connection?). The issue seems to have started with version V.5142, coincidently (?), the first version that does not have problems with HTTP-headers when called by wget.

Hello guys,

While waiting for a new version =>

image: jitsi/{web,prosody,jicofo,jvb}:stable-5076 work perfectly.

I had the same problems as you before using the version there

1 Like

Hi Amarsin!
Thanks a lot! It works for me too.

@amarsin thanks for this pointer!!
i just used the current git main branch directly and just thought i have bugs in my nginx reverse-proxy config.
with the git checkout stable-5076 version it just works :slight_smile:
Thanks!!

I encountered the same problems as the OP and followed the hint to downgrade the repository to the release mentioned above. After bringing the docker containers up, the web service fails with the following waring:

[cont-init.d] done.
[services.d] starting services
[services.d] done.
nginx: [warn] invalid value "TLSv1.3" in /config/nginx/ssl.conf:15
nginx: [warn] invalid value "TLSv1.3" in /config/nginx/ssl.conf:15
nginx: [warn] invalid value "TLSv1.3" in /config/nginx/ssl.conf:15
nginx: [warn] invalid value "TLSv1.3" in /config/nginx/ssl.conf:15
nginx: [warn] invalid value "TLSv1.3" in /config/nginx/ssl.conf:15
nginx: [warn] invalid value "TLSv1.3" in /config/nginx/ssl.conf:15
nginx: [warn] invalid value "TLSv1.3" in /config/nginx/ssl.conf:15
nginx: [warn] invalid value "TLSv1.3" in /config/nginx/ssl.conf:15

I deleted the whole directory and cloned it again with no luck. Any ideas what is going wrong?

Martin

@martin95 I’ve encountered the same problem after switching to stable-5076 release.

The problem is, you probably have leftover configuration from the latest version, which does not match the required configuration for stable-5076. Delete your docker containers, then delete ~/.jitsi-meet-cfg that you’ve created for configuration of all jitsi components, then recreate the directory. Now if you bring the containers back up, it’ll work properly.

same problem here - I have a working setup fo 5142 using a dyndns-domain and a certificate from letsencrypt, so I downloaded the new 5390-3 (stable) and tried these steps

  • configure .env, basically same as 5142 with additional port-number for https-url and a new config-directory,
  • generate new passwords,
  • create the new config-directory
  • docker-compose up
    In the log I see the new certificate-message, I can connect to the jitsi-url, both internal and external access work, but whenver I try to start a meeting I just get “you have been disconnected, try again…”
    In the logs I did not find any meaningful messages, but then I do not even know what to look for.
    Switching back to the 5142-setup - working. This is a bit disappointing, because I would like to understand what is going on and what I missed.
    Can someone guide me to trouble shooting documentation?

I checked the container logs without success so far. The browser however shows errors. The first one is

WebSocket connection to ‘wss:// “my url” /xmpp-websocket?room=v’ failed: Error during WebSocket handshake: Unexpected response code: 403
any hints how to follow up? Any known changes from 5142-4 to 5390-3 that may cause this?

solved for now: added
ENABLE_XMPP_WEBSOCKET=0
to the .env
This was mentioned in other discussions regarding similar issues in the 5142 setup. So far I had ignored this setting because 5142 was working for me without this and because it was not included in the env.example. Still would be nice to understand how xmpp-websockets could be fixed.

4 Likes

Tahnk you, wolf_mtk. This solved my issue as well. Interestingly I could not find ENABLE_XMPP_WEBSOCKET
on .env file
I had to add it myself.
I hope this will be solved in next releases

1 Like

This fixed it for me as well. Very tricky to find, how did you find this option? It’s not listed on Self-Hosting Guide - Docker · Jitsi Meet Handbook

Yes, would be nice if this were added to the manual, a trouble shooting guide or the example .env file, browsing discussion boards is fun but it takes more time for sure :wink:

2 Likes

Still broken as of docker 5765. Thanks for posting this!! I was tearing my hair out. I was about to give up and go to the “bare metal” install when I found this post and the warning/fix for AppArmor not playing nice with 2 of the docker instances making them unstoppable.

It also seems you need to clean out and recreate the CONFIG directories. Ugly but still easier than the mess that is the full install.

1 Like

I had exactly the same problem. Can PLEASE somebody fix that? I was already pondering alternatives and would have never returned to Jitsi if that ugly bug would persist.

1 Like

the issue is still there in 6173 and the workaround with ENABLE_XMPP_WEBSOCKET=0 helps.
Alternatively: with my setup it makes a difference whether PUBLIC_URL in .env is set with or without port, i.e.
https://xy.z:443 - workaround required
https://xy.z - seems to work as intended.
This probably makes sense for people who know more about the details of the whole setup than me.
Apparently I had initially tested with non-default ports and left the port when I changed back to 443.

1 Like

This.

PUBLIC_URL in .env is set without port, i.e.
https://xy.z - seems to work as intended.

That solved it. :smiley: