Common Issues

Many questions and issues have already been addressed in the GitHub Issues tab. Please use the search bar to check if your question has already been answered.

Most API-related questions or errors are due to misconfigurations. Make sure to carefully read the documentation and use the search function. If you find something missing, feel free to open a Pull Request to improve the docs.

OpenCTI and MISP & every self-hosted instance

For certificate issues, ensure the correct certificate is installed on your machine.
Disabling SSL verification is possible but not recommended.

Disabling some engines

If you want to disable certain engines, make sure you set the correct variable as described here.

GitHub Docker Image Errors

If you encounter errors with the GitHub Docker image, ensure you are authenticated to the GitHub Docker registry. Refer to the official documentation for guidance.

Where are the logs?

By default, logs generated by Cyberbro are stored inside the Docker container at /var/log/cyberbro, which is mapped to the logs directory in the Cyberbro folder on your host machine. However, you can configure the log storage location by adjusting the volume mapping in your Docker configuration.

For example, in your docker-compose-custom.yml:

services:
    web:
        # ... other configuration ...
        volumes:
            - ./logs:/var/log/cyberbro

This configuration ensures that:

• ./logs:/var/log/cyberbro: Maps the logs directory on your host machine to /var/log/cyberbro inside the container. You can change ./logs to any directory you prefer for storing logs.

Note

Persisting logs is useful for troubleshooting and monitoring.  
Make sure the `logs` directory exists on your host, or Docker will create it automatically.

For more details on volume mappings and other advanced deployment options, see the Advanced options for deployment documentation.

Where is the database?

By default, the database used by Cyberbro is stored in the data directory inside the Docker container at /app/data/results.db, which is mapped to the data directory in the Cyberbro folder on your host machine. You can configure the database storage location by changing the volume mapping in your Docker configuration to point to a different directory if needed.

Docker database permission issues

If Cyberbro starts but cannot read or write results.db (permission denied), the fastest recovery is usually:

1. Stop the stack.
2. Remove volumes/bind-mounted state related to data (and optionally logs).
3. Redeploy the container.

For most users, Cyberbro history is not critical data, so resetting volumes is often acceptable.

If you need to keep history, copy results.db first, then fix ownership/permissions on the host and redeploy.

In most deployments, Cyberbro handles ownership migration automatically for the cyberbro runtime user (starting with v0.13.0), so most users are not affected. Residual permission issues are more likely on hardened hosts, for example with SELinux enabled or equivalent host-level security policies.

Note

If you are migrating from older root-based containers, permission conflicts can happen on existing bind mounts. A clean redeploy is the simplest approach; manual ownership fix remains possible when history must be preserved.

My API keys seem to be ignored or not stored

Danger

Ensure your .env file is present and values are correctly named (uppercase). Cyberbro now uses environment variables only.