Attachments refer to old server after migration

Summary

After a successfully migration of GitLab 9.0.5 to a new server the attachments (docs,images, etc) in the "Merge Requests" and "Issues" description, are still referring to the old server, even when the paths of the attachments are relative. The documents themselves exist on the new server (if I hard-code the new server in the URL the image loads fine, even if I make just a small change like add a new line or a space the relative path get fixed) The new attachments are loaded fine with a relative path.

Steps to reproduce

1. In server A; Enter a couple of "Issues" and "Merge Requests" and attach files to the description (Gitlab 9.0.5 Omnibus CentOS6)RedHat6.

2. Migrate GitLab server A to server B (Gitlab 9.0.5 Omnibus CentOS7)RedHat7.

   • a) Backup gitlab.rb and gitlab-secrets.json

   • b) $ sudo gitlab-rake gitlab:backup:create

   • c) configure gitlab.rb and restore gitlab-secrets.json

     $ gitlab-ctl reconfigure

     $ gitlab-ctl restart 

   • d) restore Gitlab https://docs.gitlab.com/ce/raketasks/backup_restore.html#omnibus-installations

Note: I tried reconfiguring and restarting again after issue

What is the current bug behavior?

Link refer to old server (troi)

What is the expected correct behavior?

Link refer to actual server

Relevant logs and/or screenshots

(Paste any relevant logs - please use code blocks (```) to format console output, logs, and code as it's very hard to read otherwise.)

Results of GitLab environment info

System information System: RedHatEnterpriseServer 7.2 Current User: git Using RVM: no Ruby Version: 2.3.3p222 Gem Version: 2.6.6 Bundler Version:1.13.7 Rake Version: 10.5.0 Redis Version: 3.2.5 Git Version: 2.11.1 Sidekiq Version:4.2.7

GitLab information Version: 9.1.0 Revision: c3f0f143 Directory: /opt/gitlab/embedded/service/gitlab-rails DB Adapter: postgresql URL: http://dpvx012x.dp.us.conti.de:82 HTTP Clone URL: http://dpvx012x.dp.us.conti.de:82/some-group/some-project.git SSH Clone URL: git@dpvx012x.dp.us.conti.de:some-group/some-project.git Using LDAP: yes Using Omniauth: no

GitLab Shell Version: 5.0.2 Repository storage paths:

• default: /var/opt/gitlab/git-data/repositories Hooks: /opt/gitlab/embedded/service/gitlab-shell/hooks Git: /opt/gitlab/embedded/bin/git

made the issue visible to everyone

@PedroRomeroV There's a bug here, we're looking into it in the following issue:

• https://gitlab.com/gitlab-org/gitlab-ce/issues/29748

Please take a look at the steps that we are proposing to add to the restore process. They should be the same for the migration too.

closed

Thanks. That works perfectly