Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support compose "cap_add: [IPC_LOCK]" #1007

Closed
troyready opened this issue Aug 2, 2022 · 2 comments
Closed

Support compose "cap_add: [IPC_LOCK]" #1007

troyready opened this issue Aug 2, 2022 · 2 comments
Labels
question Further information is requested

Comments

@troyready
Copy link

Description

I'd like to be able to run a container that requires the IPC_LOCK capability (specifically HashiCorp's Vault) and it appears that cap_add: [IPC_LOCK] on the compose file service is ignored (based on the app's error "Failed to lock memory: cannot allocate memory ... This usually means that the mlock syscall is not available.")

This same issue occurs when using lima nerdctl compose up (using the default VM template) or docker-compose (using the docker VM template).

To reproduce (currently tested using lima v0.11.2):

limactl start default
mkdir -p volumes/{config,file,logs}

cat > volumes/config/vault.hcl << EOF
storage "file" {
  path = "/vault/file"
}

listener "tcp" {
  address = "127.0.0.1:8200"
  tls_disable = 1
}

EOF

cat > docker-compose.yml << EOF
version: '2'
services:
  vault:
    image: vault
    container_name: vault
    ports:
      - "8200:8200"
    restart: always
    volumes:
      - ./volumes/logs:/vault/logs
      - ./volumes/file:/vault/file
      - ./volumes/config:/vault/config
    privileged: true
    cap_add:
      - IPC_LOCK
    entrypoint: vault server -config=/vault/config/vault.hcl

EOF

lima nerdctl compose up
@AkihiroSuda
Copy link
Member

Does it work with this?

lima sudo systemctl enable --now containerd
lima sudo nerdctl compose up

or

lima sudo systemctl enable --now docker
lima sudo docker-compose up

@troyready
Copy link
Author

Ah, yes, that's exactly it. Thanks a ton @AkihiroSuda for pointing me in the right direction.

For anyone else following along in the future, this is expected behavior with running the containers as non-root by default. When more permissions are needed, it's fairly simple to modify the docker template to remove the parts that make it non-root and share the root (/var/run/docker.sock) socket instead (incorporating a fix to ensure the VM user has access to the socket)

@AkihiroSuda AkihiroSuda added the question Further information is requested label Aug 3, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
question Further information is requested
Projects
None yet
Development

No branches or pull requests

2 participants