I'm running HashiCorp Vault 1.15.0 with Docker Compose on Ubuntu ARM64. The container exits with an IPC_LOCK warning and reports that 0.0.0.0:8200 is already in use, even though lsof, netstat, ss, Docker container listings, and network listings show nothing using the port. Restarting Docker, pruning containers and networks, and changing the host mapping to 8201:8200 did not initially help. The Vault listener still binds to 0.0.0.0:8200 inside the container, while the host port is mapped separately. My configuration also sets VAULT_DISABLE_MLOCK and disable_mlock. What is the correct Compose syntax for adding IPC_LOCK, and how can I remove stale Docker container state that may still reserve the port?
3 Answers
The port tools only show processes listening on the host network namespace. A stale or exited Docker container can still have metadata associated with a published port. Check every container, including stopped ones, with docker ps -a and inspect the Ports field. If the old container is still present, remove it explicitly with docker rm -f , then recreate the service with docker compose up -d. Changing 8200:8200 to 8201:8200 only changes the host-side port; Vault will still listen on port 8200 inside the container.
Add the capability as a service property in Compose, not as a command-line-style option: cap_add: ["IPC_LOCK"]. For example: services: vault: cap_add: - IPC_LOCK. That allows Vault to use mlock. Alternatively, keeping VAULT_DISABLE_MLOCK=1 and disable_mlock=true is valid if you intentionally want to run without that capability; the warning itself is not what causes the port failure.
That fixed the IPC_LOCK warning. I can now focus on the listener error separately.
Also check the Vault configuration itself for formatting or parsing problems. The listener address should remain 0.0.0.0:8200 inside the container, and the host mapping can be 8201:8200. Make sure the HCL has no accidental characters or malformed spacing, then validate the mounted configuration before starting Vault. The IPC_LOCK message and the bind error are separate problems, so solve them independently.
The issue turned out to be an old container that was not removed by the cleanup commands. docker rm -f on the specific container cleared the stale state, and the service started normally afterward.