"/usr/local/bin/docker-entrypoint.sh: line 97: setcap: not found" in docker logs of vault

[yogesh119905]

Description

We are encountering an issue when starting a Vault Docker container using the 2.0.3 image.

Issue

When the container starts, it immediately fails with the following error:

root@virtplatform:~# docker ps -a
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
b1c9e249a3ed XXX.XXX.XXX./hashicorp/vault:2.0.3 "docker-entrypoint.s…" 10 minutes ago Restarting (127) 42 seconds ago vault

Environment:
1.Vault image version: 2.0.3
2.Deployment method: Docker container
3.OS: Ubuntu 24.04.3 LTS
4.Docker version: 29.1.3

Steps to Reproduce:
1.Pull the 2.0.3 Vault image.
2.Start the container with the existing configuration.
3.Observe that the container fails during startup with the error shown above.

Expected Behavior

The Vault container should start successfully without any errors.

Actual Behavior

The container fails to start and exits with the error mentioned above.

Additional Information
As of now temporary solution is tp that use this variable in docker environment
SKIP_SETCAP=1

Please let us know if any additional logs or configuration details are required to help diagnose the issue.

While checking on docker logs and getting following errors
root@:~# docker logs vault
/usr/local/bin/docker-entrypoint.sh: line 97: setcap: not found
/usr/local/bin/docker-entrypoint.sh: line 97: setcap: not found
/usr/local/bin/docker-entrypoint.sh: line 97: setcap: not found
/usr/local/bin/docker-entrypoint.sh: line 97: setcap: not found
/usr/local/bin/docker-entrypoint.sh: line 97: setcap: not found
/usr/local/bin/docker-entrypoint.sh: line 97: setcap: not found
/usr/local/bin/docker-entrypoint.sh: line 97: setcap: not found
/usr/local/bin/docker-entrypoint.sh: line 97: setcap: not found
/usr/local/bin/docker-entrypoint.sh: line 97: setcap: not found
/usr/local/bin/docker-entrypoint.sh: line 97: setcap: not found
/usr/local/bin/docker-entrypoint.sh: line 97: setcap: not found
/usr/local/bin/docker-entrypoint.sh: line 97: setcap: not found
/usr/local/bin/docker-entrypoint.sh: line 97: setcap: not found
/usr/local/bin/docker-entrypoint.sh: line 97: setcap: not found
/usr/local/bin/docker-entrypoint.sh: line 97: setcap: not found
/usr/local/bin/docker-entrypoint.sh: line 97: setcap: not found
/usr/local/bin/docker-entrypoint.sh: line 97: setcap: not found
/usr/local/bin/docker-entrypoint.sh: line 97: setcap: not found
/usr/local/bin/docker-entrypoint.sh: line 97: setcap: not found
/usr/local/bin/docker-entrypoint.sh: line 97: setcap: not found
/usr/local/bin/docker-entrypoint.sh: line 97: setcap: not found
/usr/local/bin/docker-entrypoint.sh: line 97: setcap: not found
/usr/local/bin/docker-entrypoint.sh: line 97: setcap: not found
/usr/local/bin/docker-entrypoint.sh: line 97: setcap: not found

Could you please help us determine how to resolve this issue? We would also like to know whether this is a known issue with the latest 2.0.3 Vault Docker image or if there are any additional configuration changes required to run this version successfully.

If this is a known issue, please let us know if there is a recommended workaround or if using an earlier image version is advised.

[yogesh119905]

@heatherezell @dosu Could you please help us resolve this issue?

[dosubot]

Hi @yogesh119905, happy to help clarify the situation here.

This issue stems from Vault 2.0.x switching to a non-root user (vault) by default in its Docker image. The entrypoint script still attempts to run setcap to grant the cap_ipc_lock capability to the Vault binary (which prevents sensitive memory from being swapped to disk), but this fails when running as non-root or when the setcap binary isn't available in the image [1].

Your workaround of SKIP_SETCAP=1 is correct and officially supported — it's an explicit check in the entrypoint script designed for exactly this scenario [2].

There is an open fix in PR #32005 that will make the entrypoint automatically detect non-root execution and skip the setcap/chown operations instead of failing [3]. Once that's merged, this should be resolved without needing the environment variable.

In the meantime, your options are:

1. SKIP_SETCAP=1 — what you're already doing; skips the capability grant entirely.
2. --cap-add=IPC_LOCK on your docker run command — if you want Vault to still be able to lock memory pages. Even with SKIP_SETCAP=1, Docker-level capabilities still apply, so Vault can use mlock if the container has IPC_LOCK.
3. VAULT_DISABLE_MLOCK=true in your Vault config or environment — if you're comfortable disabling memory locking entirely (e.g., in dev/test environments).

For production, the recommended combination is SKIP_SETCAP=1 + --cap-add=IPC_LOCK to retain the memory-locking security benefit while avoiding the entrypoint error.

To reply, just mention @dosu.

---

Share context across your team and agents. Try Dosu.

[yogesh119905]

@dosu, Is this issue specific to image 2.0.3, or is the image missing the setcap binary (which is typically provided by the libcap or libcap2-bin package)?

[dosubot]

Good question, @yogesh119905. Based on what I can see in the Dockerfiles, this is likely not specific to 2.0.3 — it's a combination of two factors:

1. The official Vault Dockerfile does not explicitly install libcap (which provides setcap). The Alpine variant only installs su-exec dumb-init tzdata, and the UBI variant only installs tzdata shadow-utils util-linux tar [1]. The image has historically relied on setcap being available in the base image rather than explicitly adding it as a dependency.

2. The switch to non-root USER vault in 2.0.0 made this more visible. When running as non-root, even if setcap were present, the operation would fail with a permissions error. The "not found" error you're seeing suggests the setcap binary is indeed absent from the base image your private registry is pulling.

Interestingly, the development Dockerfiles (in scripts/docker/) do explicitly install libcap [2], but the production image does not — which looks like a packaging oversight.

So to directly answer your question: the setcap binary does appear to be missing from the image, and the issue likely affects all 2.0.x versions (not just 2.0.3). In earlier 1.x versions, the container ran as root and the Alpine base image may have included libcap by default, masking the problem. The combination of the non-root user switch and potential base image changes surfaced it.

Your SKIP_SETCAP=1 workaround remains the right approach until PR #32005 is merged, which will make the entrypoint gracefully handle this scenario.

To reply, just mention @dosu.

---

Share context across your team and agents. Try Dosu.