Make can't run mkdir as root in Alpine Linux container

Question

So, I'm trying to build musl-libc inside an Alpine Linux Docker container. The configure script succeeds, but make stops immediately because it can't run mkdir:

mkdir -p lib
make: mkdir: Operation not permitted
make: *** [Makefile:96: lib] Error 127

Using strace, I can see that it's getting EPERM when it checks access on the various mkdir symlinks, so it never actually runs the command itself:

faccessat2(AT_FDCWD, "/usr/local/sbin/mkdir", X_OK, AT_EACCESS) = -1 EPERM (Operation not permitted)
faccessat2(AT_FDCWD, "/usr/local/bin/mkdir", X_OK, AT_EACCESS) = -1 EPERM (Operation not permitted)
faccessat2(AT_FDCWD, "/usr/sbin/mkdir", X_OK, AT_EACCESS) = -1 EPERM (Operation not permitted)
faccessat2(AT_FDCWD, "/usr/bin/mkdir", X_OK, AT_EACCESS) = -1 EPERM (Operation not permitted)
faccessat2(AT_FDCWD, "/sbin/mkdir", X_OK, AT_EACCESS) = -1 EPERM (Operation not permitted)
faccessat2(AT_FDCWD, "/bin/mkdir", X_OK, AT_EACCESS) = -1 EPERM (Operation not permitted)

I have no idea why this is. I'm running make as root, and /bin/busybox has the executable bit set for all users anyway. I can create the directory just fine from the command line. What's going on here, and how do I fix it?

EDIT: As requested, here's the Dockerfile I'm using:

FROM alpine

ENV UTILS='vim tmux gdb strace git mandoc'
ENV DEPS='gcc make'

RUN apk update && apk add $DEPS $UTILS
ADD musl-src /musl-libc
ENV NPROC=6
RUN cd musl-libc && ./configure --prefix=/usr --enable-debug && \
    make -j$NPROC
RUN cd musl-libc && make install

Requires the musl source in ./musl-src.

Answer 1

Workaround: use bmake instead of make

I hit this exact same problem in a containerised build on Alpine where make was GNU make 4.3. The build would work fine on local Docker but fail on the ADO pipeline agents. Alternatively the same sequence of commands that make was attempting, issued directly from RUN, also worked fine.

The pipeline agents are based on RHEL7 with the Docker version that RH choose to package. I can't upgrade Docker on them, nor start it using special options and a different security profile. It's managed by a different team and right out of my control.

With reference to comments above and the other question Which capabilities are needed for statx to stop giving EPERM it seems reasonable to guess that an alternate implementation of make might use the older stat rather than statx call which this old version of Docker has trouble with.

Indeed, NetBSD's bmake gives me a solution for now.

RUN apk add --upgrade gcc libc-dev bmake

RUN bmake dist