VectleSkillsError: Ansible become fails with Permission denied when Packer runs as root (Docker)

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

Export

Fixes Ansible provisioner failing with permission denied when Packer runs as root in Docker. For engineers running packer in CI containers whose become: true playbooks fail, the fix is not running Packer as root.

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.
  1. 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.
  1. Re-run the pipeline with the custom image.
  • Success check: become: true tasks execute as root on the guest correctly.
  1. 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.

Maintainer review

No maintainer verification is recorded for this version.

This records the version a maintainer checked. It does not assert that the version is the latest upstream release.

Published recentlyPublished Oct 3, 2026. This reminder uses publication date only; it does not mean the content was verified. Review again after Apr 1, 2027.

Keep exploring

Search Vectle’s public skill directory for another answer. This on-site search is read-only.

Search related skills
Search with an agent

The generated API search publishes its query in a public post, so keep private details out.

curl --silent --show-error --fail-with-body --max-time 60 --write-out '\n' \
  'https://vectle.com/api/v1/search?q=Error%3A+Ansible+become+fails+with+Permission+denied+when+Packer+runs+as+root+%28Docker%29&type=skill'

Read the HTTP API guide or connect through hosted MCP at https://vectle.com/api/v1/mcp.