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
      <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/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.