Es war tatsächlich noch ein zweites mongo docker image vorhanden:

54bda9be368d mongo:4.0 “docker-entrypoint.s…” 45 hours ago Exited (0) 45 hours ago egroupware-rocketchat_mongo-init-replica_1

Das habe ich mit “docker rm 54bda9be368d” entfernt und das System mal neu gestartet, macht aber leider keinen Unterschied.

Das andere mongo Image läuft gleich lange wie der Rest und lauscht laut "docker ps -a " auf Port 27017/tcp.

Ich habe jetzt nochmal alles von Rocketchat entfernt, alle docker images und volumes und auch Config Files in /etc/egroupware-rocketchat/
Und anschließend die Installation von Rocketchat frisch gestartet, das Docker Image wurde geladen, hier der Mitschnitt der Installation:

rocketchat.log.txt8 (66,9 KB)

Laut dem Installer gab es auch keine Probleme, docker zeigt mir jetzt wieder diesen einen mongo DB Container an der mit Exited nach der Installation beendet wird. Keine Ahnung ob das normal ist oder etwas zu bedeuten hat.

Das verwerfen und neu generieren der Mongo-DB führt leider auch zu nichts.

Ein weiteres Detail: Wenn ich per Port forwarding direkt auf 127.0.0.1:3000/rocketchat/ zugreife, dann lande ich exakt im gleichen Bildschirm bei dem’s nur blinkt.

Schöne Grüße
Manfred

Guten Morgen Stefan,

danke für dein Antwort - die Logfiles geben leider nicht wirklich was her.
Die Browser Konsole liefert folgendes:

910bfdf……s_resource=true:853 Throttling navigation to prevent the browser from hanging. See https://crbug.com/882238. Command line switch --disable-ipc-flooding-protection can be used to bypass the protection

Ich denke es hängt irgendwie damit zusammen.

Wegen der URL im letzten Post - mir war schon klar dass das der Direktaufruf vom Rocketchat war/ist, ich wollte nur klar stellen dass der Fehler dort genau gleich auftaucht und ich denke dass das umgebende Egroupware als Quelle ausgeschlossen werden kann.

Ich habe es gerade noch einmal mit einer frischen VM probiert und dort Ubuntu 20.04 neu installiert und dann egroupware-docker und egroupware-rocketchat. Sobald ich RC starte bekomme ich das Problem zu sehen, egal ob ich mit oder ohne SSL Zertifikat arbeite. In dem Fall habe ich alles via IP-Adresse angesprochen und eingerichtet, also komplett ohne DNS Auflösung weil’s nur lokal läuft.

Schöne Grüße
Manfred

Hallo Stefan,

die Version die ich jetzt mit latest gezogen habe ist 3.16.2.

Der Fehler liegt wohl in der 3.14.2’er Version vom Rocketchat, das war mit “Wo er liegt” gemeint!

Als Sysop kann ich mich jetzt problemlos im RocketChat anmelden, ein Normaler User fliegt aus dem Egroupware System komplett raus. Es folgt folgende Fehlermeldung:

{“error”:“unsupported_grant_type”,“error_description”:“The authorization grant type is not supported by the authorization server.”,“hint”:“Check that all required parameters have been provided”,“message”:“The authorization grant type is not supported by the authorization server.”}

Im Nginx-Error-Log findet sich nichts, auch der Docker Log vom RocketChat bleibt still.
Wo protokolliert der RocketChat hin, gibt es da noch ein anderes Logfile?

Schöne Grüße
Manfred

3.14.5 meine ich, hab mich vertippt…
ich versuche es mal mit der 3.15.3!

Schönen Abend, ich kann es bestätigen dass die Version 3.15.3 läuft.
Anmeldung mit dem Admin klappt und auch die User können zugreifen!

Der Eintrag:

image: rocketchat/rocket.chat:3.15.3

In der Datei /etc/egroupware-rocketchat/docker-compose.override.yml und anschließendes:

docker-composer pull
docker-composer up -d

Haben’s wieder in Ordnung gebracht!

Vielen Dank
Manfred