error from newuidmap: newuidmap: write to uid_map failed: Operation not permitted #3834
Comments
|
could you try these commands to confirm newuidmap and newgidmap work? |
Just for good measure: so not an SELinux problem at least. |
|
Prior versions of dnf required a reinstalled shadow-utils package to make sure newuidmap and newgidmap got their filecap set. In quay.io/buildah/stable we do: |
|
Interesting. Is this some kind of bug which will be resolved at some point to not require this hackery? Unfortunately resolving this has just led to another error: |
|
Yes there is something wrong with the imagebuilder that is building the base images. I am surprised it has not been fixed yet. The lchown issue, means that the UID is not allowed to be changed, either the UID range in the user namespace is not covered or the underlying file system is not allowing the chown. |
Any thoughts on how which of those problems is determined to be the cause and the mitigation? |
|
--build-arg UID=$(id -u) is probably causing the issue, if this UID is not available in the user namespace. |
|
Just a guess, but UID 11412345 does not exists within the user namespace and if this UID is attempted to be put on disk the chown will fail. |
|
So if your guess is correct, how do I make that UID available in the user namespace? I'm afraid I have not really had time to wrap my head around all of this namespace stuff yet. :-( |
|
Could you try to build in rootfull mode? What are you doing with the UID? BTW Your UID is in the container, it is just mapped to root. |
|
The UID in the container is being used to add a user. I.e.: Running the Although frankly if that's just a side-effect of running rootful, then we could disregard it as hopefully running rootful has provided the information you need and we can move on to getting it to run rootless again? |
|
If you are running the container with Podman, there is no need to add that user. Podman will do it automatically with a command like: $ podman run --userns=keep-id -v $HOME:$HOME --workdir $HOME fedora grep dwalsh /etc/passwd |
|
yes please drop I am closing the issue since this failure is expected, but please keep the discussion going and add more comments. |
Following along here: https://rpm-software-management.github.io/mock/#mock-inside-podman-fedora-toolbox-or-docker-container it instructs to add a
AFAIU, that is needed when creating the user above so that a directory mapped into the container (with And this works elsewhere, where |
|
You should just create a user within your container and set it to that UID like 1000 but it has no relationship the the UID assigned to the user do the build. In rootless containers, you only get 65k UIDs, so specifying a UID > 65k will not work. |
But then (with Docker at least -- recall the requirement to be compatible with Docker as podman is not ubiquitous yet) running the container with, say, |
|
We change the UIDs within the podman machine to match those of the host, so that processes running by the user "podman containers" can write to volumes from the homedir. |
|
I'm not seeing that here. Creating the container with the default Or maybe I am. I don't really know any more as I am so confused now. I really just want to be able to start a container, map my FROM fedora:35
RUN dnf -y install mock make \
rpm-build createrepo rpmlint redhat-lsb-core git \
python-srpm-macros rpmdevtools mock-core-configs\ \<\ 37.1
ARG UID=1000
ENV USER build
ENV PASSWD build
RUN useradd -u $UID -ms /bin/bash $USER
RUN echo "$USER:$PASSWD" | chpasswd
RUN usermod -a -G mock $USER
RUN dnf -y upgrade --exclude mock-core-configs && \
dnf clean all
USER buildi.e.: podman's limitation of not being able to use my large UID in the container seems to be the road-block here, so what is the solution? |
|
@giuseppe thoughts? BTW Podman can do exactly what Docker does, which is run as root. The issues you are seeing is caused by the User Namespace. If you ran docker in rootless mode, you would have the exact same issue. @giuseppe I think we should have To allow users to see what that user namespace looks like. |
|
I seem to have a solution that works in both environments with both high and low UIDs: FROM fedora:35
RUN dnf -y install mock make \
rpm-build createrepo rpmlint redhat-lsb-core git \
python-srpm-macros rpmdevtools mock-core-configs\ \<\ 37.1
ARG UID=1000
ENV USER build
ENV PASSWD build
RUN useradd -u $UID -ms /bin/bash $USER
RUN echo "$USER:$PASSWD" | chpasswd
RUN usermod -a -G mock $USER
RUN dnf -y upgrade --exclude mock-core-configs && \
dnf clean allPodmanDockerwhere with Podman, my UID is 1001 and on the Docker machine, my UID is 11412345. But boy this was a long haul to get here. Any thoughts about all of this? |
|
could you give a try to |
Description
Trying to build a container results in an error:
Steps to reproduce the issue:
Not entirely sure. Simply tried to build a container as above.
Describe the results you received:
As above.
Describe the results you expected:
Container build works just as it does successfully on a different Fedora 35 system where my
uidis1001Output of
rpm -q buildahorapt list buildah:(but I came here because https://github.com/containers/podman/issues/new says:
Output of
buildah version:Output of
podman versionif reporting apodman buildissue:I have of course tried to run
podman system migrateas suggested.Output of
cat /etc/*release:Output of
uname -a:Output of
cat /etc/containers/storage.conf:The text was updated successfully, but these errors were encountered: