Cannot access URL on new RocketChat container

Community Support
,
1

Description

I am having an issue with standing up a new RocketChat instance on a brand new Debian image. I have followed the documentation and installed using docker compose.

The containers create without issue, but when I try to connect to the URL, I am only faced with a loading screen and nothing ever materializes.

I think part of the issue is that the ROOT_URL is not updating in RocketChat even though I have it set in the .env file. Running ‘docker compose config’ reflects the correct root URL but when I look at the rocketchat container logs, it still shows the “localhost:3000” for ROOT_URL.

Also, when inspecting the loading page, there is a file “meter_runtime_config.js” that is failing to connect to another page because it is trying to connect to localhost:3000 which doesn’t exist on the device I am trying to access from.

I have made numerous changes to the .env file and looked at the build config to confirm the changes are made, but the rocketchat container still is using localhost:3000 as its ROOT_URL.

Server Setup Information

  • Version of Rocket.Chat Server: 6.4.0
  • Operating System: Debian 12
  • Deployment Method: docker
  • Number of Running Instances:
  • DB Replicaset Oplog: Enabled
  • NodeJS Version: 14.21.3
  • MongoDB Version: 5.0.21
  • Proxy:
  • Firewalls involved:

Any additional Information

This is the snippet from the rocketchat container logs
±---------------------------------------------+
| SERVER RUNNING |
±---------------------------------------------+
| |
| Rocket.Chat Version: 6.4.0 |
| NodeJS Version: 14.21.3 - x64 |
| MongoDB Version: 5.0.21 |
| MongoDB Engine: wiredTiger |
| Platform: linux |
| Process Port: 3000 |
| Site URL: localhost:3000 |
| ReplicaSet OpLog: Enabled |
| Commit Hash: e2f60199ab |
| Commit Branch: HEAD
±---------------------------------------------+

Here is the current docker config created from the docker-compose.yml and .env files:

name: root
services:
mongodb:
environment:
ALLOW_EMPTY_PASSWORD: “yes”
MONGODB_ADVERTISED_HOSTNAME: mongodb
MONGODB_ENABLE_JOURNAL: “true”
MONGODB_INITIAL_PRIMARY_HOST: mongodb
MONGODB_INITIAL_PRIMARY_PORT_NUMBER: “27017”
MONGODB_PORT_NUMBER: “27017”
MONGODB_REPLICA_SET_MODE: primary
MONGODB_REPLICA_SET_NAME: rs0
image: Docker: Accelerated Container Application Development
networks:
default: null
restart: always
volumes:
- type: volume
source: mongodb_data
target: /bitnami/mongodb
volume: {}
rocketchat:
depends_on:
mongodb:
condition: service_started
required: true
environment:
DEPLOY_METHOD: docker
DEPLOY_PLATFORM: “”
MONGO_OPLOG_URL: mongodb://mongodb:27017/local?replicaSet=rs0
MONGO_URL: mongodb://mongodb:27017/rocketchat?replicaSet=rs0
PORT: “3000”
REG_TOKEN: “”
ROOT_URL: http://10.0.0.194:3000
expose:
- “3000”
image: registry.rocket.chat/rocketchat/rocket.chat:6.4.0
labels:
traefik.enable: “true”
traefik.http.routers.rocketchat.entrypoints: https
traefik.http.routers.rocketchat.rule: Host(``)
traefik.http.routers.rocketchat.tls: “true”
traefik.http.routers.rocketchat.tls.certresolver: le
networks:
default: null
ports:
- mode: ingress
host_ip: 0.0.0.0
target: 3000
published: “3000”
protocol: tcp
restart: always
networks:
default:
name: root_default
volumes:
mongodb_data:
name: root_mongodb_data
driver: local

Any help would be appreciated!

2

I found the cause of the issue (or atleast mine). Apparently even when you run docker compose down, it does not totally wipe the mongodb data. I originally had run the docker compose without changing the ROOT_URL.

After hours and hours of searching, I finally stumbled upon the answer. Run the command “docker compose down --volumes” while the containers are running and this will wipe the mongodb.

Make sure your .env file is correct and run “docker compose up -d” again and it should change the site URL to what you have listed in the .env file.

Hope this helps!

3

Not working for me, did you change something else as well ?

4

I had edited my compose.yml and .env files a million times but other than running the command that wipes out the volumes for the mongodb, I don’t think so.

Are you able to access the loading page on the root URL? I knew I was close since it was serving the page, but was failing because it was trying to fetch the rest from localhost instead of the URL I had specified.

Have you looked at your container logs?

5

worked, i just added “” to the server url