Portainer is a GUI mean to make managing Docker easier. By default Docker is managed using mainly CLI tools and while this is all grand it can be a bit much for those who just need quick access for simple purposes.
I recently attempted to setup Portainer on my local Windows 10 Enterprise Edition PC using the basic installation instructions. I opened up PowerShell and ran:
docker volume create portainer_data docker run -d -p 8000:8000 -p 9000:9000 -v /var/run/docker.sock:/var/run/docker.sock -v portainer_data:/data portainer/portainer
And of course that didn’t work. Instead I was shown this error message:
C:\Program Files\Docker\Docker\Resources\bin\docker.exe: Error response from daemon: pull access denied to portainer/portainer, repository does not exist or may required 'docker login': denied: requested access to the resource is denied. See 'C:\Program Files\Docker\Docker\Resources\bin\docker.exe run --help'.
I tried authenticating without issue to Docker using docker login as recommended in above error. I reran the initial command again but received the same error. I decided to try pulling down the portainer image to my local machine without any attempt to run it:
docker pull portainer/portainer
Shouldn’t work right? It did! Now I rerun the initial command but Docker is still telling me it is “Unable to find image ‘portainer/portainer:latest’ locally”. It is at this point that I notice the Note in the installation documentation:
Note: the -v /var/run/docker.sock:/var/run/docker.sock option can be used in Linux environments only.
Oops. Okay, so how do I get Portainer running on Windows? Unfortunately the next instructions are for setting up Portainer on a Windows Docker Host running Windows Containers – but I’m trying to run Linux Containers on a Windows Docker Container. Still, I get a hint:
$ docker volume create portainer_data $ 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
Note in the above the highlighted portion. Here we see that portainer_data has been specified using a Windows rather than *nix path as in our original command. So I swap this Windows path into my original command (forgetting, btw, to change out the -v /var/run/docker.sock…):
docker run -d -p 8000:8000 -p 9000:9000 -v /var/run/docker.sock:/var/run/docker.sock -v C:\ProgramData\Portainer:/data portainer/portainer
Now I’m getting another error…
C:\Program Files\Docker\Docker\Resources\bin\docker.exe: Error response from daemon: Mount denied: The source path "C:/ProgramData/Portainer" doesn't exist and is not known to Docker..."
Some Googling done I stumble upon Issue #2575 on GitHub for the portainer repository. And then Manuel Patrone’s question on the Docker Forums. Based on this my understanding is that the issue is two fold:
- When we use a *nix path when setting up the data location for Portainer it becomes a local path within the Docker VM on Windows (but theoretically fixed this by changing the path to a Windows path above)
- For some reason Docker/Portainer attempt to save the Docker image to C:\ProgramData\Portainer where no such folder exists and Windows isn’t too happy to create one.
So I make one last change to my command:
docker run -d -p 9000:9000 --name portainer --restart always -v /var/run/docker.sock:/var/run/docker.sock -v C:\Portainer:/data portainer/portainer
And it works beautifully. I’m able to launch Portainer, setup my admin password, and begin navigating around the UI. You’ll note in the above that I set the path as C:\Portainer instead of inside C:\ProgramData. This path could be anywhere, but I figured setting it outside of ProgramData might save me some pain in the future (or not).
You may also note that my command is still technically incorrect. According to the Portainer documentation I should have replaced /var/run/docker.sock:/var/run/docker.sock with \\.\pipe\docker_engine:\\.\pipe\docker_engine – since the former only runs on Linux according to the Portainer documentation.
Why is this working? I don’t know. Maybe I’ll go back and rerun it later using the correct path, but it is worth noting that the pipe path used is only available in 1803+ versions of Windows, so if you have something before that you’ll need to (1) upgrade (I would), (2) use the Linux command as I did above, or (3) find some other command that works pre-1803.
I hope this rambling journey helps others who may find themselves running into the same issue.