Help regarding failing docker-based setup

Hi everyone!
Let me start this off by stating that I am utterly impressed by how good jitsi meet is, how polished the software is, and how good the quality is. The setup worked flawlessly for me (at first), thanks to which I was able to get it up and running without authentication in ~15 minutes on my server, tested it out, and loved it!

Now onto the problem:
Given that I set it up without authentication, I wanted to add internal auth to lock room creation to myself only. Several tries got me nowhere, and I wanted to get some help on that.
Unfortunately, my last attempt involved deleting everything (~/.jitsi-meet-config/ and the git repo) then reinstalling from scratch. When I did that (and completed the quickstart setup), the (previously working) video calls stopped working, and got me stuck in with a working web dashboard, but broken rooms see screenshot:


debugging this a little showed that both jvb docker containers were unable to authenticate to the XMBB prosody container:
relevant logs:
prosody:

Component authentication failed for focus.meet.jitsi
Disconnecting component, <stream:error> is: <stream:error><not-authorized xmlns='urn:ietf:params:xml:ns:xmpp-streams'/><text xmlns='urn:ietf:params:xml:ns:xmpp-streams'>Given token does not match calculated token</text></stream:error>

jicofo:

Jicofo 2020-04-13 14:01:53.458 SEVERE: [34] org.jitsi.meet.ComponentMain.log() not-authorized, host:xmpp.meet.jitsi, port:5347
Jicofo 2020-04-13 14:01:49.823 SEVERE: [28] org.jitsi.impl.protocol.xmpp.XmppProtocolProvider.doConnect().315 Failed to connect/login: SASLError using SCRAM-SHA-1: not-authorized
Jicofo 2020-04-13 14:01:53.222 SEVERE: [33] org.jitsi.xmpp.component.ComponentBase.log() Failed to send ping

What’s especially weird is that I have now tried to completely destroy any trace of jitsi to recreate it from scratch several times (deleting the config directory, killing containers and removing images), only to get the same error, whereas two days ago everything was working fine.
I may note that even though at this point problems are likelier to be related to my install, I did notice that everything started not working after a docker-compose up -d that I ran had to pull some new layers (maybe an update had been pushed).

Extra details which may be related to the problem:
I didn’t change the .env file beyond the example (except for running gen-passwords.sh) I played around with some other settings at first to try and make authentication work, but now my main problem (video not working at all in rooms) occurs even without changing anything.
My setup runs entirely behind an nginx proxy:

  • Https (443) traffic to jitsi.my-example-box.dev is proxied to the local web container’s http port (8000),
  • UDP 10000 port is open and directed to my box.
  • tried toggling the backup tcp port for video transfer, but that did not change (in my successful tries, it was closed)
  • Tried changing the PUBLIC_URL .env variable to match jitsi.my-example-box.dev, but that also didn’t affect the results (in my successful tries, I didn’t have to set that)
  • Didn’t touch any other .env variable like letsencrypt since this runs behind a proxy that’s already properly certified

running containers (in case I’m missing an obvious change, but don’t think that ever changed since I follow the docker-compose)

CONTAINER ID        IMAGE                              COMMAND                  CREATED             STATUS              PORTS                                              NAMES
bd9de03ee326        jitsi/jvb                          "/init"                  17 minutes ago      Up 17 minutes       0.0.0.0:4443->4443/tcp, 0.0.0.0:10000->10000/udp   docker-jitsi-meet_jvb_1
216a58b4d93e        jitsi/jicofo                       "/init"                  17 minutes ago      Up 17 minutes                                                          docker-jitsi-meet_jicofo_1
e849b0ab2c4a        jitsi/prosody                      "/init"                  17 minutes ago      Up 17 minutes       5222/tcp, 5269/tcp, 5280/tcp, 5347/tcp             docker-jitsi-meet_prosody_1
4c8137ffd6e1        jitsi/web                          "/init"                  17 minutes ago      Up 17 minutes       0.0.0.0:8000->80/tcp, 0.0.0.0:8443->443/tcp        docker-jitsi-meet_web_1

At this point I’m kind of at a loss for what to try next, especially since restarting from scratch doesn’t seem to change much!
Any ideas?

Thanks again, and sorry for the long post!

I ran into the same problem. I just updated all the passwords with the new gen-passwords.sh

I tried several things but I think at the end the problem was some state in my .jitsi-meet-cfg folder.
After moving/deleting it, everything worked again.

It really feels like that’s the kind of error that comes from that, but unfortunately I deleted my .jitsi-meet-cfg over and over to no avail

You can get help from https://easyjitsi.com We will help you there

Hi, I wanted to say that I was finally able to resolve the issue, and can confirm once again that the platform is really awesome - and I was finally able to enable internal authentication following the very well-written github tutorial!

The one PSA that was missing for me (with hindsight it seems very obvious, but I hope this will help other people)

When running the docker-based jitsi-meet install on Ubuntu, docker will be installed with root privileges, and require sudo to run commands.

Because of this, the default CONFIG path in example.env, ~/.jitsi-meet-cfg will not resolve to
/home/you_user/.jitsi-meet-cfg
but
/root/snap/docker/current/.jitsi-meet-cfg
instead.

(I found out by running sudo docker inspect -f '{{ .Mounts }}' container_id on one of the jitsi containers.)

This is also why I was mysteriously unable to reset my configuration no matter how much I deleted my ~/.jitsi-meet-cfg directory - it wasn’t being used in the first place.

The dead-easy fix was to change the CONFIG path in .env to /home/you_user/.jitsi-meet-cfg.
I’m not sure if this is basic enough to merit mention in the quick-install docs, but if other people make the same mistake would be nice to either add it to the docs, or make a one-click-install script that copies env.example, runs ./gen_passwords.sh and makes the config path absolute based on current working directory.

Really glad I could resolve it, good luck to other fellow installers!

3 Likes

Work for me <3 thanks!