Random empty folder display with various IMAP clients

(UCS Version 5.2-1 errata38 / Dovecot 2.3.19.1)

We are running in an issue with Dovecot: From time to time, connected IMAP clients fail to display the list of messages in a certain folder. As an example: Thunderbird displays “No messages found” for this folder, while it displays all other folders. Interaction with the Dovecot server is possible, e.g. marking messages as read is handled by the server and shown on other clients.

There is no message in Dovecot’s logs. Restarting the IMAP client may display the messages in a folder, but hide other folders for the same user/client or a different one.

I assume that we are running into a limitation of the number of e-mail folders watched. We have about 150 GB of e-mail with only 10 users, but thousands of folders and multiple clients simultaneously active.

Is there any hint which parameter I could tweak?

Cheers, Rainer

1 Like

Hello Rainer,

from your tellings the following article / behaviour comes in my mind:

If you’re using IMAP IDLE and have a lot of clients connected, with watches on various folders, it’s possibel that you exceed the common default limit of 32768 directory watches. You should be able to simply increase the limit as described in the linked guide.

Kind regards,
Fabian

Hello,

we are experiencing similar issues with our mail server and also with a customer’s mail server. However, it doesn’t seem to be related to the inotify instance limit mentioned above. Even after raising the limit, the mail folders still appear empty at random times.

dovecot.warn only shows some Sieve warnings (already fixed, but no change in behavior):

root@ncs-mail:~# cat /var/log/dovecot.warn
2025-09-10T02:07:06.952981+02:00 ncs-mail dovecot: lmtp(mail@nerdsclub.de - ): Warning: sieve: file storage: Active sieve script symlink /mnt/daten/dovecot/private/nerdsclub.de/mail/.dovecot.sieve points to non-existent script (points to sieve/default.sieve).
2025-09-10T06:12:47.962439+02:00 ncs-mail dovecot: lmtp(mail@nerdsclub.de - ): Warning: sieve: file storage: Active sieve script symlink /mnt/daten/dovecot/private/nerdsclub.de/mail/.dovecot.sieve points to non-existent script (points to sieve/default.sieve).
2025-09-10T07:23:17.150647+02:00 ncs-mail dovecot: lmtp(mail@nerdsclub.de - ): Warning: sieve: file storage: Active sieve script symlink /mnt/daten/dovecot/private/nerdsclub.de/mail/.dovecot.sieve points to non-existent script (points to sieve/default.sieve).

root@ncs-mail:~# cat /var/log/dovecot.warn.1
2025-09-09T00:22:30.018532+02:00 ncs-mail dovecot: lmtp(mail@nerdsclub.de - ): Warning: sieve: file storage: Active sieve script symlink /mnt/daten/dovecot/private/nerdsclub.de/mail/.dovecot.sieve points to non-existent script (points to sieve/default.sieve).
2025-09-09T05:40:16.513812+02:00 ncs-mail dovecot: lmtp(mail@nerdsclub.de - ): Warning: sieve: file storage: Active sieve script symlink /mnt/daten/dovecot/private/nerdsclub.de/mail/.dovecot.sieve points to non-existent script (points to sieve/default.sieve).

dovecot.log also seems normal, just IMAP logins and disconnects.

The server of the customer is running UCS 5.2 as a member server, just for the mail server and nothing else while our server is running UCS 5.0 as a Replica Directory Node with Open-Xchange. So at least in our case it doesn’t seem to be coming from the 5.2 update.

Is there anything we could try to troubleshoot this behavior?

Best regards,

Oliver
NerdsClub IT Service

I had something similar after updating from 5.0 to 5.2. Egroupware installed, so dovecot in the background. The test server had no problem, but the production server did.

I thought that it had to do with the update, so I reverted to a backup and have not tried again since then.

I’ll look into the IMAP IDLE, but as things are stable with 5.0, I do feel like it is connected to some change that happens during the update.

Hello,

I recently came across another fix: Problem: Dovecot UserDB Cache Causing Incorrect Home Directory on Cached IMAP Logins

So far, this seems to have resolved the problem for our customer.
For our own mail server, we’ll need to wait a bit longer, as we don’t have many users and it may take some time before anyone notices if the issue persists.

By the way, our mailserver is also on 5.2 already. My mistake :sweat_smile:

Best regards,

Oliver