Podman 5.3.0 win-sshproxy.tid: The system cannot find the file specified. (install via scoop) #24557
Comments
|
Calling |
|
It helps when you provide |
|
@l0rd thoughts ? |
|
In my case, yes. My |
|
Edit: Apologies, forgot I had downgraded back to 5.2.5 when I dumped all this information. It is now updated with the info dump from 5.3.0 when I was having this issue. |
Yup. Podman machine runs in the WSL2. |
|
Also might be worth mentioning that my podman setup was installed via |
Great point. And that's my installation method (via scoop) as well. |
|
We were able to reproduce this issue with @jeffmaury. The problem was related to the Can you please provide the output of the command |
|
@l0rd Here you go: |
|
Thank you. No we were not able to reproduce your error then. The problem was a different one related to the SSH config. We will try to reproduce it using scoop. |
|
It looks like if Podman is installed via winget, win-sshproxy works perfectly fine. I suspect this issue is specific to podman installation via scoop. |
|
I'll try installing via |
|
Thank you @johnnykang for checking. And you are right, that should be the problem. The version of gvproxy has been updated in 5.3 but the scoop installer extracts podman.exe, not gvproxy from the installer. @baude any idea who maintains the podman scoop bucket? From git history it looks @niheaven is the last one that have updated it. |
|
@glektarssza @johnnykang out of curiosity: why are you installing via scoop rather than winget? |
|
I've been a long time user of I'm not opposed to changing but it would be a bit of a pain to migrate everything over at this point depending on what is and is not available in the |
|
i do not know who maintains scoop. |
|
I believe it's maintained by the community who uses it via a collection of GitHub repositories under the https://github.com/orgs/ScoopInstaller organization. At least that's what their website (https://scoop.sh) seems to indicate down at the bottom. |
|
Actually, I stand corrected. Their website links specifically to https://github.com/orgs/ScoopInstaller/people as the maintainers. |
|
I can reproduce after having installed Podman through scoop |
johnnykang
changed the title
|
due to the fact that this issue only occurs when Podman is installed via scoop, i would like to close this issue as i don't believe the team is responsible for fixing it. closing. |
|
I opened ScoopInstaller/Main#6327. Hopefully they can figure this out on their end. |
|
Hi all, Scoop uses bundled version of And in my |
Mine output "The system cannot find the path specified." in the startup message. It is not an obvious message, but it warned me that the Docker API stopped working. |
In go 1.23 filepath.EvalSymlink(path) behavior has changed and it returns an error if path is a Windows junction. The new behavior breaks some functionalities (see containers#24557). The GODEBUG option `winsymlink=0` allow to get run `EvalSymlink` with its legacy behavior. Signed-off-by: Mario Loriedo <[email protected]>
|
Since I'm unsure whether other applications utilize |
|
Hi guys! Are there any updates to this topic? I had to instruct our team to not upgrade / downgrade to 5.2.5 Thanks and best regards. |
|
Hi @Laess3r and happy new year 👋 I should open a PR to fix this problem this week and hopefully the fix will land in v5.4.0. Out of curiosity: what's the issue you are facing? I am asking because the original problem (after installing podman using scoop, machines fails to start) should be fixed now and I am wondering if there is another junction-related problem we are not aware of. |
|
@l0rd I have the exact same issue as @Laess3r. Had to instruct the team to use a version lower than 5.3. Maybe there is some environment variable is use as a workaround, that is not persisted? EDIT: I noticed when I install for example podman 5.3.1, I get that hardcoded on top of the PATH: But this is only working in the scope of the powershell session I installed podman with. Informing @niheaven |
In go 1.23 filepath.EvalSymlink(path) behavior has changed and it returns an error if path is a Windows junction. The new behavior breaks some functionalities (see containers#24557). The GODEBUG option `winsymlink=0` allow to get run `EvalSymlink` with its legacy behavior. Signed-off-by: Mario Loriedo <[email protected]>
In go 1.23 filepath.EvalSymlink(path) behavior has changed and it returns an error if path is a Windows junction. The new behavior breaks some functionalities (see containers#24557). The GODEBUG option `winsymlink=0` allow to get run `EvalSymlink` with its legacy behavior. Signed-off-by: Mario Loriedo <[email protected]>
The behavior of function `path/filepath.EvalSymlinks()` has changed in Go v1.23: - https://go-review.googlesource.com/c/go/+/565136 - https://go.dev/doc/go1.23#minor_library_changes - https://tip.golang.org/doc/godebug As a consequences, starting with Podman 5.3.0, when installing on Windows (WSL) using scoop, Podman fails to start because it fails to find helper binaries. Scoop copies Podman binaries in a folder of type Junction and `EvalSymlinks` returns an error. The problem is described in containers#24557. To address this problem we are checking if a path is a `Symlink` before calling `EvalSymlinks` and, if it's not (hardlinks, mount points or canonical files), we are calling `path/filepath.Clean` for consistency. In fact `path/filepath.EvalSymlinks`, after evaluating a symlink target, calls `Clean` too. Signed-off-by: Mario Loriedo <[email protected]>
The behavior of function `path/filepath.EvalSymlinks()` has changed in Go v1.23: - https://go-review.googlesource.com/c/go/+/565136 - https://go.dev/doc/go1.23#minor_library_changes - https://tip.golang.org/doc/godebug As a consequences, starting with Podman 5.3.0, when installing on Windows (WSL) using scoop, Podman fails to start because it fails to find helper binaries. Scoop copies Podman binaries in a folder of type Junction and `EvalSymlinks` returns an error. The problem is described in containers#24557. To address this problem we are checking if a path is a `Symlink` before calling `EvalSymlinks` and, if it's not (hardlinks, mount points or canonical files), we are calling `path/filepath.Clean` for consistency. In fact `path/filepath.EvalSymlinks`, after evaluating a symlink target, calls `Clean` too. Signed-off-by: Mario Loriedo <[email protected]>
The behavior of function `path/filepath.EvalSymlinks()` has changed in Go v1.23: - https://go-review.googlesource.com/c/go/+/565136 - https://go.dev/doc/go1.23#minor_library_changes - https://tip.golang.org/doc/godebug As a consequences, starting with Podman 5.3.0, when installing on Windows (WSL) using scoop, Podman fails to start because it fails to find helper binaries. Scoop copies Podman binaries in a folder of type Junction and `EvalSymlinks` returns an error. The problem is described in containers#24557. To address this problem we are checking if a path is a `Symlink` before calling `EvalSymlinks` and, if it's not (hardlinks, mount points or canonical files), we are calling `path/filepath.Clean` for consistency. In fact `path/filepath.EvalSymlinks`, after evaluating a symlink target, calls `Clean` too. Signed-off-by: Mario Loriedo <[email protected]>
The behavior of function `path/filepath.EvalSymlinks()` has changed in Go v1.23: - https://go-review.googlesource.com/c/go/+/565136 - https://go.dev/doc/go1.23#minor_library_changes - https://tip.golang.org/doc/godebug As a consequences, starting with Podman 5.3.0, when installing on Windows (WSL) using scoop, Podman fails to start because it fails to find helper binaries. Scoop copies Podman binaries in a folder of type Junction and `EvalSymlinks` returns an error. The problem is described in containers#24557. To address this problem we are checking if a path is a `Symlink` before calling `EvalSymlinks` and, if it's not (hardlinks, mount points or canonical files), we are calling `path/filepath.Clean` for consistency. In fact `path/filepath.EvalSymlinks`, after evaluating a symlink target, calls `Clean` too. Signed-off-by: Mario Loriedo <[email protected]>
The behavior of function `path/filepath.EvalSymlinks()` has changed in Go v1.23: - https://go-review.googlesource.com/c/go/+/565136 - https://go.dev/doc/go1.23#minor_library_changes - https://tip.golang.org/doc/godebug As a consequences, starting with Podman 5.3.0, when installing on Windows (WSL) using scoop, Podman fails to start because it fails to find helper binaries. Scoop copies Podman binaries in a folder of type Junction and `EvalSymlinks` returns an error. The problem is described in containers#24557. To address this problem we are checking if a path is a `Symlink` before calling `EvalSymlinks` and, if it's not (hardlinks, mount points or canonical files), we are calling `path/filepath.Clean` for consistency. In fact `path/filepath.EvalSymlinks`, after evaluating a symlink target, calls `Clean` too. Signed-off-by: Mario Loriedo <[email protected]>
|
@l0rd with podman 5.3.2 installed via scoop it looked to be working at first but no, at least not with user mode networking.
If PowerShell is not reopened on steps 3 and 4, it works fine. Could this be strictly an issue with scoop? |
|
@disacrol Can you provide the contents of your |
|
Indeed podman dir is not persisted in the path. Plain text to allow bold: PS C:\Users\DOliveira> Write-Host $env:PATH (reopen PS) PS C:\Users\DOliveira> Write-Host $env:PATH |
|
Yeah, it's strange that it's not being persisted to your path... This is definitely something to do with |
|
Scoop adds something to PATH in two steps: 1. it adds it to the current session; 2. it adds it via Environment Variables. Please check if it works after a reboot (to ensure Environment Variables are applied). |
Issue Description
after upgrading to the Podman 5.3.0 (via scoop), when starting the podman machine, there is a message
API forwarding for Docker API clients is not available due to the following startup failures.
The system cannot find the path specified.
it turned out that the c:<user_profile>.local\share\containers\podman\machine\wsl\podman-machine-default\win-sshproxy.tid is not created.
Downgrading to Podman 5.2.5 , the message is gone.
Podman machine runs in WSL2.
Steps to reproduce the issue
As above in the description
Describe the results you received
As above in the description
Describe the results you expected
podman machine starts and API forwarding for Docker API clients on Windows machine works as expected without error message.
podman info output
Podman 5.3.0Podman in a container
No
Privileged Or Rootless
Rootless
Upstream Latest Release
Yes
Additional environment details
Additional environment details
Additional information
Additional information like issue happens only occasionally or issue happens with a particular architecture or on a particular setting
The text was updated successfully, but these errors were encountered: