Images served from different Server URL after migrating to another server/domain name

Community Support
1

Description

I’m in the process of upgrading my Rocket Chat installation from 5.x to 6.0, while also upgrading my distribution and going from Docker Compose V1 to V2.

To test this, I’ve created a staging server where I installed the latest version of my distribution and setup Docker Compose and Nginx. I changed the ROOT_URL from oldserver.site to newserver.site. Then I ran docker compose up -d, restored from a mongodb dump using --drop, and all seemed well… except the images are all being served from oldserver.site.

New Images are served from newserver.site, but the old ones from the database dump, which are all still there, are served from oldserver.site when I click Attachments in a direct chat and hover over the image.

I’m using GridFS for my images, so they’re stored inside of MongoDB. I’ve tried restarting the containers, upgrading the Rocket Chat container incrementally to 6.2…but it remains the same.

The Site URL in Rocket Chat General settings was set to oldserver.site, so I set it to newserver.site, but that didn’t help.

Does anyone have any ideas as to what might be causing this? A quick docker compose logs reveals a lot of output, but no bright orange or red warnings. I don’t know much about MongoDB yet.

Server Setup Information

  • Version of Rocket.Chat Server: 6.2
  • Operating System: Ubuntu 22.04 LTS
  • Deployment Method: Docker Compose
  • Number of Running Instances: 1
  • NodeJS Version: v14.21.3
  • MongoDB Version: 5.0
  • Proxy: nginx
  • Firewalls involved: None

Any additional Information

compose.yml:

services:
  rocketchat:
    image: rocketchat/rocket.chat:6.2.0
    restart: unless-stopped
    volumes:
      - ./uploads:/app/uploads
    environment:
      - PORT=3010
      - ROOT_URL=https://chat.newserver.site
      - MONGO_URL=mongodb://mongo:27017/rocketchat?directConnection=true
      - MONGO_OPLOG_URL=mongodb://mongo:27017/local?directConnection=true
      - OVERWRITE_SETTING_Show_Setup_Wizard=completed
    depends_on:
      - mongo-init-replica
      - 3010:3010
    labels:
      - "traefik.enable=false"

  mongo:
    image: mongo:5.0
    restart: unless-stopped
    volumes:
     - ./data/db:/data/db
     - ./data/dump:/dump
    command: mongod --oplogSize 128 --replSet rs0
    labels:
      - "traefik.enable=false"

  # this container's job is just run the command to initialize the replica set.
  # it will run the command and remove himself (it will not stay running)
  mongo-init-replica:
    image: mongo:5.0
    command: 'mongo mongo/rocketchat --eval "rs.initiate({ _id: ''rs0'', members: [ { _id: 0, host: ''mongo:27017'' } ]})"'
    depends_on:
      - mongo

Specifically, the images are served from:

https://oldserver.site/ufs/GridFS:Uploads/xxxxxxxxxxx/oldimage.png

As opposed to new images being served from:

https://newserver.site/ufs/GridFS:Uploads/xxxxxxxxxxxxxx/newimage.png

So after learning some mongo shell commands, I did this:

docker exec -it docker-rocketchat-mongo-1
mongo
use rocketchat;
db.rocketchat_uploads.find()

And I discovered that the URL seems to be hardcoded?

{ "_id" : "xxxxxxxxxx", 
"name" : "imagename.png", 
"size" : 314654, 
"type" : "image/png", 
"rid" : "xxxxxxxxxxxxxxxxxxxxxxxxxxxx", 
"userId" : "xxxxxxxxxxxxxx", 
"store" : "GridFS:Uploads", 
"_updatedAt" : ISODate("2021-05-11T07:09:37.891Z"), 
"instanceId" : "xxxxxxxxxxxxxxxx", 
"identify" : { "format" : "png", "size" : { "width" : 2998, "height" : 2991 } }, 
"complete" : true, 
"etag" : "xxxxxxxxxx", 
"path" : "/ufs/GridFS:Uploads/xxxxxxxxxxxx/imagename.png", 
"progress" : 1, 
"token" : "6b98391969", 
"uploadedAt" : ISODate("2021-05-11T07:09:37.909Z"), 
"uploading" : false, 
"url" : "https://oldserver.site/ufs/GridFS:Uploads/xxxxxxxxxxxxx/imagename.png", 
"description" : "A really old image", 
"typeGroup" : "image" }

I’m not really sure what to do now.

2

Yes, the old hard-coded hostnames in the URLs of the database are a major RocketChat problem that I could finally solve. As far as I understand, the best is to remove all hostnames so that at the end we have only relative URLs starting with e.g. “/ufs/GridFS:Uploads/…” in the database.

The following is for my Snap install, for Docker etc. this will probably differ:
First stop rocketchat server service (but mongo db service must continue to run)
service snap.rocketchat-server.rocketchat-server stop
Then perform a DB backup:
snap run rocketchat-server.backupdb
Open the Mogo shell:
rocketchat-server.mongo
Select the database (in my Snap install it is not called “rocketchat” but “parties”:
use parties
To see if there are URLs that contain http and https (which they should not), use:
db.rocketchat_uploads.find({ url: { $regex: "http", $options: "i" } })

Now you need to remove (replace with an empty string) the protocol + hostname + port (if existing) from all such URLs in the database, e.g.

db.rocketchat_uploads.find().forEach(function(row) {
  row.url = row.url.replace(new RegExp("http://rocketchat.mydomain.local:3000", 'g'), "");
  db.rocketchat_uploads.save(row);
});

Or:

db.rocketchat_uploads.find().forEach(function(row) {
  row.url = row.url.replace(new RegExp("https://rocketchat.mydomain.local", 'g'), "");
  db.rocketchat_uploads.save(row);
});

You should do this for all your hostnames you had in the past but are still in the database.

Finally, if there are no more http://… oder https://… in the URLs you should finally get an empty response from:
db.rocketchat_uploads.find({ url: { $regex: "http", $options: "i" } })
This will mean that there are only relative URLs in the database.

Be very careful when editing the database!

BTW: This problem showed up for me only when I clicked to maximize screenshot images I had posted directly in the chats. Then three spinning dots with a small broken image in the middle appeared instead of the zoomed in image. Chrome console showed a mixed content error, as the full image was trying to load from the old http URL and port 3000. In contrast, the screenshot image previews were correct.

I hope this helps,
Anguel

Credits go to this blog:

1 Like