manjarolinux/base currently contains a pre-created user builder with UID/GID 1000:1000 (/etc/passwd shows builder:x:1000:1000::/builder:/bin/bash).
This is unexpected for a base image and breaks common init/entrypoint scripts that create the first regular user as UID 1000 (a very standard default on Linux). As a result, scripts fail with:
useradd: UID 1000 is not unique
I understand why a builder account can exist in a dedicated build image/tag, but having it in base creates avoidable collisions and breaks downstream usage.
Steps to Reproduce
Run a container based on manjarolinux/base (or any image inheriting from it) and inspect /etc/passwd.
Attempt to create a user with UID 1000 in entrypoint/init.
Example output from /etc/passwd inside the container:
...
git:x:977:977:git daemon user:/:/usr/bin/git-shell
builder:x:1000:1000::/builder:/bin/bash
...
Then creating a normal user (typical pattern in entrypoint scripts):
useradd: UID 1000 is not unique
Expected Behavior
manjarolinux/base should not reserve UID/GID 1000 for a non-standard account.
Downstream images should be able to create their primary non-root user as UID 1000 without collisions.
Actual Behavior
builder exists in the base image with UID/GID 1000, causing user creation failures and breaking init scripts for many downstream images.
Impact
Breaks common “create user on first run” entrypoints (SSH images, devcontainers, CI tooling, etc.).
Forces downstream images to implement hacks/workarounds (delete/rename builder, pick nonstandard UID, conditional logic).
Violates expectation that “base” is minimal and does not pre-occupy the most common non-root UID.
Notes / Investigation
I checked Dockerfile.base and do not see an explicit useradd for builder, which suggests the account may be introduced indirectly (e.g., via packaged rootfs artifacts, skel/overlay, or shared build pipeline between tags). Regardless of the introduction point, the observable result in the published base image is the same: UID/GID 1000 is taken.
manjarolinux/base currently contains a pre-created user builder with UID/GID 1000:1000 (/etc/passwd shows builder:x:1000:1000::/builder:/bin/bash).
This is unexpected for a base image and breaks common init/entrypoint scripts that create the first regular user as UID 1000 (a very standard default on Linux). As a result, scripts fail with:
useradd: UID 1000 is not unique
I understand why a builder account can exist in a dedicated build image/tag, but having it in base creates avoidable collisions and breaks downstream usage.
Steps to Reproduce
Run a container based on manjarolinux/base (or any image inheriting from it) and inspect /etc/passwd.
Attempt to create a user with UID 1000 in entrypoint/init.
Example output from /etc/passwd inside the container:
...
git:x:977:977:git daemon user:/:/usr/bin/git-shell
builder:x:1000:1000::/builder:/bin/bash
...
Then creating a normal user (typical pattern in entrypoint scripts):
useradd: UID 1000 is not unique
Expected Behavior
manjarolinux/base should not reserve UID/GID 1000 for a non-standard account.
Downstream images should be able to create their primary non-root user as UID 1000 without collisions.
Actual Behavior
builder exists in the base image with UID/GID 1000, causing user creation failures and breaking init scripts for many downstream images.
Impact
Breaks common “create user on first run” entrypoints (SSH images, devcontainers, CI tooling, etc.).
Forces downstream images to implement hacks/workarounds (delete/rename builder, pick nonstandard UID, conditional logic).
Violates expectation that “base” is minimal and does not pre-occupy the most common non-root UID.
Notes / Investigation
I checked Dockerfile.base and do not see an explicit useradd for builder, which suggests the account may be introduced indirectly (e.g., via packaged rootfs artifacts, skel/overlay, or shared build pipeline between tags). Regardless of the introduction point, the observable result in the published base image is the same: UID/GID 1000 is taken.