Problems accessing MusicBrainz over local network

I upgraded to the new VM, and now I have problems accessing the service over the local network. It appears that half the links in the host page resolve to the correct IP address that I provide. For example:


Unfortunately, the other half always resolve to http://localhost:5000, and, obviously, fail. For example:


I did not have the same problem with the latest VM, if I remember correctly :slight_smile:

Is there any reason why relative URLs are not used for all resources?

1 Like

You need to change WEB_SERVER in lib/

1 Like

Will do. Thanks!

It might be helpful, though, to replace hardcoded URLs in the next release.

1 Like

Yes. A lot of the “static” resources on and other * sites are now being served from (for several reasons). This means that the references to the resources can’t be served with relative links, as a relative link would not result in the browser looking at an external link.

See the ticket for making “StaticBrainz”:

I refer to resources that resolve to http://localhost:5000. External resources such as are totally fine.

From: Freso

The reason why relative URLs are not used for all resources is indeed the use of StaticBrainz.
That said, default settings can probably be improved to allow relative paths in development VM.

1 Like

«[R]esources that resolve to http://localhost:5000» are the resources that are hosted at for the * sites. Hence why

if your server isn’t running on localhost:5000. For, WEB_SERVER is set to (or whatever the format of WEB_SERVER is).

@andreivolgin: You might want to test it: 8263bc2

1 Like

The “old” VM did not require any changes in settings, and my server is running on localhost:5000.

It appears, though, that this commit might fix the problem by removing hardcoded "localhost’.

Have you merged these changes into the main branch? Should I try this fork, or is the new version of the VM is coming soon? It was mentioned that the new versions would be released monthly.

You are contradicting yourself; above, you said it is running on

It is a configuration option. Configurable is the exact opposite of hardcoded.

Well, @rob may have been a bit optimistic there. :slight_smile:

@yvanz: I don’t think we should change MBS to accommodate some VM users. Instead, better change the default configuration in the VM.

1 Like

The old VM was from before was introduced into the mix.

This is the line of code I refer to:

-exports.STATIC_RESOURCES_LOCATION = ‘{{key_or_default (print $DBDefs “STATIC_RESOURCES_LOCATION”) “//localhost:5000/static/build”}}’; and http://localhost:5000 is the same port on the same web server :slight_smile: It’s the difference between accessing it from the same machine or over the local network. When I type “” over the network, half of the home page loads (because they correctly resolve to, while 8 resources fail (because they resolve to localhost:5000). When I type “http://localhost:5000” on the same machine where VM is running, the page loads fine.

Again, if static resources resolve to an external URL (e.g., there would be no problems to access the VM either from the same machine or over the network - and no change in settings would be required.

Some of the static resources (CSS, JS) get compiled per use. There’s no guarantee that the version of CSS and JS you (should) have locally are the same that are on StaticBrainz. (See the c9f2ad5685 and ee7ee655ac parts of the filenames in your original post.) Also, the StaticBrainz was made to lessen the load, if only slightly, especially for MusicBrainz. Even if it could work, I’m not sure it would have the desired effect on load/bandwidth if suddenly everyone using the VM or otherwise setting up their own instances would load all those resources from our servers. One of the reasons for the VM is exactly so people can play around with using and working on the website, without putting load on the server. (Not to mention that you would want to load local files if you’re using it on a machine shielded from outside networking or if you’re developing and need to see only local changes reflected.)

However, it is an issue that pops up now and then, so we will be looking into a way to resolve it. Either by changing the default way of looking up resources (e.g., like @yvanz’ patch (which I’m not sure he made a PR for)), or by changing the default setting specifically for/of the VM (as per @chirlu’s comment). The first step to this getting resolved is filing a ticket for it. I looked at the ticket tracker, and it doesn’t seem like this has been enough of a bother for anyone so far so that they actually reported it. But I went ahead and did so, feel free to watch the ticket to follow its progress and vote on it if you’d like to see it resolved sooner:

1 Like

The patch I linked to is made specifically for @andreivolgin. It was not intended to be merged as is.

Edit: Actually, it might be investigated for a pull request, depending on settings.

@chirlu: Relative URL/absolute path should probably be the default for MBS, not only for VMs, except when using a separate web server for static resources. This latter case (e.g. using should be handled as well.

1 Like

Catalyst generates absolute URLs (though not based on the WEB_SERVER setting, but on the hostname reported by the web server). I don’t particularly like the idea of mixing absolute and relative URLs.

1 Like

I need to change all //localhost:5000/ generated links to either //

Or, even better, to just /:

Even if I prefer the patch, to test it quicker first, I changed musicbrainz-server/lib/DBDefs/

sub WEB_SERVER { "localhost:5000" }
sub WEB_SERVER { "" }

Then I restarted sudo docker-compose up but it was not enough.
What do I need to do first, so that my change to is taken into account?

Would it be the same action for the @yvanzo patch to be taken into account, as well?

Sorry for newbie questions.

I’m not sure if this is still true for the current musicbrainz docker environment.
(assuming from here, that you use the small server with sample data)

Maybe you can find the needed information in this section about Docker Compose overrides and this section about Docker environment variables including the docker-compose.yml file.



Then I just did that Docker environment variables (.env) thing!

  1. Test that I see localhost with sudo docker-compose config
  2. Add MUSICBRAINZ_WEB_SERVER_HOST= to my musicbrainz-docker/.env file
  3. Tests that I see with sudo docker-compose config
  4. Start the server with sudo docker-compose up (now I am starting to know this one

I can’t believe the knowledge all people have in #musicbrainz:devel!