Review container permissions before adding capabilities ​

Do not add container capabilities solely because another database's setup guide lists them. Coordinator DB's public startup contract does not require CAP_IPC_LOCK or CAP_SYS_NICE. First identify the failing action and its actual error.

Check ordinary access requirements ​

Verify that the process can read its existing configuration and credentials files, write the configured log paths and access the database file location. Relative user and log paths are based on the configuration directory, which can differ from the container's working directory. Confirm listener addresses and published ports separately from filesystem access.

If a server starts but a remote client fails, test the listener and route rather than granting additional process privileges. If a file cannot be read, inspect the mounted path and ownership instead of assuming a memory-lock permission problem.

Keep host policy explicit ​

Container runtime restrictions and host security policy belong to the deployment configuration. Have the host administrator evaluate a capability only when a concrete denied operation requires it. Record the exact denial and the smallest change that resolves it, then repeat startup and a simple SQL request.

A working highly privileged container does not identify which permission was necessary.

See configuration paths, command-line startup and HTTP checks.