Docker Community Forums

Share and learn in the Docker community.

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?

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 https://hub.docker.com/editions/enterprise/docker-ee-server-windows 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.

(Hmmm, that bullet list is not showing any bullets in a desktop browser, but looks fine on mobile.)

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.

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.