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

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.

Applies to AlmaLinux 9 with cPanel & WHM 11.138 or DirectAdmin 1.712, Dovecot 2.4

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 <<'EOF'
[Service]
LimitNOFILE=65535
EOF
systemctl daemon-reload
/usr/local/cpanel/scripts/restartsrv_dovecot

Restarting Dovecot drops every open IMAP/POP3 session. Mail clients reconnect on their own, but do it at a quiet time and tell support staff first.

For the “process_limit reached” message, cPanel documents these WHM fields under Home » Service Configuration » Mailserver Configuration:

• service(imap-login) or service(pop3-login): Maximum Number of Authentication Processes (default 50).
• service(imap) or service(pop3): Maximum Number of Mail Processes (default 512).
• service(lmtp): LMTP Process Limit (default 500).

Raise the value in steps (for example 50 to 100), click Save, and watch the log for a day. Each extra process needs memory and descriptors, so a big jump in process limits can make the fd problem worse. If you need template-level changes that WHM does not expose, cPanel supports a copy of the template at /var/cpanel/templates/dovecot/main.local.

Raise the limits on DirectAdmin

DirectAdmin’s Dovecot unit comes from CustomBuild (/usr/local/directadmin/custombuild/configure/systemd/dovecot.service) and already sets LimitNOFILE=65535. If you need more, the same drop-in as above works, followed by systemctl daemon-reload and systemctl restart dovecot.

Dovecot’s own limits live in /etc/dovecot/conf/limits.conf, which CustomBuild rewrites. On our lab it contained:

default_process_limit=2048
default_client_limit=12288
default_vsz_limit=8GB

To change these so they survive updates, put your copy in CustomBuild’s custom folder for your Dovecot version (2.4 on current builds) and rebuild only the config:

mkdir -p /usr/local/directadmin/custombuild/custom/dovecot/2.4/conf
cp /usr/local/directadmin/custombuild/configure/dovecot/2.4/conf/limits.conf \
   /usr/local/directadmin/custombuild/custom/dovecot/2.4/conf/limits.conf
vi /usr/local/directadmin/custombuild/custom/dovecot/2.4/conf/limits.conf
da build dovecot_conf

Check ls /usr/local/directadmin/custombuild/configure/dovecot/ first. The custom folder must match the version folder CustomBuild uses (our lab had both 2.3 and 2.4), or your file is ignored. Keep default_client_limit below the fd limit, otherwise Dovecot logs the “fd limit (ulimit -n) is lower than required” warning at startup.

Fix inotify limit warnings

Dovecot uses inotify to notice new mail for IMAP IDLE. IMAP processes watching mailboxes open inotify instances, and the kernel counts and limits them per system user. Our DirectAdmin lab had the kernel default of 128, which a server with many IDLE clients can exceed. Count current inotify instances by user:

find /proc/*/fd -lname "anon_inode:inotify" 2>/dev/null | cut -d/ -f3 \
  | xargs -r ps -o user= -p | sort | uniq -c | sort -rn | head

Raise the limits persistently with a sysctl file, then load it:

cat > /etc/sysctl.d/90-dovecot-inotify.conf <<'EOF'
fs.inotify.max_user_instances = 1024
fs.inotify.max_user_watches = 65536
EOF
sysctl --system
sysctl fs.inotify.max_user_instances fs.inotify.max_user_watches

New IMAP processes pick up the higher limit straight away, so no Dovecot restart is needed; processes that already logged the warning keep polling until they exit. On CloudLinux or container hosts the effective values can be capped by the host, so confirm with the last command.

Check that it worked

1. Confirm the new limit is live: grep "open files" /proc/$(pidof dovecot)/limits should show the new number. If it still shows the old one, systemd did not pick up the drop-in (see Common problems).
2. Confirm systemd sees the drop-in: systemctl show dovecot -p DropInPaths should list /etc/systemd/system/dovecot.service.d/limits.conf.
3. For process limits, run doveadm service status imap-login (or imap, pop3, lmtp) and check process_limit and last_drop_warning. A last_drop_warning of 0 means no connections have been dropped since the service started.
4. Check that Dovecot started without the fd warning: journalctl -u dovecot --since "-10min" --no-pager | grep -E "fd limit|Too many open files" should return nothing.
5. Log in from a real mail client, or test IMAP over TLS with openssl s_client -connect mail.example.com:993 -quiet and look for the * OK greeting.
6. Grep the log again after the next busy period. The fix only counts if the messages stop at peak load.

Common problems

• The limit did not change after restart. You probably edited the main unit or forgot systemctl daemon-reload. On cPanel, also check that the drop-in file name ends in .conf and that it has the [Service] header.
• Raising ulimit -n in a shell did nothing. ulimit and /etc/security/limits.conf apply to login sessions. Services started by systemd ignore them, so only LimitNOFILE counts for Dovecot.
• WHM changes vanished. If you hand-edited /etc/dovecot/dovecot.conf, cPanel overwrote it. Use the WHM fields or main.local.
• DirectAdmin settings reset after da build. The custom file is in the wrong version folder, or you edited configure/ instead of custom/.
• The errors are really in Exim or the web server. “Too many open files” from exim, lsphp or httpd needs that service’s own LimitNOFILE; grep the log line for the process name before changing Dovecot.
• Limits keep rising and the server keeps running out. Something may be opening connections in a loop, such as a broken client polling every few seconds or a brute-force run against IMAP. Count connections per IP with doveadm who and block abuse in the firewall instead of raising limits forever.

If the server keeps falling over at peak and you would rather have someone go through it, see Get it fixed.

Official documentation: cPanel: Mailserver Configuration · cPanel: process limit reached in Dovecot · Dovecot 2.4: service configuration · systemd.exec: LimitNOFILE

Related: Dovecot 2.4 Mail Login Failed: Fix Broken Logins on cPanel · DirectAdmin mail delivery problems: forwarder loops, send-limit counting and outbound MX lookups · DirectAdmin Old Certificate After Renewal: 3 Service Fixes · AI Log Analyzer for Server Logs (Apache, Nginx, Exim, MariaDB)

See also: Dovecot 2.4 Mail Login Failed: Fix Broken Logins on cPanel · Exim Log Cheat Sheet: exigrep, exiqgrep, eximstats and Log Flags

Frequently asked questions

Maintenance record

This guide changes servers, data or security settings, so we re-check it against current versions on a fixed schedule. Take a backup or snapshot before you start.

Maintained by

srvScripts editorial team

Supported versions

AlmaLinux 9 with cPanel & WHM 11.138 or DirectAdmin 1.712, Dovecot 2.4

Last full review

7 Oct 2026

Next review

5 Apr 2027

Sources

docs.cpanel.net/whm/service-configuration/mailserver-configuration
support.cpanel.net/hc/en-us/articles/4408796380183-Intermittent-mail-connectivity-issues-due-to-the-process-limit-being-reached
doc.dovecot.org/2.4.1/core/config/service.html
freedesktop.org/software/systemd/man/latest/systemd.exec.html