Docker on Windows Platforms with Portainer – Known Issues

As we have been completing extensive testing of the upcoming Portainer 1.23.2 release, we have struggled to workaround four persistent issues with Docker when running atop of Windows 10 and Windows Server 2019.

If you are using Portainer on Windows Server 2019, and you are running in SWARM MODE, then you dont need to worry, as these bugs do not impact you.

If however, you are running Portainer on Windows 10 or Windows 2019 in Standalone mode, read on..

Issue 1 - Portainer with Docker Desktop on Windows 10 or Docker Enterprise on Server 2019, when running in standalone mode, cannot deploy ANY stacks (compose v2). There is a red toaster message displayed saying "Windows does not support MemorySwappiness."

This is caused by one of our dependencies, libcompose. There was a feature introduced in commit: https://github.com/docker/libcompose/commit/48231471331da6ec1e2a13e3d1e1a31d8c28a079 which added support for memoryswappiness feature for Linux environments, but failed to exclude this option for Windows Container environments, which rightfully, do not support this option.

In order to resolve this issue, we would need the maintainers of Libcompose to either revert the merged feature, or to correct the bug with this feature when used in Windows environments. Unfortunately, Libcompose is no longer actively maintained, so this is unlikely to occur. Alternatively, Portainer staff could correct this in a fork of Libcompose should there be sufficient demand.

There is no current workaround for this issue.

Issue 2 - Portainer with Docker Desktop on Windows 10, when operating as a single node swarm cluster, cannot deploy any Stacks/Services.  Deployments succeed, but silently fail. Inspecting the logs of the service shows "hnsCall failed in Win32: The parameter is incorrect. (0x57)".

We have opened an issue in the docker/for-win Git Repo, and were directed to the Moby/Moby Repo. This issue has now been tagged as a bug in Docker for Windows as per issue: https://github.com/moby/moby/issues/40621

Until this issue is resolved by Docker, we are unable to provide a solution that supports this use case.

Issue 3 - Portainer with Docker Desktop on Windows 10, when configured to run in Linux Container Mode, with the node defined as a single node swarm cluster, and with services deployed with "system generated port publishing" fail to publish the ports. The service is deployed, however the randomly chosen port is not accessible.

We have opened an issue against Docker as the issue exists via docker CLI (Portainer not present). https://github.com/moby/moby/issues/40700 and https://github.com/docker/for-win/issues/6051

You can work around this issue by always specifying a host port to publish a container port on.

Issue 4 - Portainer agent will not deploy on Docker Desktop on Windows 10, when using "Windows Containers Mode" using docker run. An error of "Failure in a windows system call: The username or password is incorrect (0x52e).

The agent container, which runs Windows Nano, uses the account ContainerAdministrator, which should be a valid user account in the Docker for Windows environment. This same container image works fine in Docker on Windows Server 2019.

This is a known issue in Docker for Windows git as per https://github.com/docker/for-win/issues/4798

No known workaround for this issue exists at this stage.

 

Summary

In conclusion, we have the following conditions:

  • Portainer, Windows 10, Windows Containers, Standalone Mode
    • Compose File (Stacks) Deployments will always fail with an error
    • Portainer Agent will not deploy
    • All other Portainer features work as expected
  • Portainer, Windows 10, Windows Containers, Swarm Mode
    • Ingress Networks are non-functional, which means no support for deploying Stacks/Services
    • Portainer and its agent cannot be deployed as a stack due to the above.
  • Portainer, Windows 10, Linux Containers, Standalone Mode
    • No known issues
  • Portainer, Windows 10, Linux Containers, Swarm Mode
    • Deploying a Stack or Service with randomly issued Host Ports will render the service inaccessible from the network; workaround is to statically assign the host ports to be mapped to container ports
    • Else, no other known issues
  • Portainer, Windows Server 2019, Standalone Mode
    • Compose File (Stacks) Deployments will always fail with an error
    • All other Portainer features work as expected
  • Portainer, Windows Server 2019, Swarm Mode
    • No known issues

When we see the underlying issues be resolved by Docker and/or Microsoft, we will update this post accordingly (as well as making changes to Portainer if applicable).

Neil Cresswell

Co-Founder and CEO, Portainer.io

 


Leave a comment!

All fields marked with an asterisk* are required.