Troubleshooting

Fix "Have not found any log file for sshd jail"

fail2ban refuses to start because a jail's logpath points to a file that doesn't exist. On Debian 12 this happens right after apt install fail2ban. The fix takes two lines.

Updated 7 min readChecked against fail2ban 1.1.1

Have not found any log file for sshd jail means the jail's logpath (by default /var/log/auth.log) doesn't exist, so fail2ban won't start. On Debian 12 there is no rsyslog, so SSH logs go only to the systemd journal. Fix it by adding backend = systemd to the [sshd] section of /etc/fail2ban/jail.local, making sure python3-systemd is installed, and restarting fail2ban.

/etc/fail2ban/jail.local
[sshd]
enabled = true
backend = systemd
bash
sudo apt install python3-systemd
sudo fail2ban-client -t
sudo systemctl restart fail2ban

The exact error messages#

The wording depends on your fail2ban version. All of them mean the same thing:

Version Message
0.11.x, 1.0.x, 1.1.0 ERROR Failed during configuration: Have not found any log file for sshd jail
1.1.1+ Have not found any log file for 'sshd' jail.
1.1.1+, switched automatically Have not found any log file for 'sshd' jail. Jail will monitor systemd journal. (warning only)
1.1.1+ with skip_if_nologs = true Jail 'sshd' skipped, because of missing log files.
All, per missing path No file(s) found for glob /var/log/auth.log (notice)

As a service, the failure shows up as fail2ban.service: Main process exited, code=exited, status=255/EXCEPTION. Startup configuration errors exit with code 255, and the unit is set not to restart on 255, so it stays down. See exit code 255 for that side of it.

Quick diagnosis#

bash
ls -l /var/log/auth.log /var/log/secure          # does the log file exist?
systemctl is-active rsyslog                       # is anything writing classic log files?
sudo journalctl -u ssh -u sshd -n 5               # are SSH logs in the journal?
python3 -c "import systemd.journal" && echo OK    # can fail2ban read the journal?
fail2ban-client --version

If the file is missing and the journal has the SSH lines, you need the systemd backend. If the file exists but under another name, you need a different logpath.

Cause 1: no rsyslog, logs live in the journal (Debian 12 and minimal images)#

Debian 12 "bookworm" no longer installs rsyslog by default, so /var/log/auth.log is never created. Its fail2ban 1.0.2 package only sets [sshd] enabled = true, and the stock sshd jail reads logpath = %(sshd_log)s, which is /var/log/auth.log. Result: the service fails on a fresh install. Minimal cloud and container images of other distributions behave the same way.

Fix: read the journal. Add backend = systemd to the jail. The sshd filter already contains a journalmatch, so logpath is ignored:

/etc/fail2ban/jail.local
[sshd]
enabled = true
backend = systemd

The systemd backend needs the Python bindings for libsystemd (python3-systemd on Debian and Ubuntu; python3-systemd on Fedora and EPEL too). Without them the jail fails with Failed to initialize any backend for Jail 'sshd', preceded in the log by Backend 'systemd' failed to initialize due to No module named 'systemd'.

After a restart the jail status shows Journal matches: instead of File list::

output
$ sudo fail2ban-client status sshd
Status for the jail: sshd
|- Filter
|  |- Currently failed:	2
|  |- Total failed:	6
|  `- Journal matches:	_SYSTEMD_UNIT=sshd.service + _COMM=sshd + _COMM=sshd-session
`- Actions
   |- Currently banned:	1
   |- Total banned:	1
   `- Banned IP list:	203.0.113.42

On Debian and Ubuntu the SSH unit is ssh.service, and Debian 13's package sets journalmatch = _SYSTEMD_UNIT=ssh.service + _COMM=sshd. Either way, the _COMM= terms match the SSH processes, so the default works. More on journal jails in backends and the systemd journal.

Alternative: install rsyslog. sudo apt install rsyslog brings back /var/log/auth.log and the file backend works unchanged. It duplicates every log message on disk, though, so the journal backend is the cleaner choice.

Newer packages already avoid this problem. Debian 13 and Ubuntu 24.04+ ship backend = systemd for sshd, and upstream 1.1.1's paths-debian.conf sets sshd_backend = systemd.

Cause 2: logpath is wrong for this distribution or app#

The jail file exists, just not at the path in logpath. Classic examples:

  • A Debian tutorial's logpath = /var/log/auth.log copied to Rocky or AlmaLinux, where SSH logs to /var/log/secure. Remove the logpath line and let paths-fedora.conf supply the right value.
  • Nginx or Apache logging per virtual host, e.g. /var/log/nginx/example.com.error.log, while the jail expects /var/log/nginx/error.log.
  • An app such as Nextcloud, Vaultwarden or Jellyfin writing to a path you set in its own config.

Find the real file, then set it in the jail. Globs and several lines are allowed:

/etc/fail2ban/jail.local
[nginx-http-auth]
enabled = true
logpath = /var/log/nginx/*error.log
          /srv/www/logs/error.log

Check what the jail actually monitors:

output
$ sudo fail2ban-client get sshd logpath
Current monitored log file(s):
`- /var/log/auth.log

No file is currently monitored is the answer for a jail with backend = systemd. That's expected for journal jails like sshd, which have no files. For a file-based jail it means none of the logpath patterns matched when the jail started, or the jail is on the journal backend by mistake.

Cause 3: the service doesn't log yet#

Some services only create their log file on the first request or the first error. A fresh nginx install may have no error.log until something goes wrong, and a mail server may log only once it receives mail. Create the file empty, with the owner the service expects, and fail2ban starts watching it:

bash
sudo touch /var/log/nginx/error.log
sudo chown www-data:adm /var/log/nginx/error.log
sudo systemctl restart fail2ban

Cause 4: fail2ban runs in a container#

If fail2ban runs in Docker (for example crazymax/fail2ban or linuxserver/fail2ban), paths in jail.local refer to the container's filesystem. Bind-mount the host's log directory into the container and use the in-container path:

docker-compose.yml (crazymax/fail2ban layout)
services:
  fail2ban:
    volumes:
      - /var/log:/var/log:ro
      - ./data:/data

For journal jails inside a container you also need the journal mounted (for example /var/log/journal:/var/log/journal:ro) and a python3-systemd build in the image. Full setup in fail2ban with Docker.

New in 1.1.1: skip_if_nologs and systemd_if_nologs#

fail2ban 1.1.1 adds two jail options so one missing log no longer takes down every jail:

  • systemd_if_nologs (default true): if the jail uses backend = auto, no logpath file exists, and the jail or its filter defines a journalmatch, fail2ban switches that jail to the systemd backend and logs a warning instead of failing.
  • skip_if_nologs (default false): if set to true and no log file is found (and no switch to systemd happened), the jail is skipped with a warning and fail2ban starts the other jails.
/etc/fail2ban/jail.local
[DEFAULT]
skip_if_nologs = true

Use skip_if_nologs for jails whose service may not be installed on every server, for example when one jail.local is deployed to many hosts. On 1.1.0 and older these options are silently ignored, so use the explicit backend = systemd fix there.

Confirm it's fixed#

bash
sudo fail2ban-client -t
sudo systemctl restart fail2ban
sudo systemctl status fail2ban --no-pager
sudo fail2ban-client status sshd

fail2ban-client -t should print OK: configuration test is successful, the service should be active (running), and the jail status should show your file list or journal matches. Then fail a login from another address and check Total failed goes up, as described in fail2ban not banning.

FAQ#

Why does fail2ban say no log file for sshd jail on Debian 12?#

Debian 12 doesn't install rsyslog, so /var/log/auth.log never exists, yet the sshd jail looks for it. Add backend = systemd under [sshd] in /etc/fail2ban/jail.local, install python3-systemd, and restart fail2ban. The jail then reads SSH failures from the systemd journal.

What does "No file is currently monitored" mean?#

It's the answer of fail2ban-client get <jail> logpath when the jail watches no files. For a jail using backend = systemd that's normal, since it reads the journal. For a file-based jail it means no logpath pattern matched an existing file when the jail started.

What does "Failed to initialize any backend for Jail 'sshd'" mean?#

The backend the jail asked for couldn't load. With backend = systemd it almost always means the Python systemd bindings are missing. Install python3-systemd and restart. With backend = pyinotify, install python3-pyinotify or use backend = auto.

Should I install rsyslog or use the systemd backend?#

Use the systemd backend. It reads the same messages directly from the journal without writing a second copy to disk, and it's what current Debian, Ubuntu and upstream fail2ban configure for SSH. Install rsyslog only if other tools on the server need classic text log files.

Can fail2ban skip a jail whose log file is missing?#

Yes, from fail2ban 1.1.1. Set skip_if_nologs = true for the jail, or in [DEFAULT], and fail2ban skips that jail with a warning instead of refusing to start. Version 1.1.1 also switches backend = auto jails to the journal automatically when they have a journalmatch.

Spotted something wrong or out of date? Tell us — every page is checked against the current fail2ban release.