<p>Maybe try this syntax, with quotes for the volume:</p>
<pre><code>services:
  mc-server:
    build:
      context: .
      dockerfile: Dockerfile_server2022
    image: minecraft:winserver2022
    platform: windows
    container_name: MinecraftServer
    restart: unless-stopped
    ports:
      - &quot;25565:25565&quot;
    volumes:
      - &quot;C:/MinecraftDocker/MinecraftServer:C:/MinecraftServer&quot;
</code></pre>
<ul>
<li>based on this answer at StackOverflow: <a href="https://stackoverflow.com/questions/41334021/volume-binding-using-docker-compose-on-windows">https://stackoverflow.com/questions/41334021/volume-binding-using-docker-compose-on-windows</a></li>
</ul>

CC BY-SA 4.0
2021-10-25T22:46:04.513Z
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
AdrianDeWinter
CC BY-SA 4.0
2021-10-26T14:05:09.060Z
@AdrianDeWinter looks like you solved it--the `dns` block in `docker-compose.yml`
mikequentel
CC BY-SA 4.0
2021-10-27T14:17:42.553Z
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
AdrianDeWinter
CC BY-SA 4.0
2021-10-25T15:39:36.767Z
2021-10-25T15:39:36.767Z
mikequentel
<h1>Workaround</h1>
<p>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:</p>
<p>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:</p>
<pre class="lang-docker prettyprint-override"><code>dns: &lt;DNS server IP&gt;
</code></pre>
<p>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 &quot;server failed&quot; 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.</p>
<p>Further reading:</p>
<p><a href="https://docs.docker.com/compose/compose-file/compose-file-v3/#dns" rel="nofollow noreferrer">DNS in the compose file reference</a></p>
<p><a href="https://docs.docker.com/compose/networking/#configure-the-default-network" rel="nofollow noreferrer">A guide on networking in compose</a></p>

CC BY-SA 4.0
2021-10-27T14:27:37.770Z
2021-10-27T14:27:37.770Z
AdrianDeWinter
<p>I recently decided to try out windows containers and i am using my private minecraft server for that purpose (as a hobby project).</p>
<p>I have an image prepared, based on Windows Server Core 2022.</p>
<p>When i start the container manually, it works perfectly:</p>
<pre class="lang-ps prettyprint-override"><code>docker run -it -p 25565:25565 --mount type=bind,source=&quot;C:\MinecraftDocker\MinecraftServer&quot;,target=C:/MinecraftServer minecraft:winserver2022
</code></pre>
<p>(i am mounting the minecraft server folder to allow a persistent world and server config)</p>
<p>However, i usually use the following docker-compose file to simplify this process:</p>
<pre class="lang-docker prettyprint-override"><code>services:
  mc-server:
    build:
      context: .
      dockerfile: Dockerfile_server2022
    image: minecraft:winserver2022
    platform: windows
    container_name: MinecraftServer
    restart: unless-stopped
    ports:
      - &quot;25565:25565&quot;
    volumes:
      - type: bind
        source: C:/MinecraftDocker/MinecraftServer
        target: C:/MinecraftServer
</code></pre>
<p>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).</p>
<p>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.</p>
<p>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?</p>
<p><strong>EDIT: DNS is at fault</strong>
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?</p>
<p><strong>EDIT2: Workaround</strong>
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 &quot;server failed&quot; responses. Conversely, docker run just grabs the hosts DNS config which is why that works.</p>
<p>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:</p>
<pre class="lang-docker prettyprint-override"><code>dns: &lt;DNS server IP&gt;
</code></pre>
<p>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</p>

<docker><docker-compose><dockerfile><windows>
DNS resolution fails when container is started via docker-compose
AdrianDeWinter
# DNS resolution fails when container is started via docker-compose

(Asked by: username_0 on 2021-10-24)

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: 

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

**Tags:** docker, docker-compose, dockerfile, windows


---

## 2 answers

### Answer by username_0 on 2021-10-27. Score: 4 | Accepted answer

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: 

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


---

### Answer by username_1 on 2021-10-25. Score: 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"


based on this answer at StackOverflow: https://stackoverflow.com/questions/41334021/volume-binding-using-docker-compose-on-windows

> **Comments:**
> **username_0**: 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  
> **username_1**: @username_0 looks like you solved it--the `dns` block in `docker-compose.yml`  
> **username_0**: 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  

---

