This page covers common problems encountered when deploying and operating the Wazuh Docker Stack, with diagnostic commands and resolution steps for each issue. Problems are grouped by symptom — useDocumentation Index
Fetch the complete documentation index at: https://mintlify.com/rsol9000-01/wazuh/llms.txt
Use this file to discover all available pages before exploring further.
docker compose ps and docker compose logs to identify which container is unhealthy, then jump to the relevant section below.
Indexer fails to start — vm.max_map_count too low
Indexer fails to start — vm.max_map_count too low
Symptom: The Cause: OpenSearch (which powers the Wazuh Indexer) requires the Linux kernel parameter
wazuh.indexer container exits immediately after starting. Logs contain the message:vm.max_map_count to be at least 262144. The default value on most Linux distributions is 65530.Fix:wazuh-dev.sh server up automatically sets vm.max_map_count=262144 before starting the stack. If you start the stack directly with docker compose up -d, you are responsible for setting this parameter first.Dashboard cannot connect to Manager API
Dashboard cannot connect to Manager API
Symptom: After logging into the Dashboard at Fix:Run Or manually restart just the Dashboard after verifying the credentials match:
https://<host>:6443, a banner appears: “Could not connect to the Wazuh API” or the Wazuh plugin shows no data.Cause: config/wazuh_dashboard/wazuh.yml contains stale or incorrect API credentials or URL. This file is the Dashboard’s configuration for reaching the Manager REST API.Diagnosis:wazuh-dev.sh to re-sync wazuh.yml from .env and restart the Dashboard:Remember: the
$ character is not allowed in API_PASSWORD or API_USERNAME. If either value contains $, wazuh-dev.sh will reject it — choose a password without that character.Agent not appearing in Dashboard
Agent not appearing in Dashboard
Symptom: An agent was enrolled but shows “Never connected” in the Dashboard, or the agent does not appear in the agents list at all.Cause: Network connectivity issues between the agent and the Manager on ports Fix:
1514 (event forwarding) or 1515 (enrollment), or a WAZUH_MANAGER_SERVER misconfiguration inside the agent container.Diagnosis:- Ensure ports
1514and1515are open in your firewall — see Security forufwexamples. - Verify
WAZUH_MANAGER_SERVERin.envor the agentdocker-compose-agent.ymlpoints to the correct IP or hostname of the Manager host. Indocker-compose.yml, the agent is configured withWAZUH_MANAGER_SERVER=wazuh.manager(the Docker service hostname) — this works when agent and Manager share the same Compose network. For remote agents, set this to the Manager host’s actual IP or FQDN. - If agents appear with “Never connected,” verify the Manager
wazuh-authddaemon is running (port1515) and that<use_password>no</use_password>or the correct PSK is set inwazuh_manager.conf.
Certificate errors between services
Certificate errors between services
Symptom: Manager or Dashboard container logs contain TLS handshake errors such as:Cause: Certificates were not generated, the node names in Verify node name alignment:Open
certs.yml do not match the actual Docker service hostnames, or the cert/key pair is mismatched.Fix:Regenerate all certificates from scratch:config/certs.yml (used by generate-indexer-certs.yml) and confirm the node names match the Docker service hostnames exactly:- Indexer node name must match the
hostnamefield indocker-compose.yml—wazuh.indexer - Manager node name —
wazuh.manager - Dashboard node name —
wazuh.dashboard
wazuh-dev.sh server up always regenerates certs before starting the stack, so running it is equivalent to the manual steps above.Indexer API returns 401 Unauthorized
Indexer API returns 401 Unauthorized
wazuh-dev.sh exits with "$ character not allowed"
wazuh-dev.sh exits with "$ character not allowed"
Symptom: Running orCause: The Update
sudo bash scripts/wazuh-dev.sh server up prints:API_PASSWORD or API_USERNAME value in .env contains a $ character. The script uses sed to inject these values into config/wazuh_dashboard/wazuh.yml; a $ in the replacement string is interpreted as a back-reference by sed and causes the substitution to fail or produce incorrect output. The script validates this upfront and exits early.Fix:Edit .env and choose a new password for API_PASSWORD (and/or API_USERNAME) that does not contain $:.env with the new value, then re-run:Docker socket permission denied (agent)
Docker socket permission denied (agent)
Symptom: The Cause: The agent container joins the host’s Fix:Update Then restart the agent:
wazuh.agent container fails to start or the docker-listener wodle logs show permission errors accessing /var/run/docker.sock:docker group via group_add: ["${DOCKER_GID}"] in docker-compose.yml. If DOCKER_GID in .env does not match the actual GID of the docker group on the host, the container’s process will not have permission to read the socket.Diagnosis:DOCKER_GID in .env to match the host value:wazuh-dev.sh auto-detects the Docker GID using getent group docker | cut -d: -f3 and exports it before running docker compose up. If you use wazuh-dev.sh, the GID mismatch is resolved automatically at deploy time.High memory usage / OOM kills
High memory usage / OOM kills
Symptom: The host runs out of memory; Docker kills one or more containers (visible in Fix:
dmesg as OOM kill events). docker stats shows the Indexer consuming most available RAM.Cause: The Wazuh Indexer (OpenSearch) JVM heap is set to 1g/-Xms1g -Xmx1g via the OPENSEARCH_JAVA_OPTS environment variable in docker-compose.yml. Under load — many agents, high event throughput, or large indices — total memory consumption can significantly exceed the JVM heap allocation due to OS page cache and native off-heap buffers.Diagnosis:-
Set resource limits — uncomment the
deploy.resources.limitsblock indocker-compose.ymlfor each service. Example for the Indexer: -
Tune the JVM heap — adjust
OPENSEARCH_JAVA_OPTSindocker-compose.ymlto match available RAM (rule of thumb: no more than 50% of host RAM, max 31 GB): - Minimum host RAM recommendation: 8 GB for the full stack (Manager + Indexer + Dashboard + Agent). 16 GB is recommended for production workloads with more than 50 agents.
-
Apply changes and restart:
Wazuh Dashboard takes a long time to load
Wazuh Dashboard takes a long time to load
Symptom: After starting the stack, the Dashboard at Resolution:Wait for the Indexer cluster health to reach
https://<host>:6443 takes 1–2 minutes to respond or shows a blank page / loading spinner before becoming usable.Cause: This is expected behavior on first start. The OpenSearch (Indexer) initialization sequence — security plugin bootstrapping, index template loading, and cluster health check — must complete before the Dashboard can establish a working connection. The Dashboard’s internal health check endpoint runs on port 5601 inside the container (mapped to host port 6443) and is configured with retries: 10 and interval: 10s, giving OpenSearch up to ~100 seconds to become ready.Diagnosis:green status before considering the Dashboard broken. If the Dashboard is still unreachable after 5 minutes: