Repository: containers/podman (Go)

Issue:
Podman 5.3.0 win-sshproxy.tid: The system cannot find the file specified. (install via scoop)
### 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

```yaml
Podman 5.3.0
```

### Podman 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


Discussion:
Calling `podman machine stop` will also produce the following warning/error in this situation:

```
Could not stop API forwarding service (win-sshproxy.exe): open C:\Users\<username>\.local\share\containers\podman\machine\wsl\podman-machine-default\win-sshproxy.tid: The system cannot find the file specified.
```
It helps when you provide `podman info` like the template recommends.  In both cases, is it safe to assume WSL is being used?
@l0rd thoughts ?
In my case, yes. My `podman machine` instance is running inside of WSL.
`podman version` output:

```
Client:       Podman Engine
Version:      5.3.0
API Version:  5.3.0
Go Version:   go1.23.3
Git Commit:   874bf2c301ecf0ba645f1bb45f81966cc755b7da
Built:        Wed Nov 13 06:19:59 2024
OS/Arch:      windows/amd64

Server:       Podman Engine
Version:      5.2.5
API Version:  5.2.5
Go Version:   go1.22.7
Built:        Thu Oct 24 18:00:00 2024
OS/Arch:      linux/amd64
```

`podman info` output:

```
host:
  arch: amd64
  buildahVersion: 1.37.5
  cgroupControllers: []
  cgroupManager: cgroupfs
  cgroupVersion: v1
  conmon:
    package: conmon-2.1.12-2.fc40.x86_64
    path: /usr/bin/conmon
    version: 'conmon version 2.1.12, commit: '
  cpuUtilization:
    idlePercent: 99.64
    systemPercent: 0.25
    userPercent: 0.11
  cpus: 4
  databaseBackend: sqlite
  distribution:
    distribution: fedora
    variant: container
    version: "40"
  eventLogger: journald
  freeLocks: 2048
  hostname: GlekPC
  idMappings:
    gidmap:
    - container_id: 0
      host_id: 1000
      size: 1
    - container_id: 1
      host_id: 524288
      size: 65536
    uidmap:
    - container_id: 0
      host_id: 1000
      size: 1
    - container_id: 1
      host_id: 524288
      size: 65536
  kernel: 5.15.167.4-microsoft-standard-WSL2
  linkmode: dynamic
  logDriver: journald
  memFree: 16078487552
  memTotal: 16776019968
  networkBackend: netavark
  networkBackendInfo:
    backend: netavark
    dns:
      package: aardvark-dns-1.12.2-2.fc40.x86_64
      path: /usr/libexec/podman/aardvark-dns
      version: aardvark-dns 1.12.2
    package: netavark-1.12.2-1.fc40.x86_64
    path: /usr/libexec/podman/netavark
    version: netavark 1.12.2
  ociRuntime:
    name: crun
    package: crun-1.17-1.fc40.x86_64
    path: /usr/bin/crun
    version: |-
      crun version 1.17
      commit: 000fa0d4eeed8938301f3bcf8206405315bc1017
      rundir: /run/user/1000/crun
      spec: 1.0.0
      +SYSTEMD +SELINUX +APPARMOR +CAP +SECCOMP +EBPF +CRIU +LIBKRUN +WASM:wasmedge +YAJL
  os: linux
  pasta:
    executable: /usr/bin/pasta
    package: passt-0^20240906.g6b38f07-1.fc40.x86_64
    version: |
      pasta 0^20240906.g6b38f07-1.fc40.x86_64
      Copyright Red Hat
      GNU General Public License, version 2 or later
        <https://www.gnu.org/licenses/old-licenses/gpl-2.0.html>
      This is free software: you are free to change and redistribute it.
      There is NO WARRANTY, to the extent permitted by law.
  remoteSocket:
    exists: true
    path: /run/user/1000/podman/podman.sock
  rootlessNetworkCmd: pasta
  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: ""
    package: ""
    version: ""
  swapFree: 4294967296
  swapTotal: 4294967296
  uptime: 0h 5m 17.00s
  variant: ""
plugins:
  authorization: null
  log:
  - k8s-file
  - none
  - passthrough
  - journald
  network:
  - bridge
  - macvlan
  - ipvlan
  volume:
  - local
registries:
  search:
  - docker.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: 1081101176832
  graphRootUsed: 914518016
  graphStatus:
    Backing Filesystem: extfs
    Native Overlay Diff: "true"
    Supports d_type: "true"
    Supports shifting: "false"
    Supports volatile: "true"
    Using metacopy: "false"
  imageCopyTmpDir: /var/tmp
  imageStore:
    number: 0
  runRoot: /run/user/1000/containers
  transientStore: false
  volumePath: /home/user/.local/share/containers/storage/volumes
version:
  APIVersion: 5.2.5
  Built: 1729814400
  BuiltTime: Thu Oct 24 18:00:00 2024
  GitCommit: ""
  GoVersion: go1.22.7
  Os: linux
  OsArch: linux/amd64
  Version: 5.2.5
```

`podman machine info` output:

```
host:
    arch: amd64
    currentmachine: podman-machine-default
    defaultmachine: podman-machine-default
    eventsdir: C:\Users\roblo\.local\share\containers\podman\podman
    machineconfigdir: C:\Users\roblo\.config\containers\podman\machine\wsl
    machineimagedir: C:\Users\roblo\.local\share\containers\podman\machine\wsl
    machinestate: Running
    numberofmachines: 1
    os: windows
    vmtype: wsl
version:
    apiversion: 5.3.0
    version: 5.3.0
    goversion: go1.23.3
    gitcommit: 874bf2c301ecf0ba645f1bb45f81966cc755b7da
    builttime: Wed Nov 13 06:19:59 2024
    built: 1731503999
    osarch: windows/amd64
    os: windows
```

`podman machine inspect` output:

```
[
     {
          "ConfigDir": {
               "Path": "C:\\Users\\roblo\\.config\\containers\\podman\\machine\\wsl"
          },
          "ConnectionInfo": {
               "PodmanSocket": null,
               "PodmanPipe": {
                    "Path": "\\\\.\\pipe\\podman-machine-default"
               }
          },
          "Created": "2024-11-13T14:54:20.3775309-07:00",
          "LastUp": "2024-11-13T14:55:18.3645367-07:00",
          "Name": "podman-machine-default",
          "Resources": {
               "CPUs": 16,
               "DiskSize": 100,
               "Memory": 2048,
               "USBs": []
          },
          "SSHConfig": {
               "IdentityPath": "C:\\Users\\roblo\\.local\\share\\containers\\podman\\machine\\machine",
               "Port": 50275,
               "RemoteUsername": "user"
          },
          "State": "running",
          "UserModeNetworking": false,
          "Rootful": false,
          "Rosetta": false
     }
]
```

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.
> It helps when you provide `podman info` like the template recommends. In both cases, is it safe to assume WSL is being used?

Yup. Podman machine runs in the WSL2.
Also might be worth mentioning that my podman setup was installed via `scoop`. Shouldn't impact anything (I think) but you never know.
> Also might be worth mentioning that my podman setup was installed via `scoop`. Shouldn't impact anything (I think) but you never know.

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 `%USERPROFILE%/.ssh/config`. As a workaround we renamed the config file.

Can you please provide the output of the command `podman info --log-level debug`.
@l0rd Here you go:

```
time="2024-11-13T19:30:32-07:00" level=info msg="C:\\Users\\roblo\\scoop\\apps\\podman\\current\\podman.exe filtering at log level debug"
time="2024-11-13T19:30:32-07:00" level=debug msg="Called info.PersistentPreRunE(C:\\Users\\roblo\\scoop\\apps\\podman\\current\\podman.exe info --log-level debug)"
time="2024-11-13T19:30:32-07:00" level=debug msg="SSH Ident Key \"C:\\\\Users\\\\roblo\\\\.local\\\\share\\\\containers\\\\podman\\\\machine\\\\machine\" SHA256:DW4NTzZN7HgVBWBnF8rA6cmGd9LchILrC9GP0vnMU7Q ssh-ed25519"
time="2024-11-13T19:30:32-07:00" level=debug msg="DoRequest Method: GET URI: http://d/v5.3.0/libpod/_ping"
time="2024-11-13T19:30:32-07:00" level=debug msg="DoRequest Method: GET URI: http://d/v5.3.0/libpod/info"
host:
  arch: amd64
  buildahVersion: 1.37.5
  cgroupControllers: []
  cgroupManager: cgroupfs
  cgroupVersion: v1
  conmon:
    package: conmon-2.1.12-2.fc40.x86_64
    path: /usr/bin/conmon
    version: 'conmon version 2.1.12, commit: '
  cpuUtilization:
    idlePercent: 99.47
    systemPercent: 0.35
    userPercent: 0.18
  cpus: 4
  databaseBackend: sqlite
  distribution:
    distribution: fedora
    variant: container
    version: "40"
  eventLogger: journald
  freeLocks: 2048
  hostname: GlekPC
  idMappings:
    gidmap:
    - container_id: 0
      host_id: 1000
      size: 1
    - container_id: 1
      host_id: 524288
      size: 65536
    uidmap:
    - container_id: 0
      host_id: 1000
      size: 1
    - container_id: 1
      host_id: 524288
      size: 65536
  kernel: 5.15.167.4-microsoft-standard-WSL2
  linkmode: dynamic
  logDriver: journald
  memFree: 16092475392
  memTotal: 16776024064
  networkBackend: netavark
  networkBackendInfo:
    backend: netavark
    dns:
      package: aardvark-dns-1.12.2-2.fc40.x86_64
      path: /usr/libexec/podman/aardvark-dns
      version: aardvark-dns 1.12.2
    package: netavark-1.12.2-1.fc40.x86_64
    path: /usr/libexec/podman/netavark
    version: netavark 1.12.2
  ociRuntime:
    name: crun
    package: crun-1.17-1.fc40.x86_64
    path: /usr/bin/crun
    version: |-
      crun version 1.17
      commit: 000fa0d4eeed8938301f3bcf8206405315bc1017
      rundir: /run/user/1000/crun
      spec: 1.0.0
      +SYSTEMD +SELINUX +APPARMOR +CAP +SECCOMP +EBPF +CRIU +LIBKRUN +WASM:wasmedge +YAJL
  os: linux
  pasta:
    executable: /usr/bin/pasta
    package: passt-0^20240906.g6b38f07-1.fc40.x86_64
    version: |
      pasta 0^20240906.g6b38f07-1.fc40.x86_64
      Copyright Red Hat
      GNU General Public License, version 2 or later
        <https://www.gnu.org/licenses/old-licenses/gpl-2.0.html>
      This is free software: you are free to change and redistribute it.
      There is NO WARRANTY, to the extent permitted by law.
  remoteSocket:
    exists: true
    path: /run/user/1000/podman/podman.sock
  rootlessNetworkCmd: pasta
  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: ""
    package: ""
    version: ""
  swapFree: 4294967296
  swapTotal: 4294967296
  uptime: 0h 6m 30.00s
  variant: ""
plugins:
  authorization: null
  log:
  - k8s-file
  - none
  - passthrough
  - journald
  network:
  - bridge
  - macvlan
  - ipvlan
  volume:
  - local
registries:
  search:
  - docker.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: 1081101176832
  graphRootUsed: 961994752
  graphStatus:
    Backing Filesystem: extfs
    Native Overlay Diff: "true"
    Supports d_type: "true"
    Supports shifting: "false"
    Supports volatile: "true"
    Using metacopy: "false"
  imageCopyTmpDir: /var/tmp
  imageStore:
    number: 0
  runRoot: /run/user/1000/containers
  transientStore: false
  volumePath: /home/user/.local/share/containers/storage/volumes
version:
  APIVersion: 5.2.5
  Built: 1729814400
  BuiltTime: Thu Oct 24 18:00:00 2024
  GitCommit: ""
  GoVersion: go1.22.7
  Os: linux
  OsArch: linux/amd64
  Version: 5.2.5

time="2024-11-13T19:30:32-07:00" level=debug msg="Called info.PersistentPostRunE(C:\\Users\\roblo\\scoop\\apps\\podman\\current\\podman.exe info --log-level debug)"
time="2024-11-13T19:30:32-07:00" level=debug msg="Shutting down engines"
```
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 `winget` after work today to confirm this as well. If I cannot reproduce the issue in that environment I think it's a scoop-specific issue, yeah. 
Thank you @johnnykang for checking. And you are right, that should be the problem. 

The version of [gvproxy has been updated](https://github.com/containers/podman/pull/24394) in 5.3 but [the scoop installer](https://github.com/ScoopInstaller/Main/blob/master/bucket/podman.json) 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 `scoop` so mainly because it's an ecosystem I'm familiar with and, at the time I started using it, had the software I was using.

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 `winget` ecosystem. 
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
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 `gvproxy.exe` and `win-sshproxy`, which version comes with `podman` v5.3.0?

And in my `podman` installation, `podman machine start` doesn't output any error, but yes, `podman machine stop` does, even after I replaced existing `gvproxy` and `win-sshproxy` in the `podman` folder with the latest ones (v0.8.0).
> And in my `podman` installation, `podman machine start` doesn't output any error

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. 
Oh yes, same output, really not obvious :)

So which one should `podman` use? I'll try to install podman via winget and put all the files under scoop installed folder and see what will happened.
> Oh yes, same output, really not obvious :)
> 
> So which one should `podman` use? I'll try to install podman via winget and put all the files under scoop installed folder and see what will happened.

Just do scoop uninstall podman and winget install podman.


all configurations should still in effective and ready to use with all your existing containers. 

Try that at your own risk. It worked that that way on my machine ™️
An error occurs when Podman is initiated from a Windows junction folder, as with Scoop's setup (where Podman starts from `podman\current`, a junction to `podman\5.3.0`). However, initiating Podman directly from the actual folder (`podman\5.3.0`) or from other locations like `C:\`, `D:\`, etc., works without issues.

Are there recent commits that change this behavior?
@niheaven, we came to the same conclusion after doing some tests with @jeffmaury today. The workarounds we found **when the provider is Hyper-V**:

- Run Podman from `<scoop-app-dir>\podman\5.3.0` as you mentioned above
- Create a `%APPDATA%\containers\containers.conf` with the `helper_binaries_dir` that points to `<scoop-app-dir>\podman\5.3.0`:
```toml
[engine]
helper_binaries_dir=["<scoop-app-dir>\podman\5.3.0"]
```
- Copy the `*.exe` files in `%PROGRAMFILES%/RedHat/Podman` (however, this requires admin privileges and may not be ideal)

When Podman starts from a junction it [fails to find the `win-sshproxy.exe`](https://github.com/containers/podman/blob/d3e7d4e2175d858d53d9142b0125fd38fc0dd83c/pkg/machine/machine_windows.go#L139) but it doesn't look that anything changed between 5.2 and 5.3 🤷 
> Copy the *.exe files in %PROGRAMFILES%/RedHat/Podman (however, this requires admin privileges and may not be ideal)

Is it necessary? I've noticed that the executables are identical between Winget and Scoop.

> Create a %APPDATA%\containers\containers.conf with the helper_binaries_dir that points to <scoop-app-dir>\podman\5.3.0:

I'll try this and it should be done during Scoop installation.
> Is it necessary? I've noticed that the executables are identical between Winget and Scoop.

No, I don't think that's necessary. If you create the configuration file, you don't need to move the files there. 

> I'll try this and it should be done during Scoop installation.

Right, I think that's the best solution at the moment. We should figure out the root cause of the problem and eventually provide a fix (in Podman), but in the meantime, I think it's better to create the configuration file.
> We should figure out the root cause of the problem and eventually provide a fix (in Podman)

Okay, let's wait for the fix, but for now, a hotfix in Scoop's manifest works quite well.
Another question. If my scoop installation is at `D:\Scoop\apps\podman\5.3.0`, the config entry `helper_binaries_dir=["<scoop-app-dir>\podman\5.3.0"]` should be which format? 

- `helper_binaries_dir=["D:\Scoop\apps\podman\5.3.0"]`
- `helper_binaries_dir=["D:\\Scoop\\apps\\podman\\5.3.0"]`
- `helper_binaries_dir=["D:/Scoop/apps/podman/5.3.0"]`
- Or something else?

Ping @l0rd 
@johnnykang I think scoop is just the messenger here. There was [a change in go 1.23](https://github.com/containers/podman/blob/d3e7d4e2175d858d53d9142b0125fd38fc0dd83c/pkg/machine/machine_windows.go#L254) changing the behavior of `filePath.EvalSymlinks()` that may be related (podman 5.2  still used go 1.22).
> [@niheaven](https://github.com/niheaven), we came to the same conclusion after doing some tests with [@jeffmaury](https://github.com/jeffmaury) today. The workarounds we found:
> 
> * Run Podman from `<scoop-app-dir>\podman\5.3.0` as you mentioned above
> * Create a `%APPDATA%\containers\containers.conf` with the `helper_binaries_dir` that points to `<scoop-app-dir>\podman\5.3.0`:
> 
> [engine]
> helper_binaries_dir=["<scoop-app-dir>\podman\5.3.0"]
> * Copy the `*.exe` files in `%PROGRAMFILES%/RedHat/Podman` (however, this requires admin privileges and may not be ideal)
> 
> When Podman starts from a junction it [fails to find the `win-sshproxy.exe`](https://github.com/containers/podman/blob/d3e7d4e2175d858d53d9142b0125fd38fc0dd83c/pkg/machine/machine_windows.go#L139) but it doesn't look that anything changed between 5.2 and 5.3 🤷


I have a self-maintained scoop bucket, with podman 

<https://github.com/specter119/scoop-dsms/blob/main/bucket/podman.yml>

and tried 2 following solutions, neither works:

- `%APPDATA%\containers\containers.conf` 
- add gvproxy and win-sshproxy to PATH

I have fixed the issue in the official repo (like only extract podman.exe ) and tried the above approaches.

It seems that there are some remaining issues in the podman side, at least a proper config different with previous.


A few more informations.

Indeed after [this change](https://github.com/golang/go/issues/63703) introduced in go v1.23, `filepath.EvalSymlinks(path)` returns an error if `path` is within a [junction ](https://learn.microsoft.com/en-us/sysinternals/downloads/junction) (as in the case of `podman.exe` installed via scoop). The fact that we are not checking if `path` is a symlink before calling `EvalSymlinks` is a bug in Podman.

The good news is that setting the env `$env:GODEBUG="winsymlink=0"` when running Podman is sufficient to make it work as before. So that looks the simplest workaround @niheaven.

Othewise, the workarounds I [have mentioned above](https://github.com/containers/podman/issues/24557#issuecomment-2478100481), and in particular configuring `helper_binaries_dir`, work if the provider is Hyper-V. They don't when it's WSL. And WSL is the default provider and switching from WSL to HyperV can be problematic (a WSL machine cannot be converted to an HyperV machine). Anyway this is the `%APPDATA%\containers\containers.conf` I have tested with.

```ini
[engine]
helper_binaries_dir=["C:\\Users\\<username>\\scoop\\apps\\podman\\5.3.0\\"]

[machine]
provider="hyperv"
```

For WSL, a workaround is to change `PATH` so that `C:\\Users\\<username>\\scoop\\apps\\podman\\5.3.0\\` comes first:

```pwsh
$env:PATH="C:\Users\<username>\scoop\apps\podman\5.3.0\;$env:PATH"
```

but setting `$env:GODEBUG="winsymlink=0"` as mentioned above is probably simpler and works for both WSL and HyperV.
I am re-opening this issue and assigning it to myself. I have a fix [here ](https://github.com/l0rd/podman/commit/36040952e02d3c87ddb2545b5ed6c537208c1b02) ([this](https://github.com/l0rd/podman/commit/4b9dcc1cdb727d26c7e054557552b38da0c407ef) works too) but there are still other uses of `filepath.EvalSymlinks` in Podman codebase that should be reviewed and likely updated.
Since I'm unsure whether other applications utilize `winsymlink` in Go, I implemented a temporary fix for Scoop manifest by adding the versioned directory to the PATH, which seems to be working well.
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](https://github.com/ScoopInstaller/Main/pull/6335) 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.
When I install podman from scoop and start a new podman machine, there is no error.
But if I stop podman machine and re-open the console, the error resurfaces when starting podman machine again.

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:
```
PS C:\> Get-ChildItem Env:Path

Name                           Value
----                           -----
Path                           C:\Users\disacrol\scoop\apps\podman\5.3.1;C:\Program Files\PowerShell\7;C:\Windows\system32;C:\Windows; (...)
```
But this is only working in the scope of the powershell session I installed podman with.

Informing @niheaven 
@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.

1. open PowerShell
2. install podman via scoop
3. close PowerShell
4. open PowerShell
5. create a podman machine with user mode networking (`podman machine init --user-mode-networking`)
6. `podman machine start`
7. error occurs: `Error: could not locate gvproxy.exe, which is necessary for user-mode networking, please reinstall`

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 `$env:PATH` after installing via `scoop` but before reopening PowerShell and then again after reopening PowerShell? That might shed some light on things.
Indeed podman dir is not persisted in the path.
I noticed that scoop persists the path of some apps (e.g. python) but not others (e.g. notepadplusplus). Could this just be a matter of fixing some flag in the podman's scoop manifest or something? Or that https://github.com/ScoopInstaller/Main/pull/6335 was not enough to fix this?

Plain text to allow bold:

PS C:\Users\DOliveira> Write-Host $env:PATH
C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0\;C:\Windows\System32\OpenSSH\;C:\Program Files\dotnet\;C:\Users\DOliveira\scoop\shims;C:\Users\DOliveira\AppData\Local\Microsoft\WindowsApps;C:\Users\DOliveira\AppData\Local\Microsoft\WinGet\Packages\Microsoft.Sysinternals.TCPView_Microsoft.Winget.Source_8wekyb3d8bbwe;C:\Users\DOliveira\AppData\Local\JetBrains\Toolbox\scripts
PS C:\Users\DOliveira> **scoop install podman**
Installing 'podman' (5.3.2) [64bit] from 'main' bucket
Loading podman-5.3.2-setup.exe from cache
Checking hash of podman-5.3.2-setup.exe ... ok.
Running installer script...Adding ~\scoop\apps\podman\5.3.2 to your path.
done.
Installer added '~\scoop\apps\podman\5.3.2' to path. Removing.
Linking ~\scoop\apps\podman\current => ~\scoop\apps\podman\5.3.2
Creating shim for 'podman'.
'podman' (5.3.2) was installed successfully!
PS C:\Users\DOliveira> Write-Host $env:PATH
**C:\Users\DOliveira\scoop\apps\podman\5.3.2**;C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0\;C:\Windows\System32\OpenSSH\;C:\Program Files\dotnet\;C:\Users\DOliveira\scoop\shims;C:\Users\DOliveira\AppData\Local\Microsoft\WindowsApps;C:\Users\DOliveira\AppData\Local\Microsoft\WinGet\Packages\Microsoft.Sysinternals.TCPView_Microsoft.Winget.Source_8wekyb3d8bbwe;C:\Users\DOliveira\AppData\Local\JetBrains\Toolbox\scripts

(reopen PS)

PS C:\Users\DOliveira> Write-Host $env:PATH
C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0\;C:\Windows\System32\OpenSSH\;C:\Program Files\dotnet\;C:\Users\DOliveira\scoop\shims;C:\Users\DOliveira\AppData\Local\Microsoft\WindowsApps;C:\Users\DOliveira\AppData\Local\Microsoft\WinGet\Packages\Microsoft.Sysinternals.TCPView_Microsoft.Winget.Source_8wekyb3d8bbwe;C:\Users\DOliveira\AppData\Local\JetBrains\Toolbox\scripts
Yeah, it's strange that it's not being persisted to your path... This is definitely something to do with `scoop` as I'm seeing the same behaviour on my system too. This is not a `podman` issue, I think. Best to report it to the `scoop` team.
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).
Yes it does - and now that I have setup freshly (with newer podman 5.4.0 btw), it also works after re-opening PowerShell. Maybe there was something odd in my system. Thanks @l0rd and @niheaven for the info!
With 5.4.0 the [fix](https://github.com/ScoopInstaller/Main/pull/6335) provided by @niheaven (the `PATH` update) should not be necessary anymore. I have created a [PR ](https://github.com/ScoopInstaller/Main/pull/6528) to revert it.



Patch:
diff --git a/pkg/machine/machine_windows.go b/pkg/machine/machine_windows.go
index 174980fc298..dd59876ad32 100644
--- a/pkg/machine/machine_windows.go
+++ b/pkg/machine/machine_windows.go
@@ -251,7 +251,7 @@ func FindExecutablePeer(name string) (string, error) {
 		return "", err
 	}
 
-	exe, err = filepath.EvalSymlinks(exe)
+	exe, err = EvalSymlinksOrClean(exe)
 	if err != nil {
 		return "", err
 	}
@@ -259,6 +259,28 @@ func FindExecutablePeer(name string) (string, error) {
 	return filepath.Join(filepath.Dir(exe), name), nil
 }
 
+func EvalSymlinksOrClean(filePath string) (string, error) {
+	fileInfo, err := os.Lstat(filePath)
+	if err != nil {
+		return "", err
+	}
+	if fileInfo.Mode()&fs.ModeSymlink != 0 {
+		// Only call filepath.EvalSymlinks if it is a symlink.
+		// Starting with v1.23, EvalSymlinks returns an error for mount points.
+		// See https://go-review.googlesource.com/c/go/+/565136 for reference.
+		filePath, err = filepath.EvalSymlinks(filePath)
+		if err != nil {
+			return "", err
+		}
+	} else {
+		// Call filepath.Clean when filePath is not a symlink. That's for
+		// consistency with the symlink case (filepath.EvalSymlinks calls
+		// Clean after evaluating filePath).
+		filePath = filepath.Clean(filePath)
+	}
+	return filePath, nil
+}
+
 func GetWinProxyStateDir(name string, vmtype define.VMType) (string, error) {
 	dir, err := env.GetDataDir(vmtype)
 	if err != nil {


Test patch:
diff --git a/pkg/machine/machine_windows_test.go b/pkg/machine/machine_windows_test.go
new file mode 100644
index 00000000000..48f3eafd536
--- /dev/null
+++ b/pkg/machine/machine_windows_test.go
@@ -0,0 +1,116 @@
+//go:build windows
+
+package machine
+
+import (
+	"os"
+	"os/exec"
+	"path/filepath"
+	"testing"
+
+	"github.com/stretchr/testify/assert"
+	"github.com/stretchr/testify/require"
+)
+
+// CreateNewItemWithPowerShell creates a new item using PowerShell.
+// It's an helper to easily create junctions on Windows (as well as other file types).
+// It constructs a PowerShell command to create a new item at the specified path with the given item type.
+// If a target is provided, it includes it in the command.
+//
+// Parameters:
+//   - t: The testing.T instance.
+//   - path: The path where the new item will be created.
+//   - itemType: The type of the item to be created (e.g., "File", "SymbolicLink", "Junction").
+//   - target: The target for the new item, if applicable.
+func CreateNewItemWithPowerShell(t *testing.T, path string, itemType string, target string) {
+	var pwshCmd string
+	pwshCmd = "New-Item -Path " + path + " -ItemType " + itemType
+	if target != "" {
+		pwshCmd += " -Target " + target
+	}
+	cmd := exec.Command("pwsh", "-Command", pwshCmd)
+	cmd.Stdout = os.Stdout
+	cmd.Stderr = os.Stderr
+	err := cmd.Run()
+	require.NoError(t, err)
+}
+
+// TestEvalSymlinksOrClean tests the EvalSymlinksOrClean function.
+// In particular it verifies that EvalSymlinksOrClean behaves as
+// filepath.EvalSymlink before Go 1.23 - with the exception of
+// files under a mount point (juntion) that aren't resolved
+// anymore.
+// The old behavior of filepath.EvalSymlinks can be tested with
+// the directive "//go:debug winsymlink=0" and replacing EvalSymlinksOrClean()
+// with filepath.EvalSymlink().
+func TestEvalSymlinksOrClean(t *testing.T) {
+	// Create a temporary directory to store the normal file
+	normalFileDir := t.TempDir()
+
+	// Create a temporary directory to store the (hard/sym)link files
+	linkFilesDir := t.TempDir()
+
+	// Create a temporary directory where the mount point will be created
+	mountPointDir := t.TempDir()
+
+	// Create a normal file
+	normalFile := filepath.Join(normalFileDir, "testFile")
+	CreateNewItemWithPowerShell(t, normalFile, "File", "")
+
+	// Create a symlink file
+	symlinkFile := filepath.Join(linkFilesDir, "testSymbolicLink")
+	CreateNewItemWithPowerShell(t, symlinkFile, "SymbolicLink", normalFile)
+
+	// Create a hardlink file
+	hardlinkFile := filepath.Join(linkFilesDir, "testHardLink")
+	CreateNewItemWithPowerShell(t, hardlinkFile, "HardLink", normalFile)
+
+	// Create a mount point file
+	mountPoint := filepath.Join(mountPointDir, "testJunction")
+	mountPointFile := filepath.Join(mountPoint, "testFile")
+	CreateNewItemWithPowerShell(t, mountPoint, "Junction", normalFileDir)
+
+	// Replaces the backslashes with forward slashes in the normal file path
+	normalFileWithBadSeparators := filepath.ToSlash(normalFile)
+
+	tests := []struct {
+		name     string
+		filePath string
+		want     string
+	}{
+		{
+			name:     "Normal file",
+			filePath: normalFile,
+			want:     normalFile,
+		},
+		{
+			name:     "File under a mount point (juntion)",
+			filePath: mountPointFile,
+			want:     mountPointFile,
+		},
+		{
+			name:     "Symbolic link",
+			filePath: symlinkFile,
+			want:     normalFile,
+		},
+		{
+			name:     "Hard link",
+			filePath: hardlinkFile,
+			want:     hardlinkFile,
+		},
+		{
+			name:     "Bad separators in path",
+			filePath: normalFileWithBadSeparators,
+			want:     normalFile,
+		},
+	}
+
+	for _, tt := range tests {
+		assert := assert.New(t)
+		t.Run(tt.name, func(t *testing.T) {
+			got, err := EvalSymlinksOrClean(tt.filePath)
+			require.NoError(t, err)
+			assert.Equal(tt.want, got)
+		})
+	}
+}