moby: docker build hangs/crashes when useradd with large UID

As a work around can you try the -l or --no-log-init in the Dockerfile

RUN useradd -l -u 99900000 -g users mcieslik

Still a problem! Can’t believe docker silently filled up my disk due to this. Visual Studio Code is recommending this pattern for having non-root users, so it’s important to get this fixed asap!

It gets worse - the disk space cannot be reclaimed unless docker is reinstalled. None of the docker system prune options work.

Just came by to look for a solution for this issue, which is affecting me, too. To my disappointment I see now that this eight year old issue is still open and unresolved. Having read the comments and mentions, I assume that this issue is affecting a number of projects but appears to have no priority.

Besides recommending workarounds in Dockerfiles to everybody who is affected by this shortcoming, it seems to me that there is no activity related to a fix. Please note that these workarounds are sometimes not applicable. For instance does the usermod command on the Linux distributions that I am familiar with (Debian up to v10, Gentoo) not have a --no-log-init option.

If there is no fix planned, what is then the anticipated way forward with this issue?

Thanks! This worked.

usermod causes the same problem and it doesn’t have --no-log-init Storage Driver: aufs

Just want to mention that a duplicated issue was opened then closed: https://github.com/moby/moby/issues/43133

As part of the up mentioned one, I’ve confirmed that - from software developer point of view - this issue can be used to DoS attack different environments - provided by different IaaS and/or PaaS - especially CICD ones and exactly, as a software developer I’m able to trigger a Jenkins build which builds such a Dockerfile file and as a result that Jenkins node becomes dead in few hours so IaaS and/or PaaS engineers are forced to reinstall OS on host which runs Jenkins node.

As a work around try for usermod

Dockerfile

....
RUN rm /var/log/lastlog /var/log/faillog && \
        ln -s /dev/null /var/log/lastlog && \
        ln -s /dev/null /var/log/faillog && \
        useradd -u 99900000 -g users developer && \
        rm /var/log/lastlog /var/log/faillog && \
        touch /var/log/lastlog && \
        touch /var/log/faillog
....

I also can confirm that @pnasrat’s workaround fixes this problem. I am now using:

groupadd -g $HOST_USER_GID notroot                           && \
useradd -l -u $HOST_USER_UID -g $HOST_USER_GID notroot       && \

instead of:

addgroup --gid $HOST_USER_GID notroot                     && \
adduser --uid $HOST_USER_UID --gid $HOST_USER_GID notroot

And the build succeeded.

My $HOST_USER_UID and $HOST_USER_GID contain 10 digit IDs

Unfortunately I can not help you with those as I have not used them inside docker yet. But if I find any issue/workaround I will post them here (until the problem is properly fixed).

Let’s get https://github.com/moby/moby/pull/35739 in first and see if we could use the new APIs in archive/tar, such as tar.DetectSparseHoles.

So is this an issue with “docker commit” that it can’t handle sparse files and blots the file to the full size during commit. If yes, then I guess this is something which should be fixed in docker.

I created a 1G sparse file in a container (with overlay backend) and then did docker commit and top most layer size was 1G. So docker did inflate the file to 1G and that seems very inefficient.

The underlying issue is that a large sparse file is created (approximately 32 GB), but it’s not exactly a Docker bug. Docker could make an attempt to handle large sparse files better, but that’s a subject for the #docker-dev mailing list.

I’ll close this issue now. Please feel free to comment.