Docker Build Issue - Stuck At Exporting Layers

[mrother-stoneriver]

I am simply adding a user, group and directory into a standard image. It works fine until the userid number gets too big and then dock gets stuck exporting layers.I simplified the docker file down to:

FROM eclipse-temurin:17-jdk-jammy

USER root

RUN groupadd -r -g 996600555 testGroup RUN useradd -u 997690599 -g testGroup -r -d /tmp/test testUser RUN mkdir /tmp/test RUN chown -R testUser:testGroup /tmp/test RUN chmod -R g+rw /tmp/test

CMD ["/bin/bash"] The build output show:

=> [internal] load build definition from Dockerfile 0.1s => => transferring dockerfile: 309B 0.0s => [internal] load .dockerignore 0.0s => => transferring context: 2B 0.0s => [internal] load metadata for docker.io/library/eclipse-temurin:17-jdk-jammy 1.3s => CACHED [1/7] FROM docker.io/library/eclipse-temurin:17-jdk-jammy@sha256:ff753441e51d0260f917710d0dfdea73f698624768db2b31be3f6685b4953874 0.0s => => resolve docker.io/library/eclipse-temurin:17-jdk-jammy@sha256:ff753441e51d0260f917710d0dfdea73f698624768db2b31be3f6685b4953874 0.0s => [2/6] RUN groupadd -r -g 996600555 testGroup 0.5s => [3/6] RUN useradd -u 997690599 -g testGroup -r -d /tmp/test testUser 0.6s => [4/6] RUN mkdir /tmp/test 0.6s => [5/6] RUN chown -R testUser:testGroup /tmp/test 0.6s => [6/6] RUN chmod -R g+rw /tmp/test 0.6s => exporting to image 163.4s => => exporting layers UPDATE:

Without the added lines for adding user, group, and directory...image size is 454 MB If I change the value of group and userid to be 10000...image size is 457 MB If I change the value of group and userid to be 1000000...image size is 778 MB If I change the value of group and userid to be 5000000...image size is 2.07 GB If I change the value of group and userid to be 10000000...image size is 3.69 GB As the userId gets increased, the processing time and size of images gets much larger.

Unfortunately, I need to stick with the large userId value to match up container and host user.Does anyone have a solution for this type of error?

DOCKER VERSION INFORMATION

Client: Cloud integration: v1.0.28 Version: 20.10.17 API version: 1.41 Go version: go1.17.11 Git commit: 100c701 Built: Mon Jun 6 23:09:02 2022 OS/Arch: windows/amd64 Context: default Experimental: true

Server: Docker Desktop 4.11.0 (83626) Engine: Version: 20.10.17 API version: 1.41 (minimum version 1.12) Go version: go1.17.11 Git commit: a89b842 Built: Mon Jun 6 23:01:23 2022 OS/Arch: linux/amd64 Experimental: false containerd: Version: 1.6.6 GitCommit: 10c12954828e7c7c9b6e0ea9b0c02b01407d3ae1 runc: Version: 1.1.2 GitCommit: v1.1.2-0-ga916309 docker-init: Version: 0.19.0 GitCommit: de40ad0

Docker Info:

Debug Information

Browser name and version:

URL:

Timetamp or time range:

Public IP:

Hub Username:

Error messages (on screen or in browser console)

Screenshots of the issue (if applicable)

Task List

• [ ] This is NOT a security issue
• [ ] I do NOT have a Docker subscription
• [ ] I have looked through other issues and they do NOT apply to me

[justincormack]

@thaJeztah this is a moby issue not a Hub issue, but its weird, uids are 32 bit so this should be within range, but somewhere else (Go tar?) is getting confused (the sizes look bigger than just writing the uids out in ascii which can also be happening).

[thaJeztah]

This looks possibly the same issue as https://github.com/moby/moby/issues/5419, which has more background and some workarounds.

[thaJeztah]

The TL;DR of the above issue is that;

• useradd by default reserves space for all users, so when using (say), uid 10000, it reserves space for 10000 users, even if only user 10000 is used; for this, a sparse-file is created
• Golang's compression (which is used to compress the image layers) doesn't take sparse-files into account (see https://github.com/golang/go/issues/13548), which means that that file will take up the space reserved

As a workaround, creating the user with the -l option https://linux.die.net/man/8/adduser skips creating the file, which circumvents the issue.