Rocket.Chat gives meteor runtime config error

I have these kind of errors on stucking home page of my rocketchat:

Failed to load resource: the server responded with a status of 404 (Not Found)

Refused to execute script from ‘https://rocketchat.office129-5.local/meteor_runtime_config.js?hash=d1a24ca8938fc18b2f7ed883a1262c4ff59e9e28’ because its MIME type (‘’) is not executable, and strict MIME type checking is enabled.

Uncaught ReferenceError: meteor_runtime_config is not defined
at client_environment.js:1:1
at client_environment.js:78:1
at url_common.js:80:1

It’s just endless loading, nothing more.
How can I fix it? Rocketchat installed as snap

I have tried to revert rocket version but it affects nothing

Server Setup Information

  • Version of Rocket.Chat Server: 6.4.3
  • Operating System: Ubuntu 22.04.3 LTS
  • Deployment Method: snap
  • Proxy: nginx
  • Firewalls involved: no
2 Likes

I have the same problem on rocket chat in k8s with version 6.4.2 and 6.4.4

Server Setup Information

  • Version of Rocket.Chat Server: 6.4.4 (6.4.2 have same problem)
  • Operating System: Centos 7
  • Deployment Method: k8s (official helm)
  • Proxy: nginx
  • Firewalls involved: no

Gary, have you tried version 6.4.5 ?

having the same issue with version rocketchat/rocket.chat:6.4.5

1 Like

having the same issue with version rocketchat/rocket.chat:6.4.4!!! Installed in kubernetes

1 Like

Goddamn it! After about 20 hours of troubleshooting and wondering how it could be possible that such a simple installation process doesn’t work well, I can now confirm that it was a Rocket.Chat bug. Somehow, I only encountered this error with HTTPS, so initially, I thought something in my Nginx configuration was wrong. I updated to version 6.5.0-rc.2, and the problem is now resolved without any additional changes.

hi @kourosh , can you please share your nginx config and .env (even sample details) ? mine still having meteor runtime config error after using 6.5.0-rc.2 and 6.5.0-rc.3.

sure @nelajc :

# Upstreams
upstream backend {
    server 127.0.0.1:3000;
}

# HTTPS Server
server {
    listen 443 ssl;
    server_name chat.example.com;

    client_max_body_size 200M;

    error_log /var/log/nginx/rocketchat.access.log;

    ssl_certificate /etc/letsencrypt/live/chat.example.com/fullchain.pem; # managed by Certbot
    ssl_certificate_key /etc/letsencrypt/live/chat.example.com/privkey.pem; # managed by Certbot
    ssl_protocols TLSv1 TLSv1.1 TLSv1.2; # don’t use SSLv3 ref: POODLE

    location / {
        proxy_pass http://backend;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
        proxy_set_header Host $http_host;

        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto https;
        proxy_set_header X-Nginx-Proxy true;

        proxy_redirect off;
    }
}

no .env file.

I’m facing the same issue after updating my rocket.chat server snap from 5.4.10 to first 6.x/stable (6.4.5 for me, but the same applies to latest/stable = 6.4.1) on my Ubuntu 22.04.3 LTS server, which goes through a nginx reverse proxy.

# https://docs.rocket.chat/deploy/rocket.chat-environment-configuration/configuring-ssl-reverse-proxy
# Upstreams
upstream backend {
    server 127.0.0.1:3000;
}

# HTTPS Server
server {
    listen 443 ssl;
    server_name chat.DOMAIN;

    # You can increase the limit if your need to.
    client_max_body_size 10M;

    access_log /var/log/nginx/rocketchat.access.log;
    error_log /var/log/nginx/rocketchat.error.log;

    ssl_certificate /etc/nginx/tls/DOMAIN.pem;
    ssl_certificate_key /etc/nginx/tls/DOMAIN.key;
    ssl_protocols TLSv1.2 TLSv1.3;

    location / {
        proxy_pass http://backend;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
        proxy_set_header Host $http_host;

        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto https;
        proxy_set_header X-Nginx-Proxy true;

        proxy_redirect off;
    }
}

It seems like right after the installation/restart, the access to the rocket.chat server is successful. So if I service snap.rocketchat-server.rocketchat-server restart and then immediately connect to the rocket.chat webapp, I can log in just fine.

However, after a while any “fresh” access fails and the browser console logs:

Content-Security-Policy: The page’s settings blocked the loading of a resource at inline (“script-src”).
GET	https://DOMAIN/meteor_runtime_config.js?hash=b4fa3d616c8c6c5103c68892b71e78d139da0842
The resource from “https://DOMAIN/meteor_runtime_config.js?hash=b4fa3d616c8c6c5103c68892b71e78d139da0842” was blocked due to MIME type (“”) mismatch (X-Content-Type-Options: nosniff).
The resource from “https://DOMAIN/meteor_runtime_config.js?hash=b4fa3d616c8c6c5103c68892b71e78d139da0842” was blocked due to MIME type (“”) mismatch (X-Content-Type-Options: nosniff).
Loading failed for the <script> with source “https://DOMAIN/meteor_runtime_config.js?hash=b4fa3d616c8c6c5103c68892b71e78d139da0842”.
Uncaught ReferenceError: __meteor_runtime_config__ is not defined

oh… how bout the docker-compose can you share it also? still having the same error.

I’m not sure if this WILL help, but I had a bit similar problem with meteor

In my particular case the solution from this article did REALLY made the trick:

The issue was in $SITE_URL variable not affecting the corresponding value in MongoDB

Hope this’ll help!

Has anyone tried version 6.4.6? does the problem persist?

The same problem appeared with the latest update

With my installation it wasn’t limited to Site_URL

I had to purge and update NodeJs to solve the issue

$>apt remove --purge npm nodejs
$>curl -sL https://deb.nodesource.com/setup_14.x | sudo bash -
$>apt-get install -y nodejs

!! Here it’s Node14 , so please check the version which is compatible with the targeted Rocketchat release

I faced the same issue with the k8s installation for testing. My initial run was done with the port-forwarding option to localhost:8888. I was asked to autoupdate site url from original port :3000 to :8888 so I confirmed. After reload I faced meteor runtime error.

In my case, deleting pod helped to reload instance and probably to pickup updated Site_Url properly.