2.0.1 docker-entrypoint.sh broken

[Nordle]

When running the vault image as a sidecar in kubernetes the following error is being logged:

/usr/local/bin/docker-entrypoint.sh: exec: line 116: agent: not found

Reverting back to 2.0.0 fixes this issue (we were previously using latest and experienced a restart today which pulled down 2.0.1)

Current sidecar config (before fixing the version)

extraContainers:
  - name: vault-agent
    image: hashicorp/vault:latest
    args:
      - agent
      - -config=/vault/config/agent.hcl
    securityContext:
      runAsUser: 100
      runAsGroup: 1000
      runAsNonRoot: true
      allowPrivilegeEscalation: false
      capabilities:
        drop:
          - ALL

Expected behavior
Sidecar starts without issues

Vault server configuration file(s):

# Paste your Vault config here.
# Be sure to scrub any sensitive values

Additional context
Add any other context about the problem here.

[marnagy]

Hello,
We are experiencing the same issue when installing latest vault release (2.0.1).
According to releases pages 2.0.1 only contains linux platform files while 2.0.0 contains macOS, FreeBSD and Windows as well.

[heatherezell]

Thanks for this report - I'm investigating with our release management team. Stay tuned.

[heatherezell]

This is being actively worked on; we are aiming for a fix to be released next week barring any unforeseen issues. We appreciate folks' patience!

[heatherezell]

Release notes have been updated: https://developer.hashicorp.com/vault/docs/updates/release-notes#vault-2-0-1

[chris-peterson]

Additional context: the same EPERM affects consumers that extract the binary from the official image (COPY --from=hashicorp/vault / docker cp) and then run it under the default Linux capability set (i.e. not only directly running/extending)

Relevant commit: commit 8b0f0b1 — [VAULT-44098] containers: never attempt to run setcap when running as non-root user. This moves setcap cap_ipc_lock=+ep from the runtime entrypoint into a Dockerfile RUN, so the capability is set on the binary at build time. The commit message documents the new requirement: "users of the container must add IPC_LOCK capability to the container or pod or the Vault service will fail to start."

Reproduction: A Dockerfile that extracts the binary via

COPY --from=hashicorp/vault /bin/vault /usr/local/bin/vault

and runs the resulting image under the default Linux capability set (no IPC_LOCK granted). With hashicorp/vault:2.0.0 this worked; with hashicorp/vault:2.0.1 the kernel returns EPERM on exec:

vault: Operation not permitted

Scope: The commit message frames the change as a consequence of running the container as a non-root user:

As we now run the Vault container as an unprivileged user we have to set this capability at build time as setcap cannot be run by unprivileged users.

That describes why setcap moved to build time. The resulting execve() check, however, is against the calling process's capability bounding set rather than its UID — so any container that hasn't granted CAP_IPC_LOCK (the Linux/Docker default) sees the same EPERM:

$ docker run --rm --user 0:0 --cap-drop=ALL --entrypoint sh hashicorp/vault:2.0.1 -c "id; vault --version"
uid=0(root) gid=0(root) groups=0(root)
sh: /bin/vault: Operation not permitted

Documentation framing: The breaking change is documented at important-changes as "Docker image requires IPC_LOCK capability", but the capability is on the binary itself — so anything that extracts the binary from the image (COPY --from=hashicorp/vault, docker cp) also requires IPC_LOCK. A mention of the binary, not just the image, would help these consumers find the docs.

GitHub release page: The v2.0.1 release page body is empty, while v2.0.0's carries the full delta. Mirroring the 2.0.1 delta there would help consumers who arrived via the install docs (which links to the GitHub releases page) update: fixed as of 05.21.26 🙏

Versioning: The change is correctly categorized as breaking-change, but that wasn't considered in the semver bump (patch: 2.0.0 → 2.0.1).

Workaround for binary-only consumers: Pulling vault from releases.hashicorp.com instead of via COPY --from=hashicorp/vault avoids the capability requirement, since the zip distribution doesn't carry caps. Sample replacement:

ARG TARGETARCH
ARG VAULT_VERSION=2.0.1
RUN curl -sL -o /tmp/vault.zip \
      https://releases.hashicorp.com/vault/${VAULT_VERSION}/vault_${VAULT_VERSION}_linux_${TARGETARCH}.zip \
 && unzip -q /tmp/vault.zip -d /usr/local/bin/ \
 && rm /tmp/vault.zip

This gets vault 2.0.1 into the image without needing IPC_LOCK granted at runtime.

Happy to help if any follow-up testing is useful.

[peikk0]

A bugfix release should never include breaking changes. This change should be reverted and delayed until v3.

[heatherezell]

A bugfix release should never include breaking changes. This change should be reverted and delayed until v3.

I understand your frustration and I apologize for the inconvenience. The release process ran into some hiccups. We will resolve this as fast as we can. Thanks for your patience!