Dockerfile: `USER ContainerUser` results in "failure in a Windows system call: The user name or password is incorrect. (0x52e)"

[SetTrend]

Describe the bug (and Steps To Reproduce)

Building the following simple Dockerfile:

# escape=`
FROM mcr.microsoft.com/dotnet/framework/sdk:4.8

ARG RepositoryPath
ENV RepositoryPath=${RepositoryPath:-"C:\Repo"}

VOLUME $RepositoryPath
USER ContainerUser

… using:

PS C:\> docker build --rm --no-cache -m 2GB -t test:latest .

… and running the created image like this:

PS C:\> docker run --rm -it test:latest

… results in:

docker: Error response from daemon: container 46a5305c0e305a9b5e7ef5fd746478ea9211b61d136fc7a08b8e4468939514a7 encountered an error during hcs::System::CreateProcess: c:\windows\system32\cmd.exe: failure in a Windows system call: The user name or password is incorrect. (0x52e)
[Event Detail:  Provider: 00000000-0000-0000-0000-000000000000].

Expected behavior

Everything should work flawlessly.

Configuration:

```powershell PS C:\> [Environment]::OSVersion Platform ServicePack Version VersionString -------- ----------- ------- ------------- Win32NT 10.0.19045.0 Microsoft Windows NT 10.0.19045.0 PS C:\> docker version Client: Cloud integration: v1.0.35+desktop.13 Version: 26.1.1 API version: 1.45 Go version: go1.21.9 Git commit: 4cf5afa Built: Tue Apr 30 11:48:43 2024 OS/Arch: windows/amd64 Context: default Server: Docker Desktop 4.30.0 (149282) Engine: Version: 26.1.1 API version: 1.45 (minimum version 1.24) Go version: go1.21.9 Git commit: ac2de55 Built: Tue Apr 30 11:47:32 2024 OS/Arch: windows/amd64 Experimental: false PS C:\> docker info Client: Version: 26.1.1 Context: default Debug Mode: false Plugins: buildx: Docker Buildx (Docker Inc.) Version: v0.14.0-desktop.1 Path: C:\Program Files\Docker\cli-plugins\docker-buildx.exe compose: Docker Compose (Docker Inc.) Version: v2.27.0-desktop.2 Path: C:\Program Files\Docker\cli-plugins\docker-compose.exe debug: Get a shell into any image or container (Docker Inc.) Version: 0.0.29 Path: C:\Program Files\Docker\cli-plugins\docker-debug.exe dev: Docker Dev Environments (Docker Inc.) Version: v0.1.2 Path: C:\Program Files\Docker\cli-plugins\docker-dev.exe extension: Manages Docker extensions (Docker Inc.) Version: v0.2.23 Path: C:\Program Files\Docker\cli-plugins\docker-extension.exe feedback: Provide feedback, right in your terminal! (Docker Inc.) Version: v1.0.4 Path: C:\Program Files\Docker\cli-plugins\docker-feedback.exe init: Creates Docker-related starter files for your project (Docker Inc.) Version: v1.1.0 Path: C:\Program Files\Docker\cli-plugins\docker-init.exe sbom: View the packaged-based Software Bill Of Materials (SBOM) for an image (Anchore Inc.) Version: 0.6.0 Path: C:\Program Files\Docker\cli-plugins\docker-sbom.exe scout: Docker Scout (Docker Inc.) Version: v1.8.0 Path: C:\Program Files\Docker\cli-plugins\docker-scout.exe Server: Containers: 0 Running: 0 Paused: 0 Stopped: 0 Images: 19 Server Version: 26.1.1 Storage Driver: windowsfilter Windows: Logging Driver: json-file Plugins: Volume: local Network: ics internal l2bridge l2tunnel nat null overlay private transparent Log: awslogs etwlogs fluentd gcplogs gelf json-file local splunk syslog Swarm: inactive Default Isolation: hyperv Kernel Version: 10.0 19045 (19041.1.amd64fre.vb_release.191206-1406) Operating System: Microsoft Windows Version 22H2 (OS Build 19045.4412) OSType: windows Architecture: x86_64 CPUs: 4 Total Memory: 12GiB Name: *** ID: 67ce01f9-aa05-43fe-96ee-beec2f666dd8 Docker Root Dir: C:\ProgramData\Docker Debug Mode: false Labels: com.docker.desktop.address=npipe://\\.\pipe\docker_cli Experimental: false Insecure Registries: 127.0.0.0/8 Live Restore Enabled: false Product License: Community Engine ```

Additional context

This also doesn't work:

PS C:\> docker run --rm -it --mount 'type=bind,src=D:\Documents\Repos\Docker\DockerBuildTest\,dst=C:\Repo\' 'test:latest'

… results in:

docker: Error response from daemon: hcs::CreateComputeSystem cf0c577360d731d6e09be5c1eec629751c3891eba85353163c0978cc0c293054: The request is not supported.

The only difference is the additional --mount argument.

[SetTrend]

@ntrappe-msft: Hello Nicole, may I raise this issue to your attention? I'm working for a blue-chip corporation running a critical project here and we need the above Windows image to be running smoothly in very short term.

[ntrappe-msft]

Hi, I tried repro'ing your setup but I didn't hit that error. I'm wondering whether it's coming from something else. The image built successfully and I could start up the container with the mounted volume. Are you running this on Windows Server 2022? And could you share the version of Docker you're using?

[SetTrend]

Thanks for taking the time, Nicole.

I already provided the information you requested. It's just being collapsed behind the details link in my original post. You need to click the "► details" link above to expand the information.

I didn't want to distract from the situation by littering my request with technical information, so I collapsed it.

[SetTrend]

@ntrappe-msft: FWIW, this is a screencast, depicting the issue:

https://github.com/microsoft/Windows-Containers/assets/9283914/e0037f79-4ae6-4180-a379-9d2bb0ddb2fc

NB: Today, a new Docker Desktop version arrived. Same issue … I updated the version information in my original post above to reflect the new Docker Desktop version.

[profnandaa]

The WS2016-based image keeps being picked by default for the 4.8 tag, can you try an explicit tag, either 4.8-windowsservercore-ltsc2022 or 4.8-windowsservercore-ltsc2019?

FROM mcr.microsoft.com/dotnet/framework/sdk:4.8-windowsservercore-ltsc2022

[SetTrend]

@profnandaa. Thank you for this valuable suggestion!

Here are my test results:

Image	docker image build --rm --no-cache -m 2gb -t test:latest .	docker run --rm -it test:latest	docker run --rm -it --mount 'type=bind,src=D:\Documents\Repos\Docker\Create Docker Image,dst=C:\Repo' test:latest
4.8-windowsservercore-ltsc2019	✔️	✔️	docker: Error response from daemon: hcs::CreateComputeSystem 3101d03d38051469f9a0e5394ea2850c05439fa75818c67d06b91ed9429b70ac: The request is not supported.
4.8-windowsservercore-ltsc2022	a Windows version 10.0.20348-based image is incompatible with a 10.0.19045 host	➖	➖

So, the 2019 image supports switching to the ContainerUser context but doesn't support mounts. I cannot test the 2022 image as it's newer than my development VM.

[ntrappe-msft]

Thanks @profnandaa for sharing more information. @SetTrend I'll be slow to respond this week because of Build but I'll attempt to repro again and look into when that error is typically thrown. Thanks for your patience.

[SetTrend]

Any new insights on this issue?

[ntrappe-msft]

Hi! I believe I may know what's going on but I need to trace the Dockerfiles that make up the sdk images. I'll post an update on Monday.

[ntrappe-msft]

@SetTrend Could you try pulling the latest mcr.microsoft.com/dotnet/framework/sdk:4.8-windowsservercore-ltsc2022 image? I was able to repro that error last week but, with the newest image (released today) it works perfectly.

See if you can try:

docker rmi mcr.microsoft.com/dotnet/framework/sdk:4.8-windowsservercore-ltsc2022
docker pull mcr.microsoft.com/dotnet/framework/sdk:4.8-windowsservercore-ltsc2022
docker run -u ContainerUser mcr.microsoft.com/dotnet/framework/sdk:4.8-windowsservercore-ltsc2022 powershell

If that doesn't work, it's likely a configuration issue with your host.

[SetTrend]

Hello, @ntrappe-msft, I tried today. Yet, this image is incompatible with my host:

a Windows version 10.0.20348-based image is incompatible with a 10.0.19045 host

Can you provide an image available for hosts like mine? Otherwise I would be required to request for setting up a whole new VM.

[ntrappe-msft]

@SetTrend Hey, I believe 20348 == Windows 11 and 19045 == Windows 10 so try using mcr.microsoft.com/dotnet/framework/sdk:4.8-windowsservercore-ltsc2019 instead.

[SetTrend]

I tried today. While I can now run as ContainerUser I still cannot bind-mount. (See error description above.)

What is the cause for "The request is not supported."?

[ntrappe-msft]

@SetTrend I couldn't repro that error. Could you try a very simple version of the command to see whether it's some file permissions that may be triggering it? Or if we're having more issues with setting the user in the Dockerfile?

1. For example, I just created a 'fake' folder under the C drive with a single .txt file:

PS C:\fake> dir

            helloworld.txt

2. Then I mounted that folder in a .NET SDK 4.8 Server Core LTSC 2022 container:

   docker run --rm -it --mount 'type=bind,src=C:\fake\,dst=C:\repo\' mcr.microsoft.com/dotnet/framework/sdk:4.8-windowsservercore-ltsc2022

3. Finally, I checked the contents of repo/ in the container and saw helloworld.txt.

   C:\> cd repo
   C:\repo> dir
   
        helloworld.txt

If this fails for you, then I'll probably need a crash dump.

[SetTrend]

Hello, @ntrappe-msft,

Pardon me for my late response.

I tried your suggestion. While it works for running a container from the original mcr.microsoft.com/dotnet/framework/sdk:4.8-windowsservercore-ltsc2019 image, it doesn't work for running a container from the derived image, though.

[ntrappe-msft]

@SetTrend Hmm that seems odd. I'll try to repro it with a derived image too.

[SetTrend]

Any news, @ntrappe-msft?

[SetTrend]

Any news, @ntrappe-msft?

[SetTrend]

Two months ago, my client refrained from using Docker for building their .NET Framework projects, as we didn't get a feasible, working solution from you.

I guess, no one in real life can be expected to wait for months to expect a future running solution.

So, this issue has become purely personal, for me to decide whether to use Windows Containers in the future:

Will I live to see this issue fixed? Or do you plan to consider this repository "deprecated" and "obsolete"?