Latest tag of Portainer does not start the container [Windows]

[sndp24152]

Description

I'm trying to install portainer with the latest tag, but it won't start.
It outputs the following Error:

C:\Program Files\Docker\Docker\resources\bin\docker.exe: Error response from daemon: container df6d9d997f1850cb9ba9ed81b618aa0690288691f0cdb42e59784e30dfa7193a encountered an error during CreateProcess: failure in a Windows system call: The system cannot find the file specified. (0x2) [Event Detail: Provider: 00000000-0000-0000-0000-000000000000] [Event Detail: Provider: 00000000-0000-0000-0000-000000000000] [Event Detail: onecore\vm\compute\management\orchestration\vmhostedcontainer\processmanagement.cpp(173)\vmcomputeagent.exe!00007FF711039D2B: (caller: 00007FF710FEE13A) Exception(4) tid(384) 8007000 The system cannot find the file specified. CallContext:[\Bridge_ProcessMessage\VmHostedContainer_ExecuteProcess] Provider: 00000000-0000-0000-0000-000000000000] extra info: {"CommandLine":"/portainer.exe","WorkingDirectory":"C:\","CreateStdInPipe":true,"CreateStdOutPipe":true,"CreateStdErrPipe":true,"ConsoleSize":[0,0]}.

I already tried older tags, but it results in the same issue.

Steps to reproduce the issue (used commands):

1. docker volume create portainer_data
2. docker run -d -p 8000:8000 -p 9000:9000 --name portainer --restart always -v \\.\pipe\docker_engine:\\.\pipe\docker_engine -v portainer_data:C:\data portainer/portainer

Technical details:
docker info:

Client: Debug Mode: false Plugins: app: Docker Application (Docker Inc., v0.8.0) buildx: Build with BuildKit (Docker Inc., v0.3.1-tp-docker) Server: Containers: 3 Running: 0 Paused: 0 Stopped: 3 Images: 5 Server Version: 19.03.5 Storage Driver: windowsfilter (windows) lcow (linux) Windows: LCOW: 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 logentries splunk syslog Swarm: inactive Default Isolation: hyperv Kernel Version: 10.0 17763 (17763.1.amd64fre.rs5_release.180914-1434) Operating System: Windows 10 Enterprise Version 1809 (OS Build 17763.1039) OSType: windows Architecture: x86_64 CPUs: 8 Total Memory: 15.86GiB Name: N0076W05 ID: BLIV:JR5I:YVS2:MW55:LBLU:QTF5:NTZZ:FT5N:NNQV:TQBB:HD6U:SKTJ Docker Root Dir: C:\ProgramData\Docker Debug Mode: true File Descriptors: -1 Goroutines: 28 System Time: 2020-02-19T09:00:14.9752521+01:00 EventsListeners: 1 Registry: https://index.docker.io/v1/ Labels: Experimental: true Insecure Registries: 127.0.0.0/8 Live Restore Enabled: false Product License: Community Engine

[ghost]

I believe the issue is in your command syntax it should be \\.\pipe not \.\pipe
Try:
docker run -d -p 8000:8000 -p 9000:9000 --name portainer --restart always -v \\.\pipe\docker_engine:\\.\pipe\docker_engine -v portainer_data:C:\data portainer/portainer

[ghost]

The fact that older tags aren't working means that it is very unlikely its an issue with Portainer itself as we have confirmed these as working on windows

[sndp24152]

used the correct syntax.
just failed to copy it correctly.
updated the issue.

[sndp24152]

The fact that older tags aren't working means that it is very unlikely its an issue with Portainer itself as we have confirmed these as working on windows

seems so, but I couldn't find the problem myself until now

[jansssson]

I have the same problem, however older tag still works, to it looks like something with the new image.
This works: portainer/portainer:windows1903-amd64-1.23.0
This does not work: portainer/portainer:windows1903-amd64-1.23.1
Same error as described above...
Using docker-compose, with the same volume as previously used for 1.23.0 (i.e. "upgrading")

portainer:
image: "portainer/portainer:windows1903-amd64-1.23.1"
container_name: "portainer"
ports:
- "8000:8000"
- "9000:9000"
volumes:
- source: '\.\pipe\docker_engine'
target: '\.\pipe\docker_engine'
type: npipe
- source: 'C:\ProgramData\Portainer'
target: 'C:\data'
type: bind

[rbability]

We have the same issue here, running Docker on Windows Server 2019. I went back to 1.23.0, which starts flawless. I am using exactly the same command line to start the container for 1.23.0 and 1.23.1 and also use a Docker volume to store Portainers data.

[sndp24152]

We have the same issue here, running Docker on Windows Server 2019. I went back to 1.23.0, which starts flawless. I am using exactly the same command line to start the container for 1.23.0 and 1.23.1 and also use a Docker volume to store Portainers data.

1.23.0 also works for me.

[wywywywy]

The portainer.exe is missing from the 1.23.1 Windows image.

[andyfisher100]

Same issue, we had to revert back to using an 1.23.0 which worked without any issues

[deviantony]

Currently investigating the source of the problem.

[ghost]

UPDATE: Regarding the missing Portainer.exe, there was an issue with the CI build process reporting the image build as a success when in fact was failing.

We have isolated the issue to the Libcompose module and amended it. A windows image has since been built and tested. This image is now available as portainer/portainer, make sure to run docker pull portainer/portainer to get this latest image, before trying it to run it again.

@sndp24152 does this new image work for you?

[sndp24152]

I was pleased too early...
I could install it + get into Portainer, but it marks my local instance of Docker as down.
When I try to access it, it shows the following Error:

Failure: Unable to connect to the Docker endpoint

Already tried restarting and reinstalling.

Used:

1. docker volume create portainer_data
2. docker run -d -p 8000:8000 -p 9000:9000 --name portainer --restart always -v \\.\pipe\docker_engine:\\.\pipe\docker_engine -v portainer_data:C:\data portainer/portainer

[ghost]

Ok, could you please comment with the Portainer container logs? They can be different to the error shown in the UI. You can see how to get them via CLI here

[sndp24152]

I can't unfortunately.
Screenshot of my state in Browser (Chrome: Version 78.0.3904.97) attached:

[ncresswell]

Ok, further diagnostics have been undertaken, and i now have a way to get this running using named pipes. Docker run -d -p 8000:8000 -p 9000:9000 --isolation=process --name=portainer --restart always -v \\.\pipe\docker_engine:\\.\pipe\docker_engine -v portainer_data:C:\data portainer/portainer:windows1903-amd64-1.23.1 The just add the endpoint as local, and it works (albeit somewhat unstable.. wouldnt recommend this used in production) For some reason, named pipes on Windows 10 1809 are not able to be connected to from within the portainer container when using the default isolation mode of HyperV. On server 2019, the default isolation mode IS process, which is why we dont see the issue.

[ncresswell]

Further... The go library we used for named pipe support is: https://github.com/microsoft/go-winio And we are using version 0.3.8. Just noticed that version 0.4.8 includes a bug fix that allows the pipe functionality to work inside Hyper-V-isolated Windows containers. Based on this, we will look to release a custom build and image for testing ASAP, and if all good, will include this updated library in future release. Neil Rgds,

[deviantony]

See #3568 for a potential fix.

[ncresswell]

ok @sndp24152 please try this image: portainerci/portainer:fix3568-bump-go-winio-lib-windows1903-amd64

or if you are not using windows kernel 1903, you can use: portainerci/portainer:fix3568-bump-go-winio-lib-windows1803-amd64

[sndp24152]

@ncresswell tried image portainerci/portainer:fix3568-bump-go-winio-lib-windows1803-amd64.
It works! Thank you :)
Running on version "1.24.0-dev" now and can access my Docker instance.