Troubleshooting¶
| Platform | Log file |
|---|---|
| Linux | /var/log/drovio-server/drovio-server.log |
| Windows | C:\ProgramData\Drovio\Drovio Server\Logs\drovio-server.log |
The log file is always the first place to look. Every section below tells you what to search for.
Administration panel is unreachable¶
-
Check that the service is running. See Start and stop the service for your platform. If it is not running, the log file tells you why.
-
Check the port. By default, Drovio Server listens on port
8090(HTTP) or the port you set ashttps_portwhen HTTPS is enabled. Make sure no other process is using that port. -
Check reachability. If you are accessing the panel from another machine, verify that the host responds (
ping) and that no firewall blocks the port.
Drovio app cannot connect¶
The Drovio app needs the URL set in
http.url. If it is wrong or unreachable
from the client network, the app shows a connection error.
- Verify that the URL resolves to the server and that the port is open.
- If HTTPS is enabled, make sure the full certificate chain is in the keystore. A missing intermediary certificate is the most common cause: browsers may tolerate it, but the Drovio app does not. See Enable HTTPS, step 5.
Database connection errors¶
The log shows Failed to start Drovio Server or query failures shortly after
startup.
- Verify that PostgreSQL is running and reachable from the server.
- Check
database.host,database.port,database.nameand the credentials in the configuration. - If you use
ssl_modeset toverify-caorverify-full, make sure the CA certificate path is correct. - In a High Availability setup, check that the pool
sizes across all instances do not exceed
max_connectionson PostgreSQL.
HTTPS certificate rejected¶
After enabling TLS, the Drovio app or a browser refuses the connection.
The output must show your certificate and the intermediary certificate. If the intermediary is missing, re-import the full chain. See Enable HTTPS.
The log line SSL certificate reloading has failed means SIGUSR2 was sent but
the keystore could not be read. The previous certificate stays active.
SSO authentication fails¶
The log contains Could not authenticate user (SSO) or Can't build SSO
configuration.
- Callback URL mismatch. The redirect URI registered with your identity
provider must match exactly:
https://your-server/sso/auth/callback/saml(SAML) orhttps://your-server/sso/auth/callback/oidc(OIDC). See SSO. - IdP metadata unreachable. If
idp_metadata_pathpoints to a URL, the server must be able to reach it at startup. A local file avoids this dependency. - Both SAML and OIDC enabled. Only one can be active. The log says
SAML and OIDC can't be both enabled.
LDAP authentication fails¶
The log prefixes every LDAP failure with the cause:
| Log message | What to check |
|---|---|
service account bind failed |
service_account_dn and password |
search failed |
base and search_filter |
user not found |
base and search_filter (too restrictive) |
matched multiple entries |
search_filter (too broad) |
user bind failed |
User credentials or account status (disabled, locked, expired) |
If you use ldap:// instead of ldaps://, the log warns once that credentials
are sent unencrypted. Prefer LDAPS (port 636) with
ca_certificate_path.
Still stuck?
Reach out to support@drovio.com. Attaching the log file speeds up diagnosis considerably.