bacula director failed "Authentication failed" backup job error

TL;DR

Compare the daemon identities as a set, not one file at a time: the director, file daemon and storage daemon each hold a name and a shared password for the others, and every pair must match exactly. Restart the daemons in order after any config change and test with bconsole status for each daemon. Authentication failed between Bacula daemons is a configuration mismatch far more often than an attack or a network block.

bacula director failed "Authentication failed" backup job error

Use this when

• bconsole or a backup job reports Authentication failed when the director contacts a client or storage daemon.
• The failure started after a password rotation, a client rename, or a Bacula upgrade.
• One client or one storage daemon fails while others authenticate normally.

Not for this skill when

• A web interface or API login for an operator fails. That is an application account problem, not daemon authentication.
• No daemon can be reached at all on its port. Fix network or daemon startup first, then authentication.

Steps

1. Identify which pair fails: run status for the director, then status client for the affected file daemon and status storage, and note which connection reports the authentication failure. The failing pair narrows the fix to two config files instead of every daemon in the estate. Verify: the failing daemon pair and direction are named
2. On both sides of that pair, compare the daemon names character for character, including the default suffixes Bacula adds and any fully qualified host parts. Bacula authenticates by name plus password, so a renamed client whose file daemon still presents its old name fails even with the right password. Verify: the presented name and the director record for it match exactly
3. Re-enter the shared password for that pair in both configuration files as the same value taken from your vault, editing the files directly rather than pasting through a terminal that might add characters, and without printing the value to logs or tickets. Verify: both files were updated in the same change window and configuration checks pass
4. Check the connection basics that hide as authentication errors: the director must reach the file daemon on port 9102 and storage on 9103, the file daemon must reach the director for its messages where configured, and a firewall or TLS requirement mismatch can abort the handshake before authentication completes. Verify: each needed port accepts a connection from the director host
5. Restart in order: storage daemon, file daemon, then director, or reload the director configuration if your change policy requires it, because a running daemon keeps using the password it loaded at start. Stale running configuration is the reason many correct edits appear not to work. Verify: all three daemons restart or reload with no configuration errors in their logs
6. Test with bconsole status for the previously failing client and storage, then run the smallest backup job for that client to a scratch pool or with a short retention. Verify: status shows the daemon versions and the test job completes with no authentication messages

Why it happens

Bacula daemons authenticate each other with a shared password tied to a daemon name, configured independently in every daemon that talks to another. There is no central account store to fix in one place, so rotations and renames drift: the director expects one value while a file daemon still presents an old name or password from its own file. TLS settings and version differences can also end the handshake early and get reported in the same bucket. The pair by pair comparison restores a consistent set. Compatibility: Bacula 11, 13 and 15, director, file daemon and storage daemon on Linux and Windows clients, with or without TLS enabled.

Variants and edge cases

Authentication failed after password rotation

Rotation must touch the director entry and the daemon own file for every daemon in the same window. List every config that names the rotated daemon before starting, and expect any missed client to fail exactly this way.

bconsole fails but jobs still run

The console has its own name and password entry in the director configuration and in the bconsole configuration. A console only failure means those two entries drifted, while job daemons are fine.

Authentication failed after client rename

Rename in both places: the operating system hostname does not change Bacula identity by itself. The file daemon name in its own configuration and the client record in the director must change together with a daemon restart.

Provenance

Resolved from the public thread: https://vectle.com/posts/pstcZryxJ003mxXypYq7ROfA