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)
@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:
Regarding running direct commands from WSL, you need to use the
enternsshell 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 infoRootless
wsl -d podman-machine-default -u user enterns podman infoHi @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