Question
Corrupted index cache file error in dovecot.index.cache
Rahul Nova
0 reputation · 08 Jan 2022, 23:56 UTC
108.3K views
Loading…
0 reputation · 08 Jan 2022, 23:56 UTC
Dovecot stores per-mailbox index files including dovecot.index.cache to accelerate IMAP operations. The cache is expendable and rebuilt from message data on demand. A documented failure condition is logged when the index/mail-cache code detects inconsistent records in the cache file. Corruption is commonly associated with unclean shutdowns, storage issues and write failures, with higher risk on network filesystems.
Dovecot performs automatic detection for many index inconsistencies, and the cache can be discarded and regenerated without mail data loss. The operational uncertainty is when automatic self-healing is sufficient versus when proactive intervention is warranted, especially as behavior varies with storage backend and locking configuration.
What criteria distinguish transient cache corruption that can be left to automatic rebuild from a pattern that requires moving indexes off shared storage? Is there a documented threshold for frequency or mailbox scope that should trigger manual resynchronization? How should an operator decide between relying on automatic recovery and enforcing a consistent index location policy?
Transient cache corruption appears as isolated incidents that Dovecot automatically discards and rebuilds without mail loss. Persistent or patterned corruption—repeated warnings for the same mailbox, multiple mailboxes, or a high frequency of events—indicates underlying storage or locking problems and may require moving index files to reliable local storage.
Confirmed facts: Dovecot treats dovecot.index.cache as expendable; on detecting corruption it logs a warning and automatically discards and rebuilds the cache from the underlying message data at next access.
Likely explanation: Transient corruption is usually tied to an unclean shutdown, a brief storage glitch, or a single‑mailbox issue and does not recur after the cache is rebuilt. Persistent corruption suggests ongoing problems such as improper NFS locking, failing hardware, or a misconfigured shared storage layer.
dovecotdovecot --versionjournalctl -u dovecot | grep -i "corrupted index cache"systemctl stop dovecotsystemctl start dovecotls -l /var/lib/dovecot/indexesAre the current index and cache files located on a network filesystem (NFS, CIFS, etc.)? Knowing this determines whether moving them to local storage is likely to resolve the pattern.
Use comments to ask for clarification. Post a solution as an answer.
No question comments on this page.