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

> Fix the fail2ban error "Have not found any log file for sshd jail" on Debian 12 and journal-only systems: switch to backend = systemd or correct the logpath.
>
> Source: https://fail2ban.dev/troubleshooting/no-log-file/ · Updated 2026-10-25 · Checked against fail2ban 1.1.1
> fail2ban.dev is an independent guide, not the official fail2ban project.

`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.

```ini
[sshd]
enabled = true
backend = systemd
```
sudo apt install python3-systemd
sudo fail2ban-client -t
sudo systemctl restart fail2ban
```

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](/troubleshooting/exit-code-255/) for that side of it.

## Quick diagnosis

```bash
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
```

## 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:

```ini
[sshd]
enabled = true
backend = systemd
```

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

```text
$ 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
```

**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:

```ini
[nginx-http-auth]
enabled = true
logpath = /var/log/nginx/*error.log
          /srv/www/logs/error.log
```

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

> **Ubuntu 24.04: file-based jails inherit backend = systemd**
Ubuntu 24.04's `/etc/fail2ban/jail.d/defaults-debian.conf` sets `backend = systemd` in `[DEFAULT]`, so every jail you enable reads the journal and silently ignores `logpath`. For nginx, Apache and other jails that read log files, add `backend = auto` to the jail section. Otherwise they show `No file is currently monitored` and never ban.

## 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 chown www-data:adm /var/log/nginx/error.log
sudo systemctl restart fail2ban
```

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:

```yaml
services:
  fail2ban:
    volumes:
      - /var/log:/var/log:ro
      - ./data:/data
```

## 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.

```ini
[DEFAULT]
skip_if_nologs = true
```

## Confirm it's fixed

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

## 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`.