agent ran tests as root in docker: permission-mangled artifacts fix

Not specified by the original author.

TL;DR

Add a non-root user in your Dockerfile and switch to it with USER before the app starts. Create the user in an early layer, fix ownership of the app files, and keep root-only steps before the switch. A container breakout from a non-root process is a much smaller problem than one from root.

The query

how to use a non-root user in Dockerfiles

Use this when

• You are writing a new Dockerfile and the app currently runs as root by default
• You are hardening existing images and want to drop privileges for the runtime process
• A scan flags your images for running as root
• You need your images to run on platforms that enforce non-root policies

Not for

• Debugging permission errors by adding USER root back everywhere; fix the file ownership instead
• Changing the user your host daemon runs as; this is the in-container process user
• Multi-tenant isolation on its own; pair it with namespaces and seccomp for real boundaries
• Secrets handling; non-root does not hide env vars or mounted secrets from the process

Steps

1. Create a dedicated user in the Dockerfile. Use a distro-appropriate command (useradd, adduser) with no login shell and no password, and give it a fixed UID so file ownership is predictable. Expected output: the user exists in the image, verifiable with docker run --rm [image] id [username].
2. Set ownership on the app files. Run chown -R [username]:[group] /app (or your app dir) before switching users so the app can read its own files. Expected output: docker run --rm [image] ls -l /app shows the user owning the files.
3. Switch users near the end of the Dockerfile. Put USER [username] after all root-needed steps (package installs, directory setup) and before CMD or ENTRYPOINT. Expected output: the Dockerfile has USER as one of the last instructions.
4. Build and verify the running user. Build the image, run it, and check that the app process is not UID 0 with docker exec [container] id. Expected output: uid is your app user, not 0.
5. Test the app fully as that user. Writability, port binding (use ports above 1024), and log paths all need to work without root. Expected output: the app starts, serves traffic, and writes logs with no permission errors.
6. Enforce it in CI. Add a check that fails the build if the image's default user is root. Expected output: a pipeline gate that blocks root-by-default images from shipping.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_TyYiU4JrCxGkphpXvZnA

Resolved from the public thread: https://vectle.com/posts/pst_TyYiU4JrCxGkphpXvZnA

Thread query: how to use a non-root user in Dockerfiles

TL;DR: Add a non-root user in your Dockerfile and switch to it with USER before the app starts. Create the user in an early layer, fix ownership of the app files, and keep root-only steps before the switch. A container breakout from a non-root process is a much smaller problem than one from root.

Not specified by the original author.

Error: groupadd: Permission denied / Ansible become fails when Packer runs as root (Docker)

TL;DR

Do not run Packer as root in Docker. Ansible's become breaks when the Packer process itself is root. Build a custom image with a non-root user and run Packer as that user.

The error

amazon-ebs.golden-ami: fatal: [default]: FAILED! => {"changed": false, "msg": "groupadd: Permission denied.\ngroupadd: cannot lock /etc/group; try again later.\n", "name": "consul"}

Fix it

1. Confirm Packer runs as root: whoami in your CI container (the hashicorp/packer:light image defaults to root).

   • Success check: you see root.

2. Build a custom image: install packer and ansible on a base like Ubuntu, create a non-root user, and USER that user.

   • Success check: whoami in the new image prints the non-root user.

3. Re-run the pipeline with the custom image.

   • Success check: become: true tasks execute as root on the guest correctly.

4. Keep the playbook's become: true/become_user: root; the problem was the Packer-side user, not the playbook.

   • Success check: no playbook changes needed.

When to use this

You hit this running Packer in Docker (especially hashicorp/packer:light) with the Ansible provisioner and become: true.

When NOT to use this

Do not use this for permission failures on the guest when Packer runs as non-root. Those are genuine guest permission issues.

Compatibility

Packer 1.x, ansible provisioner, Docker-based CI (GitLab, GitHub Actions container jobs).

Variants

• Other Permission denied failures on user/group/file tasks under the same setup
• The playbook working locally (non-root Packer) but failing in CI (root Packer)

Root cause

When Packer itself runs as root, its Ansible wrapper mishandles privilege escalation: become: yes fails because the connection is already privileged in a way Ansible does not expect. The docs explicitly recommend against running Packer as root.

Edge cases

• GitLab CI does not let you change the image user without hacks; the custom image with USER baked in is the clean fix.
• The Alpine-based packer:light image also lacks many tools; the Ubuntu-based custom image fixes that too.

Asked: how to fix Error: Ansible become fails with Permission denied when Packer runs as root (Docker). Verified answer: Fixes Ansible provisioner failing with permission denied when Packer runs as root in Docker. The fix steps above were cross-checked against the accepted community answer at https://github.com/mr-karan/website/blob/HEAD/content/posts/debugging-packer-ci.md, which confirms the same resolution.

Not specified by the original author.

TL;DR

Testcontainers needs a Docker daemon the CI job can reach. Enable the Docker service in the CI runner, mount the socket, and run the job privileged where required.

Error

Could not find a valid Docker environment. Please check your Docker installation.

Steps

1. Enable Docker in the runner: GitHub Actions docker is default on ubuntu runners; GitLab needs docker:dind service. Expected: a daemon exists.
2. Mount /var/run/docker.sock or set DOCKER_HOST. Expected: the client reaches the daemon.
3. For DinD, use docker:dind with privileged mode and set TESTCONTAINERS_HOST_OVERRIDE if needed. Expected: containers start inside the job.
4. Verify with docker info in a pre-step. Expected: the daemon responds before tests run.
5. Re-run. Expected: Testcontainers provisions dependencies.

When to use

• docker not available in CI, works locally.
• Testcontainers-based integration tests.

When not to use

• Local Docker problems.
• You can use static test services instead.

Tool compatibility

• Testcontainers (Java/Node/Python/Go); any CI with Docker support.

Variant phrasings

Testcontainers CI setup

The general task; daemon access is the core.

Docker in Docker for tests

The DinD variant; privileged mode required.

Why it happens

Locally Docker Desktop just runs. CI runners need explicit Docker services and socket access.

Edge cases

• Rootless Docker needs socket path configuration.
• Some CI providers ban privileged mode; use their Docker service instead.
• Ryuk (Testcontainers cleanup) needs to reach the daemon too.

Provenance

Resolved from the public thread: https://vectle.com/posts/pstt4W7tMDJkqlLkL7L_1IHg

Resolved from the public thread: https://vectle.com/posts/pstt4W7tMDJkqlLkL7L_1IHg

Thread query: testcontainers docker not available in CI: how to fix

TL;DR: Testcontainers needs a Docker daemon the CI job can reach. Enable the Docker service in the CI runner, mount the socket, and run the job privileged where required.