Podman Remote Client on Windows: Failed {{.Server.Version}} check

[pfazio]

When attempting to use the Remote - Containers extension in a manner similar to "Developing inside a container on a remote Docker host", but using Podman instead of Docker, Remote Explorer does not successfully load the list of running containers.

My Podman CLI remote client successfully accesses a remote Podman host over a tunneled SSH connection; using Podman CLI works locally (on Windows) as if the host were local (e.g., podman ps works).

However, when using VSCode, using Remote Explorer fails to display any containers ("Get started with containers by installing and starting Docker...", with a console error indicating a failure running podman version --format {{.Server.Version}}. I can reproduce that this command fails in a local PowerShell window, but surrounding the final argument with single quotes succeeds:

PS > podman image tree 9ab567a29502
Image ID: 9ab567a29502
Tags:     [mcr.microsoft.com/dotnet/core/sdk:latest]
Size:     720.6MB
Image Layers
├──  ID: 0ced13fcf944 Size: 119.2MB
├──  ID: fccbd9b8189f Size:  17.1MB
├──  ID: fd9f7414107b Size: 17.85MB
├──  ID: 60cc5fb699d2 Size:   150MB
├──  ID: ee552d96de4f Size: 32.89MB
├──  ID: 31a10af7513d Size:   345MB
└──  ID: 60c3a58e851e Size: 38.56MB Top Layer of: [mcr.microsoft.com/dotnet/core/sdk:latest]
PS> podman version --format {{.Server.Version}}
Error: unknown shorthand flag: 'i' in -inputFormat
PS> podman version --format '{{.Server.Version}}'
2.1.1

The example in Docker's docker version documentation includes the quotes, but maybe Docker is more lenient than Podman?

Installing the Remote - Containers extension directly on the (Linux) Podman host works as expected provided that the dockerPath is configured to use podman as per the documentation.

• VSCode Version: 1.50.1
• Local OS Version: Windows 10 1909 with Podman remote client 2.1.1
• Remote OS Version: Fedora 33 with Podman 2.1.1
• Remote Extension/Connection Type: Docker

Steps to Reproduce:

1. Configure podman remote client (installed on PATH) to connect to remote Podman host tunneled over SSH
2. Install Remote - Containers VSCode extension and set "remote.containers.dockerPath": "podman"
3. Attempt to use Remote Explorer - Containers view with Developer Tools console open and see error {message: "Command failed: podman version --format {{.Server.Version}}", stdout: {…}, stderr: {…}, code: 1}

Does this issue occur when you try this locally?: N/A
Does this issue occur when you try this locally and all extensions are disabled?: N/A

[PavelSosin-320]

Without spending time on all client-server overengineering I install podman on WSL Ubuntu 20.04 distro as my default distro and tried to run base dev container locally:
wsl -u root -e podman run -dt --pod new:devcontainerfocal mcr.microsoft.com/vscode/devcontainers/base.
Unfortunately I faced some other base dev container and podman incompatibility issue:
C:\Users\Pavel>wsl -u root -e podman run -dt --pod new:devcontainerfocal mcr.microsoft.com/vscode/devcontainers/base
Trying to pull mcr.microsoft.com/vscode/devcontainers/base...
Getting image source signatures
Copying blob 101c41d0463b done
Copying blob e4c3d3e4f7b0 done
Copying blob 8275efcd805f done
Copying blob 8c377cb0a4ca done
Copying blob 2b8a246d7af5 done
Copying config c4a263cbda done
Writing manifest to image destination
Storing signatures
ERRO[0215] error starting some container dependencies
ERRO[0215] "container_linux.go:349: starting container process caused "process_linux.go:297: applying cgroup configuration for process caused \"Process with ID 99241 does not exist.\"": OCI runtime error"
Error: error starting some containers: internal libpod error

C:\Users\Pavel>wsl -u root -e podman pod ls
POD ID NAME STATUS CREATED # OF CONTAINERS INFRA ID
6ad136b4e610 devcontainerfocal Created 16 minutes ago 2 d485e95f3b13
root@MSI:/mnt/c/Users/Pavel# podman pod inspect devcontainerfocal
{
"Id": "6ad136b4e610c1c6eadd392722ca4b6aa3951ec7eba66dd12a3eaae75aa981d5",
"Name": "devcontainerfocal",
"Created": "2020-11-01T16:13:34.6253565+02:00",
"CreateCommand": [
"podman",
"run",
"-dt",
"--pod",
"new:devcontainerfocal",
"mcr.microsoft.com/vscode/devcontainers/base"
],
.................
The main goal of Podman is to build and run containers locally with no need for a server.

[PavelSosin-320]

Podman remote issue: Podman service listens to the wrong socket
Now I have a similar problem with my WSL Podman
sudo podman system service -t 5000
Error: unable to create socket unix:/run/podman/podman.sock: listen unix /run/podman/podman.sock: bind: no such file or directory. /run/podman doesn't exists, only /run/libpod in Podman 2.1.1

[chrmarti]

@pfazio What is the console error? (Single quotes are only needed when run from a shell.)

[pfazio]

@chrmarti, please let me know if/how I can provide more detailed information -- this is my first VSCode-related GitHub issue, but with either "remote.containers.logLevel" set to info or debug, the console error is:

console.ts:137 [Extension Host]% {message: "Command failed: podman version --format {{.Server.Version}}", stdout: {…}, stderr: {…}, code: 1}code: 1message: "Command failed: podman version --format {{.Server.Version}}"stderr: data: (74) [116, 105, 109, 101, 61, 34, 50, 48, 50, 48, 45, 49, 49, 45, 48, 50, 84, 49, 48, 58, 49, 57, 58, 50, 54, 45, 48, 53, 58, 48, 48, 34, 32, 108, 101, 118, 101, 108, 61, 101, 114, 114, 111, 114, 32, 109, 115, 103, 61, 34, 84, 104, 101, 32, 104, 97, 110, 100, 108, 101, 32, 105, 115, 32, 105, 110, 118, 97, 108, 105, 100, 46, 34, 10]type: "Buffer"__proto__: Objectstdout: data: []type: "Buffer"__proto__: Object__proto__: constructor: ƒ Object()hasOwnProperty: ƒ hasOwnProperty()isPrototypeOf: ƒ isPrototypeOf()propertyIsEnumerable: ƒ propertyIsEnumerable()toLocaleString: ƒ toLocaleString()toString: ƒ toString()valueOf: ƒ valueOf()__defineGetter__: ƒ __defineGetter__()__defineSetter__: ƒ __defineSetter__()__lookupGetter__: ƒ __lookupGetter__()__lookupSetter__: ƒ __lookupSetter__()get __proto__: ƒ __proto__()set __proto__: ƒ __proto__()
t.log @ console.ts:70
$logExtensionHostMessage @ remoteConsoleUtil.ts:29
_doInvokeHandler @ rpcProtocol.ts:401
_invokeHandler @ rpcProtocol.ts:332
_receiveRequest @ rpcProtocol.ts:278
_receiveOneMessage @ rpcProtocol.ts:220
(anonymous) @ rpcProtocol.ts:93
fire @ event.ts:535
fire @ ipc.net.ts:407
_receiveMessage @ ipc.net.ts:755
(anonymous) @ ipc.net.ts:630
fire @ event.ts:535
acceptChunk @ ipc.net.ts:224
(anonymous) @ ipc.net.ts:149
t @ ipc.net.ts:892
emit @ events.js:223
addChunk @ _stream_readable.js:309
readableAddChunk @ _stream_readable.js:290
Readable.push @ _stream_readable.js:224
onStreamRead @ internal/stream_base_commons.js:181

@PavelSosin-320, unfortunately my behavior differs from what you see when running Podman under WSL; without WSL, I can run all three commands from your post #3929 (comment) with apparent success.

For further context on the use case, I am following the approach described in Red Hat's blog here: https://www.redhat.com/sysadmin/podman-clients-macos-windows.

[PavelSosin-320]

Indeed, I can do it now too with no problem. Maybe podman version issue or how Ubuntu 20.04 distro starts in WSL. But starting podman service is still impossible. I think 4 days is not enough to get podman.sock correction.
Anyway, I don't intend to use podman as a runtime for containers. This is development and testing tool.
I created a simple example which generates dev-container Kube application to run on Kubernetes like K3e:

Generation of Kubernetes YAML is still under development!

Save the output of this file and use kubectl create -f to import

it into Kubernetes.

Created with podman-2.1.1

From

sudo podman run -dt --pod new:devcontainerfocal mcr.microsoft.com/vscode/devcontainers/base

sudo podman create -dt --pod devcontainerfocal docker.io/python:latest

apiVersion: v1
kind: Pod
metadata:
creationTimestamp: "2020-11-02T09:37:23Z"
labels:
app: devcontainerfocal
name: devcontainerfocal
spec:
containers:

• command:
  • bash
    env:
  • name: PATH
    value: /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
  • name: TERM
    value: xterm
  • name: container
    value: podman
  • name: containers
    value: podman
  • name: HOSTNAME
    value: devcontainerfocal
    image: mcr.microsoft.com/vscode/devcontainers/base:latest
    name: stoicsatoshi
    resources: {}
    .................................

[chrmarti]

@pfazio Could you also check the Dev Container log? (F1 > Remote-Containers: Show Log) That should have the decoded error message. (The quotes shouldn't be needed as we don't use a shell to launch podman.)

[pfazio]

@chrmarti For some reason I'm not generating an actual Dev Container log file (a separate console error ENOENT: no such file or directory, open 'c:\Users\USERNAME\AppData\Roaming\Code\logs\20201102T183422\exthost1\ms-vscode-remote.remote-containers\remoteContainers-2020-11-02T23:51:17.255Z.log), but I decoded the bytes from the console error:
time="2020-11-02T18:43:29-05:00" level=error msg="The handle is invalid."

[chrmarti]

Not sure if and how we trigger that error message.

F1 > Remote-Containers: Show Log should still show the current log (the log file issue is fixed in the latest version of the extension available for VS Code Insiders and the upcoming VS Code 1.51).

[PavelSosin-320]

OK, I reached the fully functional "Remote Podman" on WSL Ubuntu 20.04 distro, the only ditro supporting systemd via workarround but I don't think that this scenario is valid. Unlike Docker engine that is server by design and

1. Can be configured to listen any host and port adding the single line to daemon.json file or --host option to dockerd command
2. Has all security options built-in including latest TLS, certified by security agences and without any additional components
3. Provides all automatic generation of all security stuff on the client side like Docker Desktop does it on installation and restart

Podman is not a server. It is a toolbox for creation Cloud applications running on Kubernetes. This is Pod man, i.e tool for kick-start creation debugging and testing Kubernetes applications and services without spending mony on maintanence of Kubernetes infrastructure. It provides single pod player which can be run remotely and locally.
It also fulfill old Cloud developers request for tool for debugging, correction and testing Cloud applications without full Cloud infra and passing Kubernetes-hero certification test " How to debug running mission-critical Cloud enterprise or global application without taking service down or compromise user's security" . It can be done on Linux machine or Windows with WSL.
All this is not relevant for Docker dev-container because it is not a Pod or Kubernetes application or Cloud service.

[PavelSosin-320]

@chrmarti I just tested the same scenario using CLI in my Podman-on-WSL landscape, without security, of corse and it works perfectly. It is possible to test it after Installation of Podman or Micro8k8s in Ubuntu distro and Podman Windows remote CLI for Windows after few simple steps:
On the Ubuntu side: sudo podman system service -t 0 tcp:0.0.0.0:2566
On the Windows CMD: podman --remote --url tcp://127.0.0.1:2566 version
Works as expected.
SSH and other complexity can be excluded from testing.

[MehrdadKhnzd]

I have the same problem and the same error. Any updates on this?
@pfazio

[chrmarti]

@MehrdadKhnzd Could you check the Dev Container log and post it here? (F1 > Remote-Containers: Show Log)

[MehrdadKhnzd]

@chrmarti Here your are:

[2021-01-04T11:26:39.299Z] [PID 3268] [298 ms] Remote-Containers 0.154.1 in VS Code 1.52.1 (ea3859d4ba2f3e577a159bc91e3074c5d85c0523).
[2021-01-04T11:26:39.894Z] [PID 3268] [893 ms] Start: Run: C:\Program Files (x86)\RedHat\Podman\podman.exe version --format {{.Server.APIVersion}}
[2021-01-04T11:26:40.386Z] [PID 3268] [1385 ms] Start: Run: git rev-parse --abbrev-ref --symbolic-full-name @{u}
[2021-01-04T11:26:41.078Z] [PID 3268] [2077 ms] time="2021-01-04T14:56:41+03:30" level=error msg="The handle is invalid."

I don't understand the problem. I can exactly run that command in my terminal, which works perfectly. Also, the term "The handle is invalid." seems to be a windows error, as I found lots of links for this error in various parts of Windows.

I hope it helps!

[chrmarti]

@MehrdadKhnzd Have you tried running the git command (line 3)?

[MehrdadKhnzd]

@chrmarti Yes, as it's not a git folder, it gives this error:

fatal: not a git repository (or any of the parent directories): .git

But it doesn't seem to be about that. Actually, it was the first time that it showed up in the third line, it's always on the second line, and if I repeat "Reopen in Container" after error, you only see the error for Podman.

[160 ms] Remote-Containers 0.154.1 in VS Code 1.52.1 (ea3859d4ba2f3e577a159bc91e3074c5d85c0523).
[728 ms] Start: Run: git rev-parse --abbrev-ref --symbolic-full-name @{u}
[946 ms] Start: Run: C:\Program Files (x86)\RedHat\Podman\podman.exe version --format {{.Server.APIVersion}}
[1397 ms] time="2021-01-04T17:46:49+03:30" level=error msg="The handle is invalid."

[17954 ms] Start: Run: C:\Program Files (x86)\RedHat\Podman\podman.exe version --format {{.Server.APIVersion}}
[18061 ms] time="2021-01-04T17:47:06+03:30" level=error msg="The handle is invalid."

[116128 ms] Start: Run: C:\Program Files (x86)\RedHat\Podman\podman.exe version --format {{.Server.APIVersion}}
[116230 ms] time="2021-01-04T17:48:44+03:30" level=error msg="The handle is invalid."

[grahamneville]

I'm also seeing the same issue.

vscode: 1.53.2
remote-containers: v0.158.0
remote-ssh: v0.64.0

Podman 3.0.0 running on a Linux host, vscode running on windows 10. The command runs if I quote {{ .Server.APIVersion }}

[444347 ms] Start: Run: podman version --format {{.Server.APIVersion}}
[444499 ms] Stop (152 ms): Run: podman version --format {{.Server.APIVersion}}
[444499 ms] time="2021-02-22T22:20:53Z" level=error msg="The handle is invalid."


PS C:\Users\graha> podman version --format {{ .Server.APIVersion }}  
Error: unknown shorthand flag: 'i' in -inputFormat
PS C:\Users\graha> podman version --format "{{ .Server.APIVersion }}"
3.0.0

[chrmarti]

The command is run without shell, so the parameters are passed directly and no quoting is required. The problem must be something else.

[github-actions]

This issue has been closed automatically because it needs more information and has not had recent activity. See also our issue reporting guidelines.

Happy Coding!

[fuglede]

I got a bit further by patching all arguments before they read podman. First of all, I noticed that there appears to be a very limited set of values that "remote.containers.dockerPath" can take; if I set it to anything but docker or podman, I get nowhere. So let's leave it at podman for now.

As noted above, how the command is run is crucial; VS Code seems to really want the intermediate shell. So let's give it just that: We'll write a short Python script (and maybe this step can be skipped) which does nothing but take a set of arguments, then run podman in an intermediate shell with those arguments; I'm trying to get it set up with a Windows Podman client talking to a WSL 2 remote instance, so I use @PavelSosin-320's trick to run Podman over TCP:

dockershim.py:

import sys
import subprocess

cmd = "C:\\path\\to\\podman.exe --remote --url tcp://192.168.173.18:2566 "
cmd += ' '.join(sys.argv[1:])
subprocess.call(cmd, shell=True)

Then, on your path (which must not contain podman), add a podman.bat with the following contents:

@echo off
C:\\path\\to\\python.exe C:\\path\\to\\dockershim.py %*

point being that at this point, the command does what it's supposed to:

>podman version --format {{.Server.Version}}
3.2.3

Note that the @echo off is crucial, since otherwise you'll get a > in the output, which will ultimately be parsed as a "redirect to file" that will overwrite your python.exe with random stuff (good times).

At this point, VS Code will relaunch, the Dockerfile pointed to by the devcontainer.json builds as expected, but running the container does ultimately fail:

[5025 ms] Start: Run: podman run --sig-proxy=false -a STDOUT -a STDERR --mount type=bind,source=c:\Users\username\repos\remote-test,target=/workspaces/remote-test,consistency=cached --mount type=volume,src=vscode,dst=/vscode -l vsch.local.folder=c:\Users\username\repos\remote-test -l vsch.quality=stable -l vsch.remote.devPort=0 --entrypoint /bin/sh vsc-remote-test-6ec7854ca7342f374962f8a287d35fa4 -c echo Container started
[5534 ms] time="2021-09-01T16:07:20+02:00" level=error msg="The handle is invalid."

Error: invalid container path "/workspaces/remote-test", must be an absolute pat
h

This will become an actual problem if we just rely on TCP forwarding commands: Mounting will be impossible.

But okay, let's see what else we might run into, so in our Python script, let's just remove the problematic part of the string to see if we can get anywhere:

problematic_string = r"--mount type=bind,source=c:\Users\username\repos\remote-test,target=/workspaces/remote-test,consistency=cached --mount type=volume,src=vscode,dst=/vscode -l vsch.local.folder=c:\Users\username\repos\remote-test -l vsch.quality=stable -l vsch.remote.devPort=0"
cmd = cmd.replace(problematic_string, "")

At this point, a container is actually started!

The next problem one runs into is the following:

[2021-09-01T14:20:02.808Z] Stop (615 ms): Run: podman events --format {{json .}} --filter event=start
[2021-09-01T14:20:02.808Z] time="2021-09-01T16:20:02+02:00" level=error msg="The handle is invalid."

As before, by running the command standalone we can see why:

>podman events --format {{json .}} --filter event=start
Error: `podman.exe events` takes no arguments

So, what do we do about that? Well,

cmd = cmd.replace(" --format {{json .}} --filter event=start", "")

A bit later, we run into this issue:

[2021-09-01T14:31:49.819Z] Stop (539 ms): Run: podman ps -q -a --filter label=vsch.local.folder=c:\Users\username\repos\remote-test --filter label=vsch.quality=stable
[2021-09-01T14:31:49.822Z] [object Object]

Since we removed these labels above, we would have to get the started container through other means. I'll just use a container I happen to know is running and which is based on python:3.7-slim:

if 'ps -q -a' in cmd:
    print('468a584acd20')
else:
    subprocess.call(cmd, shell=True)

Next error is

[2021-09-01T14:44:50.711Z] Stop (623 ms): Run: podman inspect --type container 468a584acd20
[2021-09-01T14:44:50.714Z] SyntaxError: Unexpected end of JSON input

This one is suspicious; the podman inspect command runs fine on the host! We can use the Python script to hardcode the expected JSON response. Doing so, we reach the following:

[2021-09-01T14:58:29.493Z] Start: Run in container: /bin/sh
[2021-09-01T14:58:29.563Z] Start: Run in container: uname -m
[2021-09-01T14:58:29.753Z] Stop (260 ms): Run in container: /bin/sh
[2021-09-01T14:58:29.754Z] Start: Run in container: cat /etc/passwd
[2021-09-01T14:58:29.754Z] Stdin closed!
[2021-09-01T14:58:29.757Z] Shell server terminated (code: 0, signal: null)

Here, as above, the corresponding podman exec (which can be expected by writing cmd from the Python script to file) actually works fine when run standalone; that it doesn't work here probably isn't surprising given how we're sending everything through Python. I suspect that if I wasn't complicated things by including WSL 2 in the mix, it might be possible to simplify this all a bit.

[chrmarti]

Seeing a new report on "handle is invalid" (#5545), has anyone made any progress on this issue?

[max06]

Hello there 👋🏼

Any news on this? I'm trying to build dev-servers for my teammates, this is basically blocking me... would be really good if there's a fix coming soon 😉

[chrmarti]

The 'handle is invalid' error looks like an upstream issue, make sure you update to the latest version of Podman in case this is fixed there.

If your are using WSL: Remote-Containers 0.195.0 (currently requires VS Code Insiders) has a setting to execute all commands in WSL. That would avoid the Windows-side error:

[max06]

Thank you 👍🏼

Making progress. Now the volume init fails due to using a windows path in wsl:

[7547 ms] Command failed: podman build -f c:\Users\max06\.vscode-insiders\extensions\ms-vscode-remote.remote-containers-0.195.0\scripts\volumeBootstrap.Dockerfile -t vsc-volume-bootstrap c:\Users\max06\.vscode-insiders\extensions\ms-vscode-remote.remote-containers-0.195.0\scripts

[max06]

With the latest podman remote client (3.4.0) on Windows, the original issue seems to be solved. It's no longer complaining about an invalid handle anymore when checking the version, without running the commands in WSL.

Instead, it now has issues setting up an openSSH agent, but that might be an issue on my system. I'll clarify, and open a new issue if my problem persists.

[chinrw]

With the latest podman remote client (3.4.0) on Windows, the original issue seems to be solved. It's no longer complaining about an invalid handle anymore when checking the version, without running the commands in WSL.

Instead, it now has issues setting up an openSSH agent, but that might be an issue on my system. I'll clarify, and open a new issue if my problem persists.

Hi, I have catch the similar issue, do you have any update for this, thanks.

[2021-11-25T17:10:53.472Z] Start: Run: podman version --format {{.Server.APIVersion}}
[2021-11-25T17:10:53.922Z] Stop (450 ms): Run: podman version --format {{.Server.APIVersion}}
[2021-11-25T17:10:53.922Z] Cannot connect to Podman. Please verify your connection to the Linux system using `podman system connection list`, or try `podman machine init` and `podman machine start` to manage a new Linux VM
Error: unable to connect to Podman. failed to create sshClient: dial unix \\.\pipe\openssh-ssh-agent: connect: No connection could be made because the target machine actively refused it.

[2021-11-25T17:14:13.285Z] Start: Run: podman version --format {{.Server.APIVersion}}
[2021-11-25T17:14:13.737Z] Stop (452 ms): Run: podman version --format {{.Server.APIVersion}}
[2021-11-25T17:14:13.738Z] Cannot connect to Podman. Please verify your connection to the Linux system using `podman system connection list`, or try `podman machine init` and `podman machine start` to manage a new Linux VM
Error: unable to connect to Podman. failed to create sshClient: dial unix \\.\pipe\openssh-ssh-agent: connect: No connection could be made because the target machine actively refused it.

The podman works on powershell

PS C:\Users\chinQ> podman version
Client:
Version:      3.4.2
API Version:  3.4.2
Go Version:   go1.16.8
Git Commit:   2ad1fd3555de12de34e20898cc2ef901f08fe5ed
Built:        Sat Nov 13 03:29:50 2021
OS/Arch:      windows/amd64

Server:
Version:      3.4.2
API Version:  3.4.2
Go Version:   go1.16.8
Built:        Sun Nov 14 08:16:48 2021
OS/Arch:      linux/amd64

[artman41]

Hi,

This is still an issue.

Is there any update?

[2022-06-16T00:12:34.348Z] Remote-Containers 0.240.0 in VS Code 1.68.1 (30d9c6cd9483b2cc586687151bcbcd635f373630).
[2022-06-16T00:12:34.348Z] Start: Run: C:\Program Files\RedHat\Podman\podman.exe version --format {{.Server.APIVersion}}
[2022-06-16T00:12:34.650Z] Stop (302 ms): Run: C:\Program Files\RedHat\Podman\podman.exe version --format {{.Server.APIVersion}}
[2022-06-16T00:12:34.651Z] Cannot connect to Podman. Please verify your connection to the Linux system using `podman system connection list`, or try `podman machine init` and `podman machine start` to manage a new Linux VM
Error: unable to connect to Podman. failed to create sshClient: dial unix \\.\pipe\openssh-ssh-agent: connect: No connection could be made because the target machine actively refused it.

PS C:\Users\Tyler> podman system connection list
Name                         URI                                                          Identity                                    Default
podman-machine-default       ssh://user@localhost:54535/run/user/1000/podman/podman.sock  C:\Users\Tyler\.ssh\podman-machine-default  true
podman-machine-default-root  ssh://root@localhost:54535/run/podman/podman.sock            C:\Users\Tyler\.ssh\podman-machine-default  false

PS C:\Users\Tyler> podman info
host:
  arch: amd64
  buildahVersion: 1.26.1
  cgroupControllers: []
  cgroupManager: cgroupfs
  cgroupVersion: v1
  conmon:
    package: conmon-2.1.1-2.fc35.x86_64
    path: /usr/bin/conmon
    version: 'conmon version 2.1.1, commit: '
  cpuUtilization:
    idlePercent: 99.93
    systemPercent: 0.02
    userPercent: 0.06
  cpus: 24
  distribution:
    distribution: fedora
    variant: container
    version: "35"
  eventLogger: file
  hostname: DESKTOP-TQGCI07
  idMappings:
    gidmap:
    - container_id: 0
      host_id: 1000
      size: 1
    - container_id: 1
      host_id: 100000
      size: 65536
    uidmap:
    - container_id: 0
      host_id: 1000
      size: 1
    - container_id: 1
      host_id: 100000
      size: 65536
  kernel: 5.10.102.1-microsoft-standard-WSL2
  linkmode: dynamic
  logDriver: journald
  memFree: 32226406400
  memTotal: 33613570048
  networkBackend: netavark
  ociRuntime:
    name: crun
    package: crun-1.4.5-2.fc35.x86_64
    path: /usr/bin/crun
    version: |-
      crun version 1.4.5
      commit: c381048530aa750495cf502ddb7181f2ded5b400
      spec: 1.0.0
      +SYSTEMD +SELINUX +APPARMOR +CAP +SECCOMP +EBPF +CRIU +YAJL
  os: linux
  remoteSocket:
    exists: true
    path: /run/user/1000/podman/podman.sock
  security:
    apparmorEnabled: false
    capabilities: CAP_CHOWN,CAP_DAC_OVERRIDE,CAP_FOWNER,CAP_FSETID,CAP_KILL,CAP_NET_BIND_SERVICE,CAP_SETFCAP,CAP_SETGID,CAP_SETPCAP,CAP_SETUID,CAP_SYS_CHROOT
    rootless: true
    seccompEnabled: true
    seccompProfilePath: /usr/share/containers/seccomp.json
    selinuxEnabled: false
  serviceIsRemote: true
  slirp4netns:
    executable: /usr/bin/slirp4netns
    package: slirp4netns-1.1.12-2.fc35.x86_64
    version: |-
      slirp4netns version 1.1.12
      commit: 7a104a101aa3278a2152351a082a6df71f57c9a3
      libslirp: 4.6.1
      SLIRP_CONFIG_VERSION_MAX: 3
      libseccomp: 2.5.3
  swapFree: 8589398016
  swapTotal: 8589934592
  uptime: 58m 23.11s
plugins:
  log:
  - k8s-file
  - none
  - passthrough
  - journald
  network:
  - bridge
  - macvlan
  volume:
  - local
registries:
  search:
  - registry.fedoraproject.org
  - registry.access.redhat.com
  - docker.io
  - quay.io
store:
  configFile: /home/user/.config/containers/storage.conf
  containerStore:
    number: 0
    paused: 0
    running: 0
    stopped: 0
  graphDriverName: overlay
  graphOptions: {}
  graphRoot: /home/user/.local/share/containers/storage
  graphRootAllocated: 269490393088
  graphRootUsed: 635428864
  graphStatus:
    Backing Filesystem: extfs
    Native Overlay Diff: "false"
    Supports d_type: "true"
    Using metacopy: "false"
  imageCopyTmpDir: /var/tmp
  imageStore:
    number: 0
  runRoot: /run/user/1000/containers
  volumePath: /home/user/.local/share/containers/storage/volumes
version:
  APIVersion: 4.1.1
  Built: 1655303526
  BuiltTime: Wed Jun 15 15:32:06 2022
  GitCommit: ""
  GoVersion: go1.16.15
  Os: linux
  OsArch: linux/amd64
  Version: 4.1.1

[chrmarti]

What do you get when you set SSH_AUTH_SOCK to \\.\pipe\openssh-ssh-agent in a Windows terminal and then run podman version?

[artman41]

What do you get when you set SSH_AUTH_SOCK to \\.\pipe\openssh-ssh-agent in a Windows terminal and then run podman version?

That looks to break podman entirely @chrmarti

podman version

PS C:\Users\Tyler> $env:SSH_AUTH_SOCK
\\.\pipe\openssh-ssh-agent
PS C:\Users\Tyler> podman version
Cannot connect to Podman. Please verify your connection to the Linux system using `podman system connection list`, or try `podman machine init` and `podman machine start` to manage a new Linux VM
Error: unable to connect to Podman. failed to create sshClient: dial unix \\.\pipe\openssh-ssh-agent: connect: No connection could be made because the target machine actively refused it.

podman ps

PS C:\Users\Tyler> $env:SSH_AUTH_SOCK
\\.\pipe\openssh-ssh-agent
PS C:\Users\Tyler> podman ps
Cannot connect to Podman. Please verify your connection to the Linux system using `podman system connection list`, or try `podman machine init` and `podman machine start` to manage a new Linux VM
Error: unable to connect to Podman. failed to create sshClient: dial unix \\.\pipe\openssh-ssh-agent: connect: No connection could be made because the target machine actively refused it.

podman images

PS C:\Users\Tyler> $env:SSH_AUTH_SOCK
\\.\pipe\openssh-ssh-agent
PS C:\Users\Tyler> podman images
Cannot connect to Podman. Please verify your connection to the Linux system using `podman system connection list`, or try `podman machine init` and `podman machine start` to manage a new Linux VM
Error: unable to connect to Podman. failed to create sshClient: dial unix \\.\pipe\openssh-ssh-agent: connect: No connection could be made because the target machine actively refused it.

podman system connection list still appears to work however

PS C:\Users\Tyler> $env:SSH_AUTH_SOCK
\\.\pipe\openssh-ssh-agent
PS C:\Users\Tyler> podman system connection list
Name                         URI                                                          Identity                                    Default
podman-machine-default       ssh://user@localhost:54535/run/user/1000/podman/podman.sock  C:\Users\Tyler\.ssh\podman-machine-default  true
podman-machine-default-root  ssh://root@localhost:54535/run/podman/podman.sock            C:\Users\Tyler\.ssh\podman-machine-default  false

[KallDrexx]

I seem to be having this issue on windows with Podman 4.2.0. When I attempt to reopen in container I get a dialog that says "Docker Desktop WSL 2 backend required".

Looking at the logs I see:

[1195882 ms] userEnvProbe: loginInteractiveShell (default)
[1195882 ms] userEnvProbe shell: /bin/bash
[1195962 ms] userEnvProbe PATHs:
Probe:     '/home/mshapiro/.cargo/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/usr/lib/wsl/lib:/mnt/c/Program Files (x86)/Microsoft SDKs/Azure/CLI2/wbin:/mnt/c/windows/system32:/mnt/c/windows:/mnt/c/windows/System32/Wbem:/mnt/c/windows/System32/WindowsPowerShell/v1.0/:/mnt/c/windows/System32/OpenSSH/:/mnt/c/Program Files (x86)/GitExtensions/:/mnt/c/Program Files/Git/cmd:/mnt/c/Program Files/nodejs/:/mnt/c/Program Files/PowerShell/7/:/mnt/c/Users/mshapiro/.cargo/bin:/mnt/c/Users/mshapiro/AppData/Local/Microsoft/WindowsApps:/mnt/c/Users/mshapiro/AppData/Local/Programs/Microsoft VS Code/bin:/mnt/c/Users/mshapiro/tools/ffmpeg/bin:/mnt/c/Users/mshapiro/AppData/Local/JetBrains/Toolbox/scripts:/mnt/c/Program Files/CMake/bin:/mnt/c/Users/mshapiro/AppData/Roaming/npm:/mnt/c/Program Files/RedHat/Podman:/snap/bin'
Container: None
[1195993 ms] Host server: Error: spawn podman ENOENT
    at Process.ChildProcess._handle.onexit (node:internal/child_process:282:19)
    at onErrorNT (node:internal/child_process:477:16)
    at processTicksAndRejections (node:internal/process/task_queues:83:21)
[1195994 ms] Start: Run in Host: podman version --format {{.Server.APIVersion}}
[1195994 ms] Host server: (node:28049) PromiseRejectionHandledWarning: Promise rejection was handled asynchronously (rejection id: 1)
(Use `node --trace-warnings ...` to show where the warning was created)
[1196026 ms] Host server: Error: spawn podman ENOENT
    at Process.ChildProcess._handle.onexit (node:internal/child_process:282:19)
    at onErrorNT (node:internal/child_process:477:16)
    at processTicksAndRejections (node:internal/process/task_queues:83:21)
[1196027 ms] spawn podman ENOENT
[1196028 ms] CLI host's PATH: /home/mshapiro/.cargo/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/usr/lib/wsl/lib:/mnt/c/Program Files (x86)/Microsoft SDKs/Azure/CLI2/wbin:/mnt/c/windows/system32:/mnt/c/windows:/mnt/c/windows/System32/Wbem:/mnt/c/windows/System32/WindowsPowerShell/v1.0/:/mnt/c/windows/System32/OpenSSH/:/mnt/c/Program Files (x86)/GitExtensions/:/mnt/c/Program Files/Git/cmd:/mnt/c/Program Files/nodejs/:/mnt/c/Program Files/PowerShell/7/:/mnt/c/Users/mshapiro/.cargo/bin:/mnt/c/Users/mshapiro/AppData/Local/Microsoft/WindowsApps:/mnt/c/Users/mshapiro/AppData/Local/Programs/Microsoft VS Code/bin:/mnt/c/Users/mshapiro/tools/ffmpeg/bin:/mnt/c/Users/mshapiro/AppData/Local/JetBrains/Toolbox/scripts:/mnt/c/Program Files/CMake/bin:/mnt/c/Users/mshapiro/AppData/Roaming/npm:/mnt/c/Program Files/RedHat/Podman:/snap/bin
[1196028 ms] Host server: (node:28049) PromiseRejectionHandledWarning: Promise rejection was handled asynchronously (rejection id: 2)

This is attempting to utilize a podman install that works on windows (not installed inside a wsl2 distro). When attempting to run the podman version --format {{.Server.APIVersion}} command manually in powershell I get

PS C:\Users\mshapiro> podman version --format {{.Server.APIVersion}}
Error: unknown shorthand flag: 'i' in -inputFormat
See 'podman.exe version --help'

Running version without the format shows

PS C:\Users\mshapiro> podman version
Client:       Podman Engine
Version:      4.2.0
API Version:  4.2.0
Go Version:   go1.16.15
Git Commit:   7fe5a419cfd2880df2028ad3d7fd9378a88a04f4
Built:        Thu Aug 11 10:20:57 2022
OS/Arch:      windows/amd64

Server:       Podman Engine
Version:      4.1.1
API Version:  4.1.1
Go Version:   go1.18.4
Built:        Fri Jul 22 15:05:59 2022
OS/Arch:      linux/amd64

It seems that something changed in the format parameter in podman's CLI and vscode is not comaptible with it.

[KallDrexx]

It looks like my previous post is wrong. The error seems to be because "Running on host" really means "running on WSL" even though I have "run commands on WSL" unchecked. So it's trying to run podman on WSL even though I don't have it installed in WSL..

[chrmarti]

Some of the discussed issues appear to be fixed in later versions of Podman. Please open new issues for any remaining problems. Thanks!