Troubleshooting
Common issues, debug commands, and solutions.
Installation Issues
Docker daemon not running
ERROR: Docker daemon is not running.sudo systemctl start dockerPermission denied on Docker socket
Got permission denied while trying to connect to the Docker daemon socketAdd your user to the docker group:
sudo usermod -aG docker $USER
# Log out and back inConnection Issues
Worker can't enroll
- Verify the master is reachable from the worker at
CONTEXTBAY_MASTER_URLover plain HTTP (the one-time/api/enrollcall happens before the mesh is up):curl -v $CONTEXTBAY_MASTER_URL/api/health - Open the Hosts page in the master UI and check the recent enroll-attempts log for this host — each attempt is tagged with a reason code (
bad_secret,invalid_token,expired,already_consumed,rate_limited,not_configured,mesh_mint_failed) so you can see exactly why it was rejected. - Tokens are short-lived (~24h). If the worker took longer than the token TTL to start, click Regenerate token and re-run the install snippet.
- Confirm
CONTEXTBAY_SHARED_SECRETon the worker matches[mesh].shared_secreton the master (rejection reasonbad_secret).
Worker enrolled, gRPC won't connect
- After enrollment all gRPC traffic flows over Headscale on the address in
CONTEXTBAY_MASTER_ADDR(typically<MASTER_MESH_IP>:7481). The worker uses an embedded tsnet client — there is notailscaleCLI inside the container. Check mesh state from the master UI instead.<MASTER_MESH_IP>is the master's address on the Headscale mesh, in the100.64.0.0/10CGNAT range — the master is always assigned100.64.0.1, so the shape is the same on every install. - Open Settings → Mesh in the master UI, or call
GET /api/mesh/statusandGET /api/mesh/nodes. A worker that finished enroll but can't dial gRPC will show up as a mesh node but no heartbeat. - If you're on a single-node dev install with
mesh.mode = direct, setCONTEXTBAY_MASTER_ADDRon the worker to the master's LAN address (this mode is dev-only).
Web UI not loading
- Check the master is running:
docker logs contextbay - Verify port 7480 is not in use:
ss -tlnp | grep 7480 - Try the health endpoint:
curl http://localhost:7480/api/health
Database Issues
SQLite locked
database is lockedEnsure only one master instance runs per database file. ContextBay uses WAL mode to minimize locking, but concurrent access from multiple processes is not supported.
Migration errors
- Check logs for the specific error
- Back up your database file
- The migration system tracks applied migrations and will retry failed ones on next startup
Module Issues
Discord bot not responding
- Verify
discord.enabled = truein config - Verify bot token is valid and Message Content Intent is enabled in the Developer Portal
- Verify
guild_idmatches your Discord server - Check master logs for Discord-related errors
Ollama (cb-ollama) AI not responding
- Check that the cb-ollama sub-container is healthy:
curl http://cb-ollama:11434/api/tags # or via the master UI: Admin -> Sub-containers -> cb-ollama - For an external Ollama, override
CONTEXTBAY_AI_OLLAMA_ENDPOINTSwith a comma-separated list of full URLs (includinghttp://).
RAG search returns no results on a fresh deploy
cb-ollama auto-pulls the embedding model on first boot. Until the pull finishes the index is empty — wait for the master log line:
ollama bootstrap: model ready model=nomic-embed-textThen trigger a re-index from Knowledge → Settings → Re-index.
Model not found
The default Ollama chat model is llama3:8b (configurable via [ai].default_model). Pull it (or your override) on the cb-ollama instance:
docker exec cb-ollama ollama pull llama3:8bn8n logs show 403 on /api/v1/variables
Expected on community / free n8n. The Variables endpoint is an enterprise-only feature; CB detects this and gracefully skips variable sync. Everything else (workflows, credentials, webhooks) keeps working.
Master crashes on startup after wiping only one volume
The three CB volumes form a chain (contextbay-data,contextbay-portainer-data,cb-n8n_contextbay-n8n-data). Removing one in isolation leaves the others with stale credentials. For a fresh install, wipe all three together.
Performance
High memory usage
- Reduce the number of metrics retained with shorter retention periods
- Use PostgreSQL instead of SQLite for large deployments
- Reduce the number of concurrent AI tasks
Slow dashboard loading
- Reduce the time range on time series panels
- Limit the number of panels per dashboard
- Ensure metrics queries include a
node_idfilter
Debug Logging
Viewing logs
# Docker
docker logs contextbay
docker logs contextbay-worker
# Binary (logs go to stderr by default)
./contextbay-master 2>&1 | tee /var/log/contextbay.logEnable debug logging
[logging]
level = "debug"
format = "json"Or via environment variable: CONTEXTBAY_LOGGING_LEVEL=debug
Getting Help
- Check the Architecture and Configuration references first.
- The source repository is a passive code mirror — issues and roadmap live in the in-product Project Planner (
/planner), not on GitHub.

