Podman: Trying to copy *out* of container errors with "cannot copy into ..."

[rpjday]

/kind bug

Description
With a running CentOS 8 container, simply trying to copy a file out of the container generates an error suggesting you're trying to copy into the container.

$ podman cp hungry_cerf:/etc/os-release /tmp
Error: cannot copy into running rootless container with pause set - pass --pause=false to force copying

Simply trying to cat that same file appears to work fine:

$ podman exec hungry_cerf cat /etc/os-release
NAME="CentOS Linux"
VERSION="8 (Core)"
ID="centos"
ID_LIKE="rhel fedora"
VERSION_ID="8"
PLATFORM_ID="platform:el8"
PRETTY_NAME="CentOS Linux 8 (Core)"
ANSI_COLOR="0;31"
CPE_NAME="cpe:/o:centos:centos:8"
HOME_URL="https://www.centos.org/"
BUG_REPORT_URL="https://bugs.centos.org/"

CENTOS_MANTISBT_PROJECT="CentOS-8"
CENTOS_MANTISBT_PROJECT_VERSION="8"
REDHAT_SUPPORT_PRODUCT="centos"
REDHAT_SUPPORT_PRODUCT_VERSION="8"

Output of podman version:

Version:            1.7.0
RemoteAPI Version:  1
Go Version:         go1.13.5
OS/Arch:            linux/amd64

[mheon]

I thought we forced the default for pause to false on rootless with CGroups
v1.

On Tue, Jan 28, 2020, 07:49 Robert P. J. Day [e-mail]
wrote:

/kind bug

Description
With a running CentOS 8 container, simply trying to copy a file out of
the container generates an error suggesting you're trying to copy into
the container.

$ podman cp hungry_cerf:/etc/os-release /tmp
Error: cannot copy into running rootless container with pause set - pass --pause=false to force copying

Simply trying to cat that same file appears to work fine:

$ podman exec hungry_cerf cat /etc/os-release
NAME="CentOS Linux"
VERSION="8 (Core)"
ID="centos"
ID_LIKE="rhel fedora"
VERSION_ID="8"
PLATFORM_ID="platform:el8"
PRETTY_NAME="CentOS Linux 8 (Core)"
ANSI_COLOR="0;31"
CPE_NAME="cpe:/o:centos:centos:8"
HOME_URL="https://www.centos.org/"
BUG_REPORT_URL="https://bugs.centos.org/"

CENTOS_MANTISBT_PROJECT="CentOS-8"
CENTOS_MANTISBT_PROJECT_VERSION="8"
REDHAT_SUPPORT_PRODUCT="centos"
REDHAT_SUPPORT_PRODUCT_VERSION="8"

Output of podman version:

Version: 1.7.0
RemoteAPI Version: 1
Go Version: go1.13.5
OS/Arch: linux/amd64

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/containers/libpod/issues/5000?email_source=notifications&email_token=AB3AOCEJXNGGEZLXAZRFF53RAASVXA5CNFSM4KMR3AWKYY3PNVWWK3TUL52HS4DFUVEXG43VMWVGG33NNVSW45C7NFSM4IJGYBIA,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AB3AOCD2AVREPRWXX4QNQSTRAASVXANCNFSM4KMR3AWA
.

[rpjday]

Both the host (Fedora 31) and container (Centos 8.1) are currently using cgroups v2, so not sure what v1 has to do with this issue.

[baude]

i cannot replicate this with upstream master.

$ bin/podman cp foo:/etc/os-release /tmp/
$

@rpjday can you confirm what you are doing here? this is rootless and the container is running ?

[mheon]

I think we fixed the error on upstream. I do think the error message could use a touchup to reflect that it doesn't matter if we're copying in or out.

[rpjday]

On Tue, 28 Jan 2020, Matthew Heon wrote:

I think we fixed the error on upstream. I do think the error message
could use a touchup to reflect that it doesn't matter if we're
copying in or out.

couple thoughts ... first, is it the copying error that has been
fixed upstream? given that copying a file from a container to the host
seems like such a basic operation, i'm puzzled as to how there can
have been an issue with it all this time. surely i can't have been the
only one who has tried something like this and had it fail.

and second, i would think that the error messages generated by
copying in versus copying out should be at least a little different,
as copying out of a container should be a far more forgiving
operation than the opposite. or perhaps i'm misreading this.

rday

p.s. and, yes, "man podman-cp" formatting is somewhat borked, as
the markdown being used is not properly rendering list items within a
list, or whatever is being attempted there. will fix.

[rpjday]

On Tue, 28 Jan 2020, Brent Baude wrote:

>

i cannot replicate this with upstream master.

$ bin/podman cp foo:/etc/os-release /tmp/
$

@rpjday can you confirm what you are doing here? this is rootless
and the container is running ?

not sure if you still wanted the recipe i'm using to generate this
but:

• fully updated fedora 31
  $ podman version
  Version: 1.7.0
  RemoteAPI Version: 1
  Go Version: go1.13.5
  OS/Arch: linux/amd64

start ubuntu container with:

$ podman run -it ubuntu sh

if i try a simple "podman cp" out of the running ubuntu container:

$ podman cp relaxed_payne:/etc/os-release /tmp
Error: cannot copy into running rootless container with pause set - pass --pause=false to force copying
$

so, ok, add the recommended option, which makes it work:

$ podman cp --pause=false relaxed_payne:/etc/os-release /tmp
$ cat /tmp/os-release
NAME="Ubuntu"
VERSION="18.04.3 LTS (Bionic Beaver)"
ID=ubuntu
... etc etc ...

that's it, not doing anything special that i'm aware of.

rday

[QiWang19]

I can replicate this issue with fedora 31, podman 1.7.0
but this issue has been fixed with upstream master.
Should we close this issue?

[rpjday]

I will leave it to those higher up the food chain to close this issue.

[rhatdan]

If it is upstream @QiWang19 Then close the issue, if someone disagrees, they can reopen.