Troubleshooting and Recovery
EnterpriseBacula 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) matchesoidc_issuer_url.Audience (
aud) includes the expected client.Group/role claim is present and contains values mapped in BWeb.
See also
Previous articles:
Go back to: Authentication via OpenID Connect/OAuth 2.0 and Single Sign-On.