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.
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
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.
