Docker Mailserver Dovecot “Corrupted index cache file”

Dovecot logs Corrupted index cache file, an IMAP folder will not open, message counts look wrong, or the same index error returns on every connection. In Docker Mailserver, the important first distinction is between Dovecot’s index/cache state and the mailbox messages themselves. A rebuildable index problem is not permission to delete a mail volume.

The narrow recovery path is to capture the exact user and mailbox, prove the underlying storage is healthy, protect the message files, and ask Dovecot to resynchronise that mailbox. Only a log or version-specific Dovecot instruction should lead you to remove a named cache file—and only after a backup.

Repair one affected mailbox first. Never turn an index error into a recursive deletion across /var/mail.

What the Dovecot files do

With Maildir, messages normally live as individual files below the mailbox’s cur, new, and tmp directories. Dovecot maintains files such as dovecot.index, dovecot.index.cache, and transaction logs to make mailbox access efficient and track state.

Those files are related but not interchangeable. The cache stores selected message metadata; the main index and transaction log participate in mailbox state; dovecot-uidlist associates Maildir files with IMAP UIDs. Do not include dovecot-uidlist in a casual “delete all Dovecot files” command. UID changes can make clients download messages again or lose their view of flags.

1. Capture the exact mailbox and first error

Open the affected folder once while watching a short log window:

docker compose logs --since 10m --follow mailserver

Record the timestamp, Dovecot process, account, mailbox, first corruption line, and any earlier I/O, permission, locking, or capacity error. Keep the raw log private because it can reveal addresses, folder names, message identifiers, client addresses, and host paths.

If authentication fails before any mailbox opens, use the separate IMAP login troubleshooting guide. If the first storage error is Permission denied, follow the Dovecot mailbox permissions guide before rebuilding an index.

2. Record the running image, mount, and mailbox format

Use runtime evidence instead of assuming the current Compose file matches the running container:

docker inspect mailserver \
  --format 'image={{.Config.Image}} id={{.Image}}'

docker inspect mailserver \
  --format '{{range .Mounts}}{{println .Type .Source "->" .Destination .RW}}{{end}}'

docker compose exec mailserver doveconf -n

Confirm the expected writable mount reaches /var/mail. Review the effective mail_driver or mail location, index path, cache path, namespaces, compression and full-text-search settings. Keep host paths and private configuration out of public logs.

This guide focuses on ordinary Maildir index/cache recovery. Dovecot’s sdbox and mdbox formats use indexes as a more central part of storage, and force-resync checks their storage files too. Do not transplant Maildir file-deletion advice onto dbox.

3. Prove storage health before rebuilding

An index rebuild needs working storage. Check capacity inside the same container boundary:

docker compose exec mailserver df -h /var/mail
docker compose exec mailserver df -i /var/mail

Then inspect host evidence for filesystem errors, read-only remounts, container restarts, abrupt shutdowns, remote-storage failures, and mandatory-access-control denials. If several mailboxes broke at the same time, treat that as a storage incident until disproved.

Also query the affected identity and list mailboxes through Dovecot:

docker compose exec mailserver \
  doveadm user [email protected]

docker compose exec mailserver \
  doveadm mailbox list -u [email protected]

Use a mailbox you control and keep the real address private. A successful user lookup does not prove that every parent directory is writable; it does prove which effective identity and path should be investigated.

4. Back up before any write repair

For a production mailbox, stop or quiesce mail writes before taking the repair backup. Preserve the pinned image identity, mail-data volume, and relevant configuration. A bind-mount example is:

docker compose down

# Replace the source path privately; the archive contains private mail.
sudo tar --numeric-owner -cpf \
  mail-data-before-index-repair.tar \
  -C ./docker-data/dms mail-data

tar -tf mail-data-before-index-repair.tar >/dev/null

Store the archive with restrictive permissions and away from the live volume. For a large installation, a tested snapshot may provide a shorter write pause. The essential acceptance test is that you can restore the affected mailbox files and metadata—not merely that an archive command returned zero.

The broader Docker Mailserver backup and restore runbook covers mail, state, configuration, image pinning, and restore drills.

5. Start cleanly and resynchronise one mailbox

After correcting any proven capacity, mount, ownership, or filesystem fault, start the same pinned image. Ask Dovecot to repair the affected mailbox:

docker compose up -d mailserver

docker compose exec mailserver \
  doveadm force-resync -u [email protected] INBOX

Replace INBOX with the exact mailbox from the error. Dovecot documents force-resync for cases where it cannot automatically solve mailbox problems. Beginning with one account and one mailbox limits impact and gives you a useful control before considering a wider scope.

Do not start with -A. An all-user repair can add heavy I/O, obscures which mailbox was actually broken, and depends on correct user enumeration. If several folders are affected, prove the first repair and then handle each evidenced folder deliberately.

6. If the cache error remains

Repeat the log capture immediately. If the exact message is still Corrupted index cache file, storage is healthy, the mailbox is confirmed as Maildir, and the documentation for your pinned Dovecot version specifically directs removal of dovecot.index.cache, preserve that exact file and remove only that cache file for the affected mailbox while writes are stopped. Let Dovecot recreate it on access.

Do not use a recursive wildcard such as find /var/mail -name 'dovecot*' -delete. It can remove UID lists, transaction history, subscriptions, and unrelated users’ state. Do not remove message files from cur, new, or tmp. If logs identify a damaged message or a compression mismatch, preserve the original file and diagnose that separate data-path problem rather than repeatedly rebuilding indexes.

7. Keep FTS repair separate

A normal Dovecot mailbox index is not the same thing as a full-text-search index. If ordinary folder access works but search is incomplete, use the commands documented for the enabled FTS backend. Docker Mailserver’s Flatcurve guidance provides backend-specific check, remove, rescan, and queued indexing commands.

Do not drop a full-text index to fix an unrelated dovecot.index.cache error, and do not assume rebuilding FTS repairs Maildir metadata. Confirm the active plugin with doveconf -n, then follow the matching DMS and Dovecot version documentation.

8. Verify mailbox content and IMAP state

A successful command is not the acceptance test. Exercise the recovered mailbox:

1. Open the affected folder through IMAP and confirm the expected message count.
2. Open several old and new messages, including the area that previously failed.
3. Deliver one controlled message and confirm it appears once.
4. Mark it read, add and remove a flag, then reconnect and confirm state persists.
5. Move a disposable test message between two folders and back.
6. Compare Dovecot’s mailbox status before and after the client actions.
7. Check logs for fresh corruption, I/O, permission, or cache-size errors.
8. Recreate the container once and repeat the read/write check.

docker compose exec mailserver \
  doveadm mailbox status -u [email protected] \
  'messages unseen uidnext uidvalidity' INBOX

docker compose logs --since 10m mailserver

Keep the pre-repair backup through the rollback window. If UID validity changes unexpectedly or a client begins downloading the mailbox again, stop and compare the protected metadata before making more changes.

Repairs to avoid

• Deleting the mail-data volume: it contains the messages, not just cache.
• Deleting every dovecot* file: cache, indexes, UID lists, subscriptions, and logs have different roles.
• Running force-resync -A first: it expands I/O and impact before one mailbox proves the method.
• Resyncing on a full or read-only filesystem: regenerated state will fail again.
• Changing ownership recursively without evidence: it can expose private mail or create new delivery failures.
• Upgrading DMS during recovery: it mixes storage repair with image and configuration changes.
• Confusing FTS with mailbox indexes: rebuilding one does not necessarily repair the other.
• Trusting one successful login: verify delivery, reads, flags, moves, logs, and persistence.

Compact recovery order

1. Capture the exact account, mailbox, and first Dovecot error.
2. Record the image, effective /var/mail mount, mailbox format, and index settings.
3. Check blocks, inodes, mount state, host storage, permissions, and recent crashes.
4. Stop writes and take a verified private backup.
5. Fix the underlying storage fault, if one exists.
6. Run doveadm force-resync for one affected user and mailbox.
7. Only if pinned-version guidance requires it, replace one named cache file.
8. Verify messages, counts, flags, moves, delivery, logs, and recreation.

Authoritative references: Dovecot’s force-resync manual defines the scoped mailbox repair command; its error reference documents corrupted index-cache handling; its Maildir guide separates message, control, and index paths; and Docker Mailserver’s full-text-search guide documents backend-specific checks and rebuilds. Match commands to the DMS and Dovecot versions, mailbox format, and FTS backend you actually run.