podman-remote binds files as directories on WSL

[pravic]

Issue Description

podman-remote mounts files as directories

Steps to reproduce the issue

Steps to reproduce the issue: after installing podman-remote via https://podman-desktop.io/docs/podman/accessing-podman-from-another-wsl-instance:

$ touch hello.conf
$ podman-remote-static-linux_amd64 run --rm -v ./hello.conf:/etc/hello.conf --entrypoint ls ccfactory/binutils:2.38-x86_64-linux-gnu -a -lah -a /etc/hello.conf
drwxr-xr-x 2 root root 4.0K Oct 31 14:31 .
drwxr-xr-x 1 root root 4.0K Oct 31 16:36 ..

Using the same command on Windows host works fine:

PS D:\> touch hello.conf
PS D:\> podman run --rm -v ./hello.conf:/etc/hello.conf --entrypoint ls ccfactory/binutils:2.38-x86_64-linux-gnu -a -lah -a /etc/hello.conf
-rwxrwxrwx 1 1000 1000 0 Oct 31 16:44 /etc/hello.conf

Describe the results you received

Files are mounted as directories.

Describe the results you expected

Files should be mounted as files.

podman info output

podman info

``` host: arch: amd64 buildahVersion: 1.37.3 cgroupControllers: - cpuset - cpu - cpuacct - blkio - memory - devices - freezer - net_cls - perf_event - net_prio - hugetlb - pids - rdma - misc 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: 98.89 systemPercent: 0.51 userPercent: 0.6 cpus: 16 databaseBackend: sqlite distribution: distribution: fedora variant: container version: "40" eventLogger: journald freeLocks: 2044 hostname: NZXT idMappings: gidmap: null uidmap: null kernel: 5.15.153.1-microsoft-standard-WSL2 linkmode: dynamic logDriver: journald memFree: 31295909888 memTotal: 33621884928 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/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 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/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: false seccompEnabled: true seccompProfilePath: /usr/share/containers/seccomp.json selinuxEnabled: false serviceIsRemote: true slirp4netns: executable: "" package: "" version: "" swapFree: 8589934592 swapTotal: 8589934592 uptime: 3h 42m 30.00s (Approximately 0.12 days) variant: "" plugins: authorization: null log: - k8s-file - none - passthrough - journald network: - bridge - macvlan - ipvlan volume: - local registries: search: - docker.io store: configFile: /usr/share/containers/storage.conf containerStore: number: 1 paused: 0 running: 0 stopped: 1 graphDriverName: overlay graphOptions: overlay.imagestore: /usr/lib/containers/storage overlay.mountopt: nodev,metacopy=on graphRoot: /var/lib/containers/storage graphRootAllocated: 1081101176832 graphRootUsed: 6967193600 graphStatus: Backing Filesystem: extfs Native Overlay Diff: "false" Supports d_type: "true" Supports shifting: "false" Supports volatile: "true" Using metacopy: "true" imageCopyTmpDir: /var/tmp imageStore: number: 26 runRoot: /run/containers/storage transientStore: false volumePath: /var/lib/containers/storage/volumes version: APIVersion: 5.2.3 Built: 1727136000 BuiltTime: Tue Sep 24 03:00:00 2024 GitCommit: "" GoVersion: go1.22.7 Os: linux OsArch: linux/amd64 Version: 5.2.3 ```

Podman in a container

No

Privileged Or Rootless

None

Upstream Latest Release

Yes

Additional environment details

Host: Windows 10 19045 Podman Desktop: 1.13.3 podman-remote: tried both 4.9.1 and 5.2.5 WSL v2 WSL containers: Ubuntu 20.04.6 and Ubuntu 24.04.1

Additional information

Docker Desktop integration with WSL works perfectly - it creates a symlink:

~$ which -a docker
/usr/bin/docker
/bin/docker
~$ file /bin/docker
/bin/docker: symbolic link to /mnt/wsl/docker-desktop/cli-tools/usr/bin/docker
~$ file $(realpath /bin/docker)
/mnt/wsl/docker-desktop/cli-tools/usr/bin/docker: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), statically linked, Go BuildID=2Y0FdiRhvX69Nbh71Jxp/ZSbv0Zt4jUhKoPDqQJ7a/wYMR6xX03w9jCeveOmrw/SX6UTCNibSWpgzlgmcU7, BuildID[xxHash]=877d948d07b03a3f, with debug_info, not stripped

[Luap99]

Does ./hello.conf actually exists on the server side? Mounts must always exists on the server. My understanding is also that we do not create the source dir in podman if it does not exists so I wonder what would create it in that case. Maybe something special in the remote client is doing that.

For windows there is some special code that maps the windows client path to the correct WSL server path automatically but if you use the normal linux podman-remote it cannot do that.

[pravic]

but if you use the normal linux podman-remote it cannot do that.

@Luap99 As I mentioned, I use Ubuntu under WSL.

Does ./hello.conf actually exists on the server side?

By server side you mean what? touch ./hello.conf does create an empty file. I also tried with cp some_existing_file /path/to/conf - no difference: it's still a directory in the container.

[Luap99]

Well the server where podman actual runs not the client side WSL instance

[pravic]

Why would that file exist on the podman machine (if you mean podman-machine-default)? It exists in WSL.

For windows there is some special code that maps the windows client path to the correct WSL server path automatically but if you use the normal linux podman-remote it cannot do that.

So, you are saying that if I mount a file from Windows to a container, then Podman translates that file path into the podman machine (something like c:\file.txt => /mnt/c/file.txt) and then maps it into the container. Right?

And in my case, when I mount a file from a WSL instance to a container, then Podman also translates that file path into the podman machine, however this case works only for directories.

[Luap99]

So, you are saying that if I mount a file from Windows to a container, then Podman translates that file path into the podman machine (something like c:\file.txt => /mnt/c/file.txt) and then maps it into the container. Right?

Correct

And in my case, when I mount a file from a WSL instance to a container, then Podman also translates that file path into the podman machine, however this case works only for directories.

No directory or file should not make a difference for resolving a path. However the thing I am not clear on if the linux remote client resolves the relative path on the client or the on the server relative the the service cwd. I would expect podman to error out if the source does not exists so if it does not find the file on the server side it should error out which I assume should happen here unless you somehow make sure the client side file also exists on the server. I guess something strange is happening here, have you tried specifying the full path not a relative one?

[pravic]

have you tried specifying the full path not a relative one?

I don't really remember. I should have but not 100% sure, so I'll check the next time I install Podman.