I want to be able to run, and build Linux and Windows (LCOW) containers simultaneously.

[bplasmeijer]

Tell us about your request I want to be able to run and build Linux and Windows (LCOW) containers simultaneously.

Which service(s) is this request for? docker build, and docker-compose

Tell us about the problem you're trying to solve. What are you trying to do, and why is it hard? At this moment, I am using the (LCOW) experimental feature to run Linux and Windows containers simultaneously. The option to work streamless with Linux and Windows container is hard, because of the switch context option.

Are you currently working around the issue?

• Switch context when building Linux images.
• Switch setting back to windows containers, and pull Linux image in (LCOW) mode.

Additional context The new 20H1 WSL docker integration is a great new feature, and I love it, but integration requires Linux mode. I do lose my windows context. Issue #78 describes building both Linux and windows images in parallel on windows.

LCOW is great but lingering in limbo. There are many solutions where Windows and Linux containers work together.

[stephen-turner]

See #78 for more details.

[0x53A]

For me the important part is just building. Yeah, running both in parallel would be nice, but not strictly required.

Our dockerfiles don't do anything fancy, just copy a folder, set an environment variable and set the entry point.

So I'd also be happy with some other tool. Maybe with WSL2 we can invoke buildkit through WSL or something, idk.

[thomasoatman]

Hi. I am working on moving our build and testing environment to Docker Containers. We ship Linux and Windows components and thus need support for both. During testing, we require a Windows client container talking to a database in Linux container. So the lack of dual support is killing my efforts. thank you

[erdtsieck]

We're bound to windows containers due to the use of 'windows authentication' in some of our services and because of some SLA's. We do use some linux containers like consul and traefik. Not being able to mix Windows and Linux containers prevents our team from starting to use WSL2.

[MathiasMagnus]

I am working on upgrading our CI process to allow testing locally. Both GitHub Actions and GitLab CI don't allow running pipelines locally (of course, they weren't designed to do that). Generally I was advised to move away from the feature set of any CI runner and put as much logic into (shell) scripts as possible. Heeding that advice, I'm working on a CMake module (because all of our build automation is CMake anyway) which is able to run CI tasks locally.

Pipeline definition for GitLab and GitHub remain YAML files which do not much more than define the test matrix, distribute the work to runners and invoke a single script on every pipeline stage. The CMake module is an auxiliary project commited into version control.

• CMake configuration step allows customizing the "local runner", selecting some subset of the test matrix one wishes to test for.
• The build step builds the images (from Dockerfiles from within the repo), ideally in parallel.
• CTest runs the same shell scripts which ordinary CI does (actually, they are CMake scripts too, invoked as cmake -P Build.cmake for eg.) in the correct order with dependency tracking inside Docker containers. Tests again ought to run in parallel. (Tests would get labels based on which test matrix elements they inherit, one could select some subset of the test matrix through ordinary CTest CLI args.)

It would be rapid response CI runs without involving remote entities, possibly even run totally offline.

I may be able to orchestrate the entire thing having CMake communicate with two daemons, one locally inside Windows and one running inside WSL2, but setup becomes way more complicated, not to mention having to bind the lifetime of the Linux daemon to a long running Windows process (service?), instead of it being the same daemon which is running on the Windows host anyway.

[profblackjack]

My org has .net framework applications I'm looking to containerize, and I would love to be able to mix Linux and windows containers on dev machines for a local development environment more reflective of our deployed environments

[MarkLFT]

I also would find it extremely useful to be able to run both Windows and Linux containers on a single host. We have many scenarios where it is required we run both types of containers in a single installation.

[derWallace]

For my org using this feature would help us quite a lot as well. We have some legacy components which require to mix Linux containers with Windows containers. Manually switching on the Docker Desktop between Linux containers and Windows containers all the time is quite cumbersome for our developers.

[rompic]

For my org using this feature would help us quite a lot as well. We have some legacy components which require to mix Linux containers with Windows containers. Manually switching on the Docker Desktop between Linux containers and Windows containers all the time is quite cumbersome for our developers.

+1

Afaik it is possible via the DockerCLI

[bplasmeijer]

@nebuk89 any update?

[Seramis]

Any updates?

[nebuk89]

Ah sorry for being quiet, no updates yet I am afraid 😞. Please keep everyone following/providing the 👍 so we can see the interest!

[silverl]

Another +1 here. We have a mix of Windows .NET Framework services and IIS web sites, and Linux services, and would LOVE to be able to run both on a single dev workstation.

[bplasmeijer]

Ah sorry for being quiet, no updates yet I am afraid 😞. Please keep everyone following/providing the 👍 so we can see the interest!

We need some movement on #79 here, see also https://github.com/microsoft/Windows-Containers/issues/34

[conioh]

I'm not sure I understand the issue.

LCOW is deprecated and has some annoying issues such as https://github.com/docker/for-win/issues/10813 that won't be fixed but you can already use Windows containers and WSL2-based Linux containers in the way mentioned at https://github.com/docker/for-win/issues/6311#issuecomment-613315732 as being the future plan by Docker Inc.

Despite the comment there from April 2020 saying

Hi, currently we are facing 2 issues with that:

• There is a remaining bug in 2004 (fixed in insider fast branch) which prevent us to run both windows containers and wsl2 at the same time reliably. (see microsoft/WSL#4726).
• once the bug is fixed, we plan to leverage docker CLI contexts to run and expose both daemons at the same time and allow you to switch from one to the other using those contexts:

# assuming default context is Linux
$> docker run -d -p 127.0.0.2:80:80 nginx
$> docker --context=dd-win run -d -p 127.0.0.3:80:80 aspnet-iis

and supposedly no progress on the issue since, this has works for me since the day WSL2 came out:

I'm sure there was a comment by me right here on this issue that explained how to get it working today but it appears to have disappeared.

[TBBle]

The way I read https://github.com/moby/moby/issues/36682#issuecomment-733763007, LCOW itself is not deprecated, merely the current implementation in Docker. containerd has LCOW support already, and there are MS developers still fixing bugs (at least) in the containerd LCOW support since that comment.

It ought to work in Docker without much effort once Docker uses containerd on Windows, because containerd applies LCOW when a container started for Linux in the Windows daemon. So this is a distinct but non-interfering potential solution for this ticket, contrasting with WSL2.

[conioh]

Microsoft has something called "LCOW v2". See for example https://github.com/microsoft/opengcs and that's what's being worked on in containerd. This not what you get if you install the 4.14 kernel from https://github.com/linuxkit/lcow (which is archived and no work being done on).

I don't do "once". I do "now". Now WSL2 works (and is supported insofar as you can call any Microsoft product or service "supported").

[TBBle]

Oh, thank you, I'd been looking for a reference for "LCOW v2". So in my earlier comment, "the current implementation in Docker" is LCOW v1, and "containerd LCOW support" is LCOW v2, and the rest of the comment still applies.

Note that the v1/v2 split (e.g., visibility of UVM to the HCS API) also applies to WCOW, and Docker is also relying on containerd integration to support the v2 API for WCOW containers.

And speaking of support, MS has recently been somewhat explicit that they do not support WSL2 for production workloads, only for development, going so far as to disable it in Windows Server 2022 LTSC prerelease builds. So a WSL2-based solution isn't currently viable on Windows Server 2022 LTSC, although I'm not sure Docker desktop is supported on Windows Server anyway.

Since (AFAIK) LCOW v2 doesn't require further OS support than already exists in Windows Containers, I don't know if it will be similarly blocked on Windows Server 2022 LTSC; I hope not, as amongst other things, that'll mess with the CI pipelines for containerd.

[conioh]

Oh, thank you, I'd been looking for a reference for "LCOW v2". So in my earlier comment, "the current implementation in Docker" is LCOW v1, and "containerd LCOW support" is LCOW v2, and the rest of the comment still applies.

It still applies in the sense that it's still a nice prospect for the future but doesn't help people today, on May 2021, to run Linux and Windows containers without wasting years of their lives on "Switch to Windows containers...", "Switch to Linux containers...", "Switch to Windows containers...", "Switch to Linux containers...", "Switch to Windows containers...", "Switch to Linux containers...", "Switch to Windows containers...", "Switch to Linux containers...", "Switch to Windows containers...", "Switch to Linux containers...", "Switch to Windows containers...", "Switch to Linux containers...", "Switch to Windows containers...", "Switch to Linux containers...", ...

Using WSL2 does.

And speaking of support, MS has recently been somewhat explicit that they do not support WSL2 for production workloads, only for development, going so far as to disable it in Windows Server 2022 LTSC prerelease builds.

So what? Both WSL2 and LCOW (v1, the only thing that exists) are not supported for production. Both. There's no difference in this regard so it's not a disadvantage of using WSL2. But WSL2 works better for development, which is what people here seem to want (building images, not deploying them in production).

So a WSL2-based solution isn't currently viable on Windows Server 2022 LTSC, although I'm not sure Docker desktop is supported on Windows Server anyway.

It's obviously not. Docker Desktop is only supported and intended to run on Workstation SKUs.

[TBBle]

All I said was "LCOW itself is not deprecated", and "it's a distinct but non-interfering potential solution for this ticket, contrasting with WSL2". I guess you're seeing "don't use WSL2 though docker --context" somewhere in what I wrote, and responding to that?

Poking around, at least on the Microsoft side, LCOW is (or was) supported on Windows Server. As was mentioned at https://github.com/moby/moby/issues/39533#issuecomment-694382362 there are or were existing production uses, and I believe the Windows Server team are still actively committing code for it to containerd, so someone is sufficiently interested in it to invest developer time. And from that ticket, Docker wasn't going to reject getting LCOW via containerd for near-free, even though WSL2 is the currently targeted option.

"Using WSL2 exists", but the support in Docker Desktop for a nice multi-context experience (i.e. https://github.com/docker/for-win/issues/6311#issuecomment-627200096) doesn't, so I wouldn't consider this ticket closed just because it's possible to set up your system and contexts to expose both WSL2 and WCOW container daemons.

Unless I've misunderstood, and you're saying the wsl2 context is created by Docker Desktop now?

I had understood you to mean that the (missing) instructions would set you up into that position. Although I assume that since Docker Desktop doesn't yet support contexts, one of those contexts would be bypassing the Docker Desktop proxy and talking directly to the relevant daemon's socket.

[conioh]

All I said was "LCOW itself is not deprecated", and "it's a distinct but non-interfering potential solution for this ticket, contrasting with WSL2". I guess you're seeing "don't use WSL2 though docker --context" somewhere in what I wrote, and responding to that?

LCOW - the thing that exists and can be used to run Linux containers - is deprecated. No amount of text will change that. The LCOW that actually exists is deprecated and something else called LCOW that might exists in the future doesn't exist yet.

Poking around, at least on the Microsoft side, LCOW is (or was) supported on Windows Server.

You probably should have meant unsupported. I suspect you're confused because there are two meaning to the word "supported" in this context. One is "works or can work in contrast with doesn't work or can't work" while the other is "supported by a commercial entity that will treat things not working as you expect as bugs".

For example, WSL2 supports setting processor count, RAM size and kernel image via the .wslconfig file. Does that mean that Microsoft will support you if you use a broken custom kernel instead of the one provided by them?

See also https://github.com/docker/for-win/issues/6470#issuecomment-620466429 for example

"Using WSL2 exists", but the support in Docker Desktop for a nice multi-context experience (i.e. docker/for-win#6311 (comment)) doesn't, so I wouldn't consider this ticket closed just because it's possible to set up your system and contexts to expose both WSL2 and WCOW container daemons.

k bro. I never said this ticket should be closed. I proposed to interested parties today who have a problem today a way today to use Linux and Windows containers simultaneously today, without going through the whole 3 minute "Switch to Linux containers..." process every few seconds, using the same feature Docker Inc. is planning for them to use in the future anyway.

Unless I've misunderstood, and you're saying the wsl2 context is created by Docker Desktop now?

No, and I didn't say that.

I had understood you to mean that the (missing) instructions would set you up into that position. Although I assume that since Docker Desktop doesn't yet support contexts, one of those contexts would be bypassing the Docker Desktop proxy and talking directly to the relevant daemon's socket.

You have misunderstood. No one and nothing will be bypassing Docker Desktop since Docker Desktop won't be installed.

[TBBle]

LCOW (v1), "the experimental thing that exists now in Docker" is deprecated in Docker, yes.

That's the start of this ticket, a request for something in Docker (Desktop I assume) to replicate that nice workflow. LCOW, the concept, and hence LCOW v2 as a possible solution to the use-case of this ticket, is not deprecated, and if it gets delivered, would indeed provide the same workflow.

[SetTrend]

Shouldn't the documentation be groomed radically to reflect the current situation?

I tend to feel a great source of frustration that Docker documentation is contradicting itself on this point, depending on which documentation page you're reading.

For professional users cluttered documentation is not a path leading to educe trust in the Docker environment as a whole.

[stephen-turner]

@SetTrend Yes, of course the documentation should reflect the current state. If you can point to a page which is wrong, we'll fix it (or you can open a pull request if you prefer, all our docs are open source).

[SetTrend]

I created a number of pull requests already. But no-one cares ... 😢

[SetTrend]

On the other hand:

Belonging to the species of professional programmers who try to gain revenue with their own projects - utilizing Docker, perhaps even having a paid Docker subscription plan, only as a tool - I would not commend expecting those users to invest too much of their time in investigating on a tool's roadmap or to update a tool's documentation.

The most important fact for this breed of programmers is what is available here, right now. Not in the future, not in the past. Everything else will sooner or later lead to not recommending the tool.

[TBBle]

You're commenting on the Docker Roadmap project... It's entirely about the future.

[TBBle]

@conioh

I'm sure there was a comment by me right here on this issue that explained how to get it working today but it appears to have disappeared.

It was over at the duplicate ticket, https://github.com/docker/roadmap/issues/78#issuecomment-684073682, but your repo with the instructions appears to have disappeared. For anyone trying to play along at home, there's vestiges of it at https://github.com/docker/roadmap/issues/78#issuecomment-686640101.

[stephen-turner]

@conioh Your tone is not appropriate and I have deleted your comment.

[netpoetica]

At this moment, I am using the (LCOW) experimental feature to run Linux and Windows containers simultaneously.

Is this currently the recommend approach, and is this documented anywhere?

I was hoping that by specifying platform in my docker compose, I would be able to just run both Linux and Windows containers simultaneously. But the Docker Desktop client "Switch to..." option right now I think blocks running one or the other

[stephen-turner]

At this moment, I am using the (LCOW) experimental feature to run Linux and Windows containers simultaneously.

Is this currently the recommend approach, and is this documented anywhere?

I was hoping that by specifying platform in my docker compose, I would be able to just run both Linux and Windows containers simultaneously. But the Docker Desktop client "Switch to..." option right now I think blocks running one or the other

Unfortunately LCOW has now been deprecated. It never reached the level of quality where we were happy to mark it as non-experimental, and in the end we dropped it.

There isn't a good solution for running Linux and Windows containers simultaneously right now, which is why this ticket is on the roadmap.

[silverl]

Hi, @stephen-turner. I looked on the roadmap but I don't see this ticket on the board.

If a GitHub Issue remains open (as opposed to WONTFIX or closed), does that imply it's "on the roadmap" but not actively under research or investigation? I.e. The idea hasn't been dismissed, but there are no immediate plans to tackle it.

[stephen-turner]

Correct, we're aware of the demand but we're not currently working on it.

[Scherlac]

@netpoetica In my experience in case we start the Windows container and than switch to Linux we can run both at the same time. I mean I have a Cosmos DB running parallel with two Linux hosted DevOps agent ( and a StackEditor image :) ) (Windows 1909, WSL2, Docker Desktop). For me it is just inconvenient to switch. The main issue for me is VPN, that prevents network traffic on Windows containers. Linux network traffic is fine, vpnkit does a fine job here.

[aL3891]

i came across this while looking for ways to run build and run a mixed container solution as we need to use windows containers for some legacy services, but also use Linux to run things like redis. I'm a bit surprised this issue hasn't been able to receive more priority since it seems like a very core scenario

I did however find a workaround for atleast being able to build windows and Linux containers on the same machine in a non interactive fashion. There is a seemingly undocumented way to switch between Linux and windows containers from the command line detailed here and here

Basically you do this before building your windows container & $Env:ProgramFiles\Docker\Docker\DockerCli.exe -SwitchWindowsEngine (or "%ProgramFiles%\Docker\Docker\DockerCli.exe" -SwitchWindowsEngine in a cmd file)

and then before building the linux containers & $Env:ProgramFiles\Docker\Docker\DockerCli.exe -SwitchLinuxEngine

There are downsides to this approach, Docker desktop must be installed and i'm not sure what the situation is there when running on windows server. Also, switching engine is a global operation so build operations on a build agent must be coordinated so different builds doesn't disrupt each other. I also don't think this solves the issue with actually running containers and having them talk to each other, let alone run with docker compose or kubernetes

Atleast with this approach you don't have to go right clicking into some menu to switch. i don't quite understand why both the linux and windows context can be available at the same time, even if its not displayed in the gui, it would still allow scripts to use the different context

[travis-icorein]

Basically you do this before building your windows container & $Env:ProgramFiles\Docker\Docker\DockerCli.exe -SwitchWindowsEngine (or "%ProgramFiles%\Docker\Docker\DockerCli.exe" -SwitchWindowsEngine in a cmd file)

and then before building the linux containers & $Env:ProgramFiles\Docker\Docker\DockerCli.exe -SwitchLinuxEngine

There are downsides to this approach, Docker desktop must be installed and i'm not sure what the situation is there when running on windows server. Also, switching engine is a global operation so build operations on a build agent must be coordinated so different builds doesn't disrupt each other. I also don't think this solves the issue with actually running containers and having them talk to each other, let alone run with docker compose or kubernetes

Correct, upon executing & $Env:ProgramFiles\Docker\Docker\DockerCli.exe -SwitchLinuxEngine anything that existed in the SwitchWindowsEngine environment is no longer visible to the docker system. Running docker container ls -a won't show you containers running in the other environment. Neither can they communicate (eg: you can't create a network that will be seen by both, and not just merely be two different networks with the same name).

i don't quite understand why both the linux and windows context can be available at the same time, even if its not displayed in the gui, it would still allow scripts to use the different context

Agreed, this has been an incredible headache to chase down... all to find out that (despite older claims to the contrary) it doesn't work :-(

...all to try and get a consistent dev environment that works with the CosmosDb Emulator.

[bplasmeijer]

Any update @stephen-turner? Can we expect next steps, or do I need to take an other road?

[stephen-turner]

@bplasmeijer My comment of 8 Jun is still the current situation.

[bplasmeijer]

@bplasmeijer My comment of 8 Jun is still the current situation.

How can we get some movement on this request, containerd does support Linux, and Windows containers at the moment. See also the following thread, and answers, https://twitter.com/Aspenwilder/status/1428432777876107266?s=19

[slonopotamus]

How can we get some movement on this request

You can go and add code that would use containerd functionality to http://github.com/moby/moby

However, twitter post that you've linked doesn't say anything about LCOW.

[TBBle]

The current working assumption I have is that the only way forward for LCOW in Docker is leveraging the LCOW support in containerd, which I assume was the relevance of that Twitter thread which briefly touched upon the Docker/containerd integration work on Windows.

[maikschulze]

Hi,

I've made a quick experiment with Docker contexts and am a surprised that this works. As I'm not very familiar with Docker, I would appreciate if someone could shed light on how this works and what the implications, i.e. limitations or known issues, are, as I have only quickly tested this. I would hope this helps others as well.

I'm running a Windows 10 Professional 20H2 (build 19042) host system with Docker Desktop 3.6.0 installed. Everything was set up to run Linux containers through WSL2 in Linux mode and run Windows containers in isolation mode by setting the Windows mode JSON config "exec-opts": [ "isolation=process" ].

After executing side-by-side containers successfully in Windows mode through docker --platform=linux run, I've encountered the issue https://github.com/docker/for-win/issues/10813 which is a sales stopper for me.

I've then stumbled upon this article: https://poweruser.blog/docker-on-windows-10-without-hyper-v-a529897ed1cc which made me aware of the existence of contexts.

On my Windows host, I've created two contexts pointing to endpoints of the managed ones when using $env:ProgramFiles\Docker\docker\DockerCli.exe -SwitchLinuxEngine or $env:ProgramFiles\Docker\docker\DockerCli.exe -SwitchWindowsEngine:

docker context create windows --description "Windows containers" --default-stack-orchestrator=swarm --docker "host=npipe:////./pipe/dockerDesktopWindowsEngine"

docker context create linux --description "Linux containers" --default-stack-orchestrator=swarm --docker "host=npipe:////./pipe/dockerDesktopLinuxEngine"

These contexts persist over switching the engine. I've then started containers in two Powershell instances and keep them running simultaneously. At first glimpse, I can see no issues:

Instance 1

PS C:\Windows\System32\WindowsPowerShell\v1.0> docker --context linux run --rm -it ubuntu bash
root@277d141d07ca:/# cat /etc/os-release
NAME="Ubuntu"
VERSION="20.04.3 LTS (Focal Fossa)"
ID=ubuntu
ID_LIKE=debian
PRETTY_NAME="Ubuntu 20.04.3 LTS"
VERSION_ID="20.04"
HOME_URL="https://www.ubuntu.com/"
SUPPORT_URL="https://help.ubuntu.com/"
BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/"
PRIVACY_POLICY_URL="https://www.ubuntu.com/legal/terms-and-policies/privacy-policy"
VERSION_CODENAME=focal
UBUNTU_CODENAME=focal
root@277d141d07ca:/# exit
exit
PS C:\Windows\System32\WindowsPowerShell\v1.0> $LASTEXITCODE
0
PS C:\Windows\System32\WindowsPowerShell\v1.0>

Instance 2

PS C:\Windows\System32\WindowsPowerShell\v1.0> docker --context windows run --rm -it mcr.microsoft.com/windows/servercore:20H2-amd64 powershell
Windows PowerShell
Copyright (C) Microsoft Corporation. All rights reserved.

Try the new cross-platform PowerShell https://aka.ms/pscore6

PS C:\> [System.Environment]::OSVersion.Version

Major  Minor  Build  Revision
-----  -----  -----  --------
10     0      19042  0

PS C:\> exit
PS C:\Windows\System32\WindowsPowerShell\v1.0> $LASTEXITCODE
0
PS C:\Windows\System32\WindowsPowerShell\v1.0>

Context-specific commands such as docker --context linux container ls

appear to work. It seems, this is a viable solution to run WSL2 and Windows isolation containers side-by-side. Am I missing something?

Best regards Maik

[slonopotamus]

Am I missing something?

Can these containers talk over network to each other?

[maikschulze]

Can these containers talk over network to each other?

Yes, that seems to work. I have started Python web servers in the Linux and Windows containers and exposed their ports. The containers can connect to the other container's server and are reachable through localhost from the host. I cannot find any difference in the behavior in comparison to using the actual "Switch to Linux/Windows containers" in Docker Desktop. What also worked was elevating rights through --cap-add=NET_ADMIN for the Linux container.

I have also tested volumes and mounts successfully.

The behavior was identical in both Linux and Windows mode. I'm unsure what the switch actually serves apart from setting the default docker context, e.g. docker context use <context>, and some GUI setting in Docker Desktop.

For completeness, you can avoid the explicit creation of the contexts and use the environment variable DOCKER_HOST to point to npipe and get the same result, see https://docs.docker.com/engine/reference/commandline/cli/#environment-variables

[ohault]

Will the switching setting in Docker Desktop for Windows be removed soon in a future release (5.0)?

[tomatac]

Is running a mix of Windows and Linux containers from a docker-compose on a Widows host stable/supported?

[christophermclellan]

Hi folks, just to reiterate @stephen-turner's comments from 20-August 2021 and 08-June 2021, this is not something that we are working on atm or currently have planned in on our roadmap.

[abehartbg]

For anyone who runs across this @maikschulze solution will probably work for most use cases. Only thing I've noticed is that both Linux and Windows need to be 'switched to' at least once to have the corresponding file handles available. I do this with this command & $env:ProgramFiles\Docker\docker\DockerCli.exe -SwitchLinuxEngine

[maikschulze]

Great to hear this is working for you @abehartbg . I've made a small startup script sequence where I switch between the two engines and wait a few seconds in between. Ever since, I've been using this approach successfully in a CI production environment. In Gitlab you can configure this setup easily:

[[runners]]
  name = "<LINUX-NAME>"
  executor = "docker"
  ..
  [runners.docker]
    host = "npipe:////./pipe/docker_engine_linux"
    ..

[[runners]]
  name = "<WINDOWS-NAME>"
  executor = "docker-windows"
  ..
  [runners.docker]
    host = "npipe:////./pipe/docker_engine_windows"
    ..

[maikschulze]

Hi,

I have one additional piece of advise if you use the simultaneous approach based on $env:DOCKER_HOST. Please, make sure to operate in 'Linux container' mode when using volumes. You cannot mount Windows paths to Linux containers if you are Windows mode, regardless of the DOCKER_HOST value you set.

What works in Linux mode:

$env:DOCKER_HOST="npipe:////./pipe/docker_engine"
docker run --rm -it -v c/:/windows_mount alpine ls /windows_mount

$env:DOCKER_HOST="npipe:////./pipe/dockerDesktopLinuxEngine"
docker run --rm -it -v c/:/windows_mount alpine ls /windows_mount

$env:DOCKER_HOST="npipe:////./pipe/dockerDesktopWindowsEngine"
docker run --rm -it -v c:/:c:/windows_mount mcr.microsoft.com/windows/servercore:20H2-amd64 powershell -c ls c:/windows_mount

$env:DOCKER_HOST="npipe:////./pipe/docker_engine_windows"
docker run --rm -it -v c:/:c:/windows_mount mcr.microsoft.com/windows/servercore:20H2-amd64 powershell -c ls c:/windows_mount

What does not work in Linux mode:

$env:DOCKER_HOST="npipe:////./pipe/docker_engine_linux"
docker run --rm -it -v c/:/windows_mount alpine ls /windows_mount

I tested this with Docker Desktop 4.6.1 on Windows 10 20H2 and with Docker Desktop 4.6.1 on Windows 11 22H2 (with servercore:ltsc2022 images)