1

I recently decided to try out windows containers and i am using my private minecraft server for that purpose (as a hobby project).

I have an image prepared, based on Windows Server Core 2022.

When i start the container manually, it works perfectly:

docker run -it -p 25565:25565 --mount type=bind,source="C:\MinecraftDocker\MinecraftServer",target=C:/MinecraftServer minecraft:winserver2022

(i am mounting the minecraft server folder to allow a persistent world and server config)

However, i usually use the following docker-compose file to simplify this process:

services:
  mc-server:
    build:
      context: .
      dockerfile: Dockerfile_server2022
    image: minecraft:winserver2022
    platform: windows
    container_name: MinecraftServer
    restart: unless-stopped
    ports:
      - "25565:25565"
    volumes:
      - type: bind
        source: C:/MinecraftDocker/MinecraftServer
        target: C:/MinecraftServer

Doing this, the container and server process inside it start up normally, but connecting to it leads to some error message claiming the minecraft authentication servers were down (they are nof course not). A nearly identical compose file work perfectly fine with linux containers (on the same host system).

The weird part is that i built that image that i use to start the contianer manually with the above mentioned compose file. It seems to me that, when starting the service via docker-compose, something is blocking communication from the container to mojangs servers, but not incoming connections from the clients (i can see the failed connection attempt and name of the connecting account in the servers console output). However, i can not for the life of me, figure out what. I have tried removing everything except the bare minimum (context, ports and volumes) from the compose file, but to no avail.

Are there any relevant differences in how docker-compose configures networking and firewalls on a container vs what docker run does? Specifically in interaction with windows server core?

EDIT: DNS is at fault I have done some further digging and found the URLs for the API-Servers the Minecraft server application talks to when verifying client identities. That led me on to discover that any DNS resolution from the container fails when it is started via docker-compose, but not when started via docker run. It can ping the relevant IP's just fine either way. Question is, why?

EDIT2: Workaround Turns out the docker container attempts to get DNS responses from the gateway configured in the network compose generates, and for some reason does only gets "server failed" responses. Conversely, docker run just grabs the hosts DNS config which is why that works.

When i override the docker-compose created container's primary DNS server by adding this into the service's config, it is suddenly able to resolve host names just fine:

dns: <DNS server IP>

While i would really like to find out why the container doesn't get a response from the network gateway, this is at least a usable workaround. Any more insights or ideas as to the root cause, or why this issue does not arise for linux containers launched via compose, would be appreciated, but my immediate problem is at least solved

1

Workaround

While have not found the root cause for why this only affects the specific combination of windows containers and docker-compose, i want to add the workaround mentioned in the second edit for other peoples benefit:

I solved my problem by overriding the container's primary DNS server. After adding this into the service's config, it is suddenly able to resolve host names just fine:

dns: <DNS server IP>

Turns out the docker container attempts to get DNS responses from the gateway configured in the network that compose generates, and for some reason only gets "server failed" responses. Conversely, docker run just grabs the hosts DNS config which is why that works. Why only my windows containers are affected, i do not know.

Further reading:

DNS in the compose file reference

A guide on networking in compose

0

Maybe try this syntax, with quotes for the volume:

services:
  mc-server:
    build:
      context: .
      dockerfile: Dockerfile_server2022
    image: minecraft:winserver2022
    platform: windows
    container_name: MinecraftServer
    restart: unless-stopped
    ports:
      - "25565:25565"
    volumes:
      - "C:/MinecraftDocker/MinecraftServer:C:/MinecraftServer"
3
  • Thanks for the suggestion, unfortunately it did not work. I didn't expect it to, though, since the server starts up properly (and reads the mounted files without issue). The problems start when clients attempt to connect to it. Some further testing has revealed that something is wrong with the containers name resolution when it is started via docker compose. I have updated the question with further info Oct 25 at 22:46
  • @AdrianDeWinter looks like you solved it--the dns block in docker-compose.yml Oct 26 at 14:05
  • yep. I would love to find out why this workaround is even necessary, aka why does the linux container get proper DNS responses with the default network, but not the windows container? Anyways, it seems like i wont get an answer to that anytime soon. I'll add the Workaround as an awnser, for anyone else who stumbles across this problem Oct 27 at 14:17

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.