Linux container support on Windows servers

I have been trying to find recent information about Linux container support (lcow) on Windows server, but Windows Server 2016 1709 seems still to be the latest version for lcow.

While Microsoft is constantly releasing new builds of Windows Server 2019 preview, there is no news about lcow support, only new Windows containers.

Has development of Linux container support stopped or what is happening?

1 Like

A few years later the question still seems relevant, or is relevant again. It seems that mid December 2020 all references to Windows Server were removed from, e.g., Docker Hub:

Many old blog posts referred to that search query, so the above must have shown something earlier?

Also, many old posts refer to Docker which is a 404 since mid December. Until last month, that page stated:

Docker Enterprise (Windows Server) is available at no additional cost to all Windows Server 2019 and 2016 customers. Technical support is aligned to the Microsoft support entitlement and provided by Microsoft.

I don’t know if the above referred to something that could run Linux containers on Windows Server.

I know Mirantis acquired Docker’s Enterprise Platform a year earlier in November 2019. But I failed to find any announcements about the recent changes. This all coincides with name changes though, in which ‘Docker Engine - Enterprise’ was renamed to 'Enterprise Container Runtime’ mid December too.

I’d love to know what happened, and above all: if there is any future for Linux containers on Windows Server.

Some more observations in case it helps someone:

  • Docker Desktop 3.0.0 for Windows 10 runs Linux containers fine on Windows Server 2019 (Datacenter edition, version 1809, build 17763.1637). It installs Docker Desktop Service for the Windows Local System account, and even defaults to Linux containers. It also adds a group docker-users to which Windows users can be added. But:

    • It does not keep running when the user who started Docker Desktop logs off.

    • So, Docker Desktop would need some trickery to get it running using automatic login of some dedicated user?

    • I somehow feel that Docker Desktop is a developer environment, not meant for production?

  • The Microsoft article Docker Engine on Windows, seems to get one support for Windows containers only.

  • Mirantis confirmed to me that their ‘Enterprise Container Runtime’, previously known as ‘Docker Engine - Enterprise’, only supports Windows containers.

  • A June 2019 blog post, Docker :heart: WSL 2 – The Future of Docker Desktop for Windows, along with pre-releases of Windows Server that include WSL 2, may indicate there is hope. But that post is about Docker Desktop without any mention of Windows Server.

  • The much older September 2017 Exciting new things for Docker with Windows Server 1709 mentioned:

    A key focus of Windows Server version 1709 is support for Linux containers on Windows.

1 Like

Some more progress, two workarounds that after very limited testing seem work for us, though running Docker Desktop on Windows Server still doesn’t feel right. And I’m still curious to know what changed last month, and what may be planned.

The best option if using Docker Desktop on Windows Server, I feel, is to simply create a Scheduled Task to run Docker Desktop (a minute) after server start. Make sure to choose “Run whether user is logged on or not”, specify the user that should run it, and apparently important: set the “start in” folder to match that user’s home directory. (This is not set for the Start Menu shortcut, so maybe there’s a different default when really logging in, or maybe I’m just wrong about this requirement.) Finally, ensure to disable the standard option “Stop the task if it runs longer than 3 days”. When saving, you will be prompted for the user’s password (and that is actually validated as well). Running docker system info should show you the settings that you may have set using Docker Desktop Dashboard.

After a restart it may take a while before all is running, during which things like docker ps (regardless which user runs that) may show no result, or an error:

> docker ps

> docker ps
Error response from daemon: Bad response from Docker engine

> docker ps
error during connect: This error may indicate that the docker daemon is not running.: Get http://%2F%2F.%2Fpipe%2Fdocker_engine/v1.24/containers/json: open //./pipe/docker_engine: The system cannot find the file specified.

But those errors will go away.

When started using Task Scheduler one cannot use the Docker Desktop Dashboard, not even when the very same user logs in. When trying to start it, it will complain:

Docker failed to initialize

Docker Desktop is already running.
Close it in other sessions to continue.

I assume Windows professionals also know how to run this as a service, rather than some Scheduled Task that is hard to find.

Alternatively, simply enabling the Dashboard’s checkbox to run Docker Desktop after login, and then using Microsoft’s instructions to make a user login automatically after restart, works too. But then, of course, Docker Desktop will stop if that same user really logs in and then logs out rather than only disconnects. Minor advantage: the Docker Desktop Dashboard is available this way.

1 Like

For posterity: with the above setup, enabling a nightly backup made Docker be unresponsive every morning. I’ve no idea what kind of backup was used. Also, all expected Docker processes seemed to be running, but Docker would still complain:

% docker ps

Error response from daemon: open \\.\pipe\docker_engine_linux: The system cannot find the file specified.

I could not find any error in any log when the backup was running, but I don’t really know how to troubleshoot Windows installations; even Windows’ Event Viewer is hard to use for me. Maybe this is related to Hyper-V on Windows Server 2019. As this server does not hold any important data, we boldly asked our IT department to disable the daily backup.

According to the link below I believe that the best option is to use WSL2 tools (on Windows 10 or Windows Server 2019 version 1709 or later) to install the Linux version of Docker-CE as opposed to using Docker Desktop.

1st option: Using Docker Desktop for Windows with WSL2 backend.
2nd option: Using WSL2 tools to install the Linux version of Docker-CE.

The first option is appropriate for developers who build their projects on Windows platform and need native Linux kernel support for Docker. That makes it possible to run containers without emulation and use the Linux workspaces. Also, we should mention that Docker with WSL2 makes the system resources (specifically, memory) less demanding since it uses the dynamic memory allocation function.

The second option provides functionality of the Linux environment, which gives an advantage for projects using its tools and repositories. Note that Docker-CE does not require a basic desktop version and the Hyper-V service. Therefore, this option allows you to run other virtual machines together with WSL for other different tasks.

In general, the usage of Docker-CE and WSL does not differ from the typical Docker usage on Linux systems.


Docker-CE on WLS2 indeed IS a linux version. The only two differences that come to mind are WSL2 related:

  • by default WSL2 distributions do not run systemd - no automatic start of the docker deamon.
  • by default WSL2 exposes ports bound inside the WSL2 distribution to the localhost interface of the host (unrelated to docker!) It is not possible to access a published port of a container from within the lan using the host’s ip.

While there are at least two workarounds for the first point (start it manually, use one of the systemd hacks), the 2nd point is by WSL2’s design and requires a firewall configuration.

Thus said, I wouldn’t use Docker-CE in WSL2 for productive workloads. But I love it for development and testing.

Hi Metin
Thanks for your response.

Is this what you were referring to (firewall rule)?


Ps. Yes, apologies for missing auto correct (Martin vs Metin).

1 Like

Spot on! The SO thread discusses the portforwarding and bridged mode options.

I assume by Martin, you mean me :slight_smile:

I have a further note on this, even though it might be off-topic:

Even though the Windows-Subsystem for Linux feature can be enabled alone, it will not run WSL2 distributions unless the feature Virtual Machine Platform is enabled as well. As a caveat the later will bringt a minimal hyper-v layer to the table, which will force other VM solutions like VirtualBox or VMware Wokrstation to run in a much slower Hyper-V compaitibility mode.

1 Like

I hope it’s clear that my old answers above are workarounds.

Just for future reference, for those who find this old topic, a statement from someone actually working at Microsoft:

1 Like

Not sure this is allowed, but for anyone interested on Linux containers on Windows Server, I’d love to chat more and understand the scenario. Please reach out.

Here’s a workaround that is supported: You can use Hyper-V to install a Linux VM on Windows Server and run your containers there. This is not much different than what WSL does.

Here’s another workaround that is supported: You can use WSL2 on Windows Server 2022 now: WSL2 now available on Windows Server 2022 ( Please note this is only on Windows Server 2022!