# Dovecot “Too Many Open Files”: Fix on cPanel and DirectAdmin

Source: https://srvscripts.com/guides/dovecot-too-many-open-files/
Updated: 2026-10-07
Publisher: srvScripts (https://srvscripts.com/)

**Short answer:** Dovecot logs “Too many open files” when a process hits its file-descriptor limit (`LimitNOFILE` / `ulimit -n`), and similar-looking errors come from a service `process_limit` or the kernel inotify limits. Read the exact log line first, check the live limit in `/proc/$(pidof dovecot)/limits`, then raise the right one: a systemd drop-in for the fd limit, WHM Mailserver Configuration (cPanel) or a CustomBuild custom `limits.conf` (DirectAdmin) for process limits, and `/etc/sysctl.d/` for inotify.

We ran the checking commands on our lab servers (AlmaLinux 9.8 with cPanel & WHM 11.138, and AlmaLinux 9.8 with DirectAdmin 1.712, both running Dovecot 2.4.5) on 7 October 2026. The lab values quoted below come from those runs. We did not change limits on the lab servers; the change steps are checked against the cPanel, Dovecot and systemd documentation linked below.

## What “Too many open files” means in Dovecot

“Too many open files” is the operating system error `EMFILE`. Dovecot prints it at the end of whatever call failed, for example a line ending in `failed: Too many open files`. Every IMAP or POP3 connection, socket, log pipe and mailbox index uses a file descriptor, so a busy mail server can run out. Three different limits produce errors that admins lump together under this name, and each one has its own fix:

| What you see in the log | Limit that was hit | Where to raise it |
| --- | --- | --- |
| ... failed: Too many open files | Per-process open files (LimitNOFILE, ulimit -n) | systemd drop-in for dovecot.service |
| fd limit (ulimit -n) is lower than required under max. load (X < Y), because of ... | Same fd limit, warned at startup because client_limit needs more | systemd drop-in, or lower the client limit |
| service(imap-login): process_limit (50) reached, client connections are being dropped | Dovecot service process_limit | WHM Mailserver Configuration / DirectAdmin limits.conf |
| fork() failed: ... (ulimit -u N reached?) | Process count (LimitNPROC) | systemd drop-in |
| Inotify instance limit for user ... exceeded, disabling. Increase /proc/sys/fs/inotify/max_user_instances | Kernel inotify instances per user | /etc/sysctl.d/ |
| Inotify watch limit for user exceeded, disabling. Increase /proc/sys/fs/inotify/max_user_watches | Kernel inotify watches per user | /etc/sysctl.d/ |

The startup, process-limit and inotify messages above are quoted from the Dovecot 2.4 source code, so you can grep for them as written. The inotify warnings are not fatal: Dovecot falls back to polling, so IMAP IDLE clients see new mail later, but logins keep working.

## Find the exact error in the logs

Where Dovecot logs depends on the panel and whether rsyslog is installed. Both our labs have `log_path = syslog`. On the cPanel lab there was no `/var/log/maillog` at all, so Dovecot lines were only in the systemd journal. On the DirectAdmin lab they were in `/var/log/maillog`. These two commands cover both cases:

```
# systemd journal (works on both panels)
journalctl -u dovecot --since "-24h" --no-pager | grep -E "Too many open files|fd limit|process_limit|client_limit|ulimit -u|Inotify"

# classic syslog file, if it exists
grep -E "Too many open files|fd limit|process_limit|client_limit|ulimit -u|Inotify" /var/log/maillog
```

Note which `service(...)` name appears (imap-login, imap, pop3, lmtp, auth, anvil). That decides which setting you change. If the only hits are inotify warnings, skip to the inotify section.

## Check the current limits with real commands

Check what the running master process actually got, not what you think the config says. The master starts every child, so children get the same limits:

```
P=$(pidof dovecot)
grep -E "open files|processes" /proc/$P/limits
systemctl show dovecot -p LimitNOFILE -p LimitNPROC -p DropInPaths
ls /proc/$P/fd | wc -l          # descriptors the master has open right now
doveadm service status imap-login   # process_limit, client_limit, process_count
```

To see which Dovecot processes hold the most descriptors:

```
for p in $(pgrep -f "dovecot/"); do
  echo "$(ls /proc/$p/fd 2>/dev/null | wc -l) $(ps -o comm= -p $p)"
done | sort -rn | head
```

And the kernel side:

```
sysctl fs.inotify.max_user_instances fs.inotify.max_user_watches fs.file-nr
doveconf default_client_limit default_process_limit
```

What our two labs returned on 7 October 2026:

| Value | cPanel 11.138 lab | DirectAdmin 1.712 lab |
| --- | --- | --- |
| LimitNOFILE in the unit file | 16364 | 65535 |
| Max open files in /proc/PID/limits | 16364 | 65535 |
| Max processes in /proc/PID/limits | 15220 | 30766 (unit says 22503) |
| default_client_limit / default_process_limit | 1000 / 100 | 12288 / 2048 |
| imap-login process_limit / client_limit | 50 / 500 | 2048 / 1 |
| fs.inotify.max_user_instances | 4096 | 128 (kernel default) |
| Descriptors open by the master | 221 | not counted |

Two things stand out. First, the panels ship very different defaults: cPanel uses a few login processes that each handle many clients, DirectAdmin uses many single-client login processes. Second, the DirectAdmin master had a higher process limit than its unit file set. That is expected: at startup Dovecot raises its own process limit to the sum of all service `process_limit` values when the hard limit allows it.

## Raise the open-files limit on cPanel

On cPanel, `/etc/systemd/system/dovecot.service` is written by cPanel (our lab had `LimitNOFILE=16364` in it). Do not edit that file or the rendered `/etc/dovecot/dovecot.conf`; the header of that file says direct edits are lost when Dovecot is updated. Use a systemd drop-in, which overrides the unit without touching it:

```
mkdir -p /etc/systemd/system/dovecot.service.d
cat > /etc/systemd/system/dovecot.service.d/limits.conf  /etc/sysctl.d/90-dovecot-inotify.conf