podman: Error using `podman cp` on Windows

Is this a BUG REPORT or FEATURE REQUEST? (leave only one on its own line)

/kind bug

Description

I have a fresh install of podman on Windows 10 & WSL2 with a couple of containers installed and running, and I’m getting a strange error message when I try to copy a file into a container using podman cp:

C:\Users\myuser>cd C:\location\of\file\

C:\location\of\file\>podman cp myfile.bak mycontainer:/var/opt/backups
error rewriting "C:\\location\\of\\file\\myfile.bak" to be relative to "/": expected root directory to be an absolute path, got "/"

Additional information you deem important (e.g. issue happens only occasionally):

FWIW I’ll note that I initially attempted this using an MSYS2 shell, but I’m fairly confident that’s not an issue as I’ve also gotten this error through both Command Prompt and Powershell. The above example was pulled from Command Prompt (and then anonymized, of course).

Output of podman version:

Client:       Podman Engine
Version:      4.1.1
API Version:  4.1.1
Go Version:   go1.16.15
Git Commit:   f73d8f8875c2be7cd2049094c29aff90b1150241
Built:        Wed Jun 15 08:17:12 2022
OS/Arch:      windows/amd64

Server:       Podman Engine
Version:      4.1.1
API Version:  4.1.1
Go Version:   go1.16.15
Built:        Wed Jun 15 09:32:06 2022
OS/Arch:      linux/amd64

Output of podman info --debug:

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.65
    systemPercent: 0.13
    userPercent: 0.21
  cpus: 8
  distribution:
    distribution: fedora
    variant: container
    version: "35"
  eventLogger: file
  hostname: pp-907-11538
  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.16.3-microsoft-standard-WSL2
  linkmode: dynamic
  logDriver: journald
  memFree: 21931720704
  memTotal: 26743394304
  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: 7516192768
  swapTotal: 7516192768
  uptime: 2h 47m 23.29s (Approximately 0.08 days)
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: 2
    paused: 0
    running: 2
    stopped: 0
  graphDriverName: overlay
  graphOptions: {}
  graphRoot: /home/user/.local/share/containers/storage
  graphRootAllocated: 269490393088
  graphRootUsed: 3479621632
  graphStatus:
    Backing Filesystem: extfs
    Native Overlay Diff: "false"
    Supports d_type: "true"
    Using metacopy: "false"
  imageCopyTmpDir: /var/tmp
  imageStore:
    number: 2
  runRoot: /run/user/1000/containers
  volumePath: /home/user/.local/share/containers/storage/volumes
version:
  APIVersion: 4.1.1
  Built: 1655303526
  BuiltTime: Wed Jun 15 09:32:06 2022
  GitCommit: ""
  GoVersion: go1.16.15
  Os: linux
  OsArch: linux/amd64
  Version: 4.1.1

Package info (e.g. output of rpm -q podman or apt list podman):

New install via podman-v4.1.1.msi

Have you tested with the latest version of Podman and have you checked the Podman Troubleshooting Guide? (https://github.com/containers/podman/blob/main/troubleshooting.md)

Yes

Additional environment details (AWS, VirtualBox, physical, etc.):

As stated, Windows 10 / WSL 2

About this issue

  • Original URL
  • State: open
  • Created 2 years ago
  • Reactions: 4
  • Comments: 16 (4 by maintainers)

Most upvoted comments

@miguele I believe this will work. wsl -d podman-machine-default -u user enterns podman cp /mnt/c/“your file location” container:/sql/

@n1hility I was able to get a file copy into my container working with the following. I redeployed my podman machine, rebuilt my container… this does work: wsl -d podman-machine-default -u user enterns podman cp /mnt/d/2022_Projects/assessments/HK197500195.bin se92:/root/

@dancohen21 Sorry for the delay on fixing cp, I’ll bump it up higher on my queue. BUT, if there are problems accessing the drive that would be problematic for a fix there to work. if you enter the wsl host using wsl, do you see a /mnt/c but not a /mnt/d ? Does it help if you do a forced shutdown:

podman machine stop
wsl --shutdown
podman machine start

Regarding running direct commands from WSL, you need to use the enterns shell wrapper. This is because running systemd on WSL requires a nested namespace, and while ssh enters you appropriately, wsl still connects you into the outer namespace. There is a profile script that runs and auto-enters you, but this is bypassed by direct commands.

Here is some examples:

Rootful

wsl -d podman-machine-default -u root enterns podman info

Rootless

wsl -d podman-machine-default -u user enterns podman info

Hi @PlaidPhantom I’ll put this on my TODO to add support for. In the meantime as a workaround you can access your windows drive through the mount that is on the wsl linux host, using unix path conventions, like this:

podman cp /mnt/c/users/foo/bar/file.bak mycontainer:/var/opt/backups