Troubleshooting and Recovery

Enterprise

Bacula Enterprise Only

This solution is only available for Bacula Enterprise. For subscription inquiries, please reach out to sales@baculasystems.com.

First Login

On first access, BWeb runs a welcome wizard to connect to Bacula and the Catalog. This step must be completed by a user with administrator privileges (Bacula Admins by default). If a non-administrator user attempts the first login, BWeb may return HTTP 500.

If this happens, log in with a user mapped to Bacula Admins (or your configured admin role), finish the wizard, and then validate access for non-admin users.

Log Files

BWeb errors are typically logged at:

  • /opt/bacula/working/bweb-error.log

OAuth2-Proxy errors are typically logged at:

  • /var/log/oauth2-proxy-error.log

  • /var/log/oauth2-proxy.log

To display OAuth2-Proxy errors in the web pages, enable the parameter show_debug_on_error.

Common Symptoms

  • Redirect loop to login page: usually a mismatch in redirect URI, issuer URL, cookie settings, or proxy headers.

  • Login succeeds but user has no permissions: missing or incorrect group/role claims in token.

  • HTTP 500 after authentication: first-login wizard not completed by an admin-mapped user.

  • Immediate logout after login: system time skew, invalid session cookie settings, or token validation failures.

Fallback to Local Login

It is recommended to keep a local admin user with a password so that you can access BWeb if OIDC/OAuth2 integration is disabled for any reason.

sudo adduser admin
sudo passwd admin

If you need to disable OAuth2-Proxy, stop the service and re-enable BWeb to listen on its public address by editing /opt/bweb/etc/httpd.conf and commenting out the server.bind line.

SSL Certificate

If you encounter HTTP 500 errors when using a custom or self-signed certificate, OAuth2-Proxy may reject the certificate. You can disable certificate verification by setting:

# In /opt/bweb/etc/oauth2-proxy.cfg
ssl_insecure_skip_verify = true

Since BWeb is typically served only on 127.0.0.1, this can still be acceptable for internal use, but a valid certificate is recommended.

Use this only for diagnostics or controlled internal environments. Re-enable certificate validation as soon as possible.

OAuth 2.0 Access Token

If authentication fails, first verify that the access token includes the expected groups claim. Most IdPs provide a token preview capability. In Okta, see Okta Configuration for details.

When available, decode a real runtime token and validate:

  • Issuer (iss) matches oidc_issuer_url.

  • Audience (aud) includes the expected client.

  • Group/role claim is present and contains values mapped in BWeb.

Go back to: Authentication via OpenID Connect/OAuth 2.0 and Single Sign-On.