buildah: max_user_namespaces not enable warn when set up environment not start with user namespace

Description

when run buildah inside container, it shows warning of enable max_user_namespace

buildah bud -t buildah-compile .
Error during unshare(CLONE_NEWUSER): Invalid argument
User namespaces are not enabled in /proc/sys/user/max_user_namespaces.
ERRO error parsing PID "": strconv.Atoi: parsing "": invalid syntax 
ERRO (unable to determine exit status) 

It seems like I should enable user namespace using command like echo 15000 > /proc/sys/user/max_user_namespaces. But what make me confused is that the Dockerfile of the image quay.io/buildah/stable shows it already set up env _BUILDAH_STARTED_IN_USERNS="" to stop start buildah with user namespace.

  1. if it’s the problem of that I didn’t enable user namespace, why the env is not work?
  2. if it’s not the problem of user namespace, how can I debug its root cause?

Steps to reproduce the issue:

podman run -it --rm quay.io/buildah/stable bash
cd
echo -e "FROM quay.io/buildah/stable\nRUN dnf -y update;dnf -y install java-1.8.0-openjdk-devel nodejs maven;dnf -y clean all" > Dockerfile
buildah bud -t buildah-compile .
Error during unshare(CLONE_NEWUSER): Invalid argument
User namespaces are not enabled in /proc/sys/user/max_user_namespaces.
ERRO error parsing PID "": strconv.Atoi: parsing "": invalid syntax 
ERRO (unable to determine exit status)

Describe the results you expected: buildah should work

Output of rpm -q buildah or apt list buildah:

# host
buildah-1.11.6-11.el7_8.x86_64

# container
buildah-1.14.8-1.fc32.x86_64

Output of buildah version:

# host
buildah version 1.11.6 (image-spec 1.0.1-dev, runtime-spec 1.0.1-dev)

# container
buildah version 1.14.8 (image-spec 1.0.1-dev, runtime-spec 1.0.1-dev)

Output of cat /etc/*release:

# host
CentOS Linux release 7.8.2003 (Core)

# container
Fedora release 32 (Thirty Two)

Output of uname -a:

# host
Linux localhost.localdomain 3.10.0-1062.4.1.el7.x86_64 #1 SMP Fri Oct 18 17:15:30 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux

# container
Linux cdd19f290235 3.10.0-1062.4.1.el7.x86_64 #1 SMP Fri Oct 18 17:15:30 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux

Output of cat /etc/containers/storage.conf:

[storage]
driver = "overlay"
runroot = "/var/run/containers/storage"
graphroot = "/var/lib/containers/storage"
[storage.options]
additionalimagestores = [
"/var/lib/shared",
]
[storage.options.overlay]
mount_program = "/usr/bin/fuse-overlayfs"
mountopt = "nodev,fsync=0"
[storage.options.thinpool]

About this issue

  • Original URL
  • State: closed
  • Created 4 years ago
  • Comments: 32 (31 by maintainers)

Commits related to this issue

Most upvoted comments

Sorry for replying so late.

For summary

I already tried

  • mount device /dev/fuse by adding option --device /dev/fuse
  • mount volume to avoid fuse-overlayfs on overlay by adding option -v /path/to/localdir:/var/lib/containers

and quay.io/buildah/stable is still not woking on centos 7.8.

The reason I guess

fuse (inside container) version below is not worked as expected with the kernel 3.10.0-1127.10.1.el7.x86_64 (centos 7.8 's kernel version)

fuse-overlayfs: version 1.0.0
FUSE library version 3.9.1
using FUSE kernel interface version 7.31

why I guess so the version of fuse I give above is from image quay.io/buildah/stable. and the work condition is:

  • quay.io/buildah/stable running on centos 7.8: not work
  • quay.io/buildah/stable running on fedora 32: work
  • quay.io/buildah/stable running on centos 8: work

and when I downgrade fuse version to below using customized buildah image (base on centos 7.8)

fuse-overlayfs: version 0.7.2
FUSE library version 3.6.1
using FUSE kernel interface version 7.29

the work condition change to:

  • customized buildah image (base on centos 7.8) running on centos 7.8: work
  • customized buildah image (base on centos 7.8) running on fedora 32: work
  • customized buildah image (base on centos 7.8) running on centos 8: work

I recommand

  • write notes in the download page of image quay.io/buildah/stable or create a doc which explain the version compatible in this repo
  • maintain a new version image base on centos 7.8 instead of fedora 32

the reason I recommand centos 7.8 as the base image is its difficult to upgrade os from centos 7 to centos 8 in a short time. Especially for a production environment.