Podman 3.0.1 :: As a non-root user inside a Fedora-33 docker-ce container, podman(1) fails with: "Error: cannot setup namespace using newuidmap: exit status 1". [Note: This was once working] ...

[nmvega]

Hello Friends:

Environment:

• Fresh install of Fedora-33 running inside a docker-ce container
• podman(1) version 3.0.1 is being used (installed via dnf(1) during "docker build [...]")
• Default podman configuration files (beneath /etc/) have not been modified.
• jdoe, the non-root user, has not implemented any podman(1) configuration overrides.

Also:

jdoe@docker-ce-container$ grep jdoe /etc/subuid /etc/subgid
/etc/subuid:jdoe:100000:65536
/etc/subgid:jdoe:100000:65536

Under the above environment and configuration, podman(1) use to work, but now fails. All sub-commands fail with the following error:

jdoe@docker-ce-container$ podman version
Error: cannot setup namespace using newuidmap: exit status 1

As far as I can tell, the only command that works is:

jdoe@docker-ce-container$ podman -v
podman version 3.0.1

The only thing that I can think of as far as why this once worked but now fails, is that I freshly rebuilt the enclosing docker container (after many months -- just to freshen it), and perhaps it installed a newer major version of podman(1) v3.x; and this gave rise to this new issue.

Note that I didn't change anything in the Dockerfile; I simply rebuilt it.

Any ideas friends? Thank you in advance!

[mheon]

@rhatdan PTAL

[rhatdan]

Could you reinstall the shadow-utils (newuidmap) within the container. And see if it works. For some reason the file capabilities are not set by default.

[nmvega]

@rhatdan Absolutely. When I bring my cluster back up (likely tomorrow evening), I'll perform a dnf -y reinstall shadow-utils and let you know if that resolved the issue. If there is any other output that you would like to see (before or after), feel free to let me know. Hopefully it's something relatively simple either way. =:) Thank you.

[nmvega]

@rhatdan Hello Daniel:

There is positive progress after running dnf -y reinstall shadow-utils.

I'm now able to pull and ls images; ... operations that I couldn't previously perform. However, there's now a pesky little WARNing that appears after every sub-command:

jdoe@docker-ce-container$ podman pull docker.io/library/mariadb:latest
WARN[0000] Failed to detect the owner for the current cgroup: stat /sys/fs/cgroup/systemd/docker/e478aac5769b5a8d88c2b5c1c9c24ca79b3706ba075b535f67a5be969a4b04db: no such file or directory
[ ... snip ... ]

jdoe@docker-ce-container$ podman images
WARN[0000] Failed to detect the owner for the current cgroup: stat /sys/fs/cgroup/systemd/docker/e478aac5769b5a8d88c2b5c1c9c24ca79b3706ba075b535f67a5be969a4b04db: no such file or directory 
REPOSITORY                 TAG     IMAGE ID      CREATED       SIZE
docker.io/library/mariadb  latest  1138596852f3  33 hours ago  407 MB

jdoe@docker-ce-container$

Note that I'm running as jdoe (a normal user) and without systemd (and using tini instead):

jdoe@docker-ce-container$ ps -ef
UID        PID  PPID  C STIME TTY          TIME CMD
jdoe     1     0  0 20:53 ?        00:00:00 tini -g -- start-singleuser.sh --ip=0.0.0.
jdoe     6     1  0 20:53 ?        00:00:03 /opt/conda/bin/python /opt/conda/bin/jupyt
jdoe    57     6  0 20:53 pts/0    00:00:00 /bin/bash -l
jdoe   224     1  0 20:55 ?        00:00:00 podman

Given all of that, here are follow-on questions (and thank you in advance[!]):

1. When building the image, to avoid the original namespace error, what do you suggest I do? Do I run dnf -y install podman && dnf -y reinstall shadow-utils (during build)? Or implement some other configuration workaround?

2. How do I fix the latter WARN[0000] issue, preferably without impacting performance? I noticed your comments in separate issue thread, but didn't quite understand the resolution.

Thank you in advance!

[nmvega]

@rhatdan

UPDATE:

Regarding Question 1 above, I rebuilt the image using the dnf install sequence that I proposed, and that works. It's a little hacky in that it requires ordering of package installs, so if you have a better workaround, or if you know that this will be addressed in an upcoming bug fix, feel free to let me know.

Regarding Question 2 above, I still need help with that one. =:) Below I provide the output of podman info if that helps you (... I forgot to include it originally).

jdoe@docker-ce-container$ podman info
WARN[0000] Failed to detect the owner for the current cgroup: stat /sys/fs/cgroup/systemd/docker/fb08387ba1046cfa1505e26d2308bbba03ab79cddbd7374c28e60d0b42980157: no such file or directory 
host:
  arch: amd64
  buildahVersion: 1.19.4
  cgroupManager: cgroupfs
  cgroupVersion: v1
  conmon:
    package: conmon-2.0.26-1.fc33.x86_64
    path: /usr/bin/conmon
    version: 'conmon version 2.0.26, commit: 777074ecdb5e883b9bec233f3630c5e7fa37d521'
  cpus: 12
  distribution:
    distribution: fedora
    version: "33"
  eventLogger: file
  hostname: fb08387ba104
  idMappings:
    gidmap:
    - container_id: 0
      host_id: 100
      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.6.13-100.fc30.x86_64
  linkmode: dynamic
  memFree: 46721601536
  memTotal: 67376635904
  ociRuntime:
    name: crun
    package: crun-0.18-1.fc33.x86_64
    path: /usr/bin/crun
    version: |-
      crun version 0.18
      commit: 808420efe3dc2b44d6db9f1a3fac8361dde42a95
      spec: 1.0.0
      +SYSTEMD +SELINUX +APPARMOR +CAP +SECCOMP +EBPF +CRIU +YAJL
  os: linux
  remoteSocket:
    path: /home/jdoe/Downloads/TEMP.d/podman-run-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
    selinuxEnabled: false
  slirp4netns:
    executable: /usr/bin/slirp4netns
    package: slirp4netns-1.1.9-1.fc33.x86_64
    version: |-
      slirp4netns version 1.1.9
      commit: 4e37ea557562e0d7a64dc636eff156f64927335e
      libslirp: 4.3.1
      SLIRP_CONFIG_VERSION_MAX: 3
      libseccomp: 2.5.0
  swapFree: 0
  swapTotal: 0
  uptime: 192h 53m 20.65s (Approximately 8.00 days)
registries:
  search:
  - registry.fedoraproject.org
  - registry.access.redhat.com
  - registry.centos.org
  - docker.io
store:
  configFile: /home/jdoe/.config/containers/storage.conf
  containerStore:
    number: 1
    paused: 0
    running: 0
    stopped: 1
  graphDriverName: overlay
  graphOptions:
    overlay.mount_program:
      Executable: /usr/bin/fuse-overlayfs
      Package: fuse-overlayfs-1.4.0-1.fc33.x86_64
      Version: |-
        fusermount3 version: 3.9.3
        fuse-overlayfs: version 1.4
        FUSE library version 3.9.3
        using FUSE kernel interface version 7.31
  graphRoot: /home/jdoe/.local/share/containers/storage
  graphStatus:
    Backing Filesystem: extfs
    Native Overlay Diff: "false"
    Supports d_type: "true"
    Using metacopy: "false"
  imageStore:
    number: 1
  runRoot: /home/jdoe/Downloads/TEMP.d/podman-run-1000/containers
  volumePath: /home/jdoe/.local/share/containers/storage/volumes
version:
  APIVersion: 3.0.0
  Built: 1613753777
  BuiltTime: Fri Feb 19 16:56:17 2021
  GitCommit: ""
  GoVersion: go1.15.8
  OsArch: linux/amd64
  Version: 3.0.1

[rhatdan]

I think we should lower that warning to info, so that it will not show by default.
#9858