Fix Zimbra Search Index Corruption: How to Reindex a Mailbox

Reviewed October 6, 2026. If Zimbra search returns incomplete results for one mailbox and the mailbox log points to an indexer or Lucene error, the usual repair is to rebuild that mailbox’s search index with zmprov rim account@example.com start. The command recreates searchable index data from mailbox content; it is not a repair for missing message files, database corruption, a full storage volume, or server-wide search failures.

Judge success by the actual outcome: the reindex job finishes, targeted searches return messages that were previously missing, and new mail continues to appear in search. Starting the command is not proof that the index is rebuilt. Plan the work during a quieter period, check the index volume first, and run it for one affected account before expanding the scope.

When is a mailbox reindex the right fix?

A damaged or incomplete index is a reasonable suspect when ordinary mailbox access works but searches miss known messages, an affected user sees inconsistent search results, or /opt/zimbra/log/mailbox.log reports messages such as “Failed to open Indexer” or a Lucene exception for that account. Zimbra’s troubleshooting material documents zmprov verifyIndex as a diagnostic for an index that is missing or cannot be opened, and uses zmprov rim ... start to recreate it.

First establish the scope. If only one user is affected, investigate that mailbox. If many users on the same mailstore have the same symptom, check server health, storage capacity, recent upgrades, and logs before launching many rebuilds. A large batch of reindexes can consume substantial disk I/O and CPU and may worsen slow search for other users.

A reindex is not the right first move when users cannot log in, folders are missing, message bodies or attachments fail to open, the mailstore database reports errors, or the search service is unavailable for multiple accounts. Those signs can indicate database, blob-store, service, or infrastructure problems. Preserve logs and use the matching Zimbra recovery procedure or support channel instead of treating every “search” complaint as index corruption.

Before running the command

• Confirm the target mailbox: Copy the primary account address, not an alias. In a multi-mailstore deployment, verify which mailbox server owns the account and run the command according to your topology and installed Zimbra version.
• Check available space: Inspect free space and inodes on the actual index volume. Installations may place index data on a separate mount; do not assume the default path is the active location. A full index volume can itself cause indexing failures.
• Check system load: Note current mailstore latency, CPU, and disk activity. Reindexing is resource intensive, particularly for large mailboxes, so schedule it away from peak traffic.
• Protect recoverability: Confirm that the normal backup process is healthy and recent before maintenance. Reindexing is intended to reconstruct derived search data, but a backup remains important before any repair work on production mail.
• Check command support: Zimbra’s CLI syntax and available options can vary by release. Review the command help and documentation for the exact installed build, especially if you use an older release or a customized deployment.

How to verify and rebuild one mailbox

1. Run a diagnostic check, if available

As the Zimbra operating-system account, test the suspected mailbox with the diagnostic shown in Zimbra’s troubleshooting guidance:

zmprov verifyIndex user@example.com

A response indicating that the index does not exist or that a segment file cannot be found supports the index-corruption diagnosis. If your installed version does not recognize verifyIndex, do not install scripts or copy index files from another server to work around it. Use the version-specific Zimbra documentation and correlate the mailbox log with the affected account.

2. Start the mailbox reindex

On the appropriate Zimbra server, switch to the Zimbra operating-system account and start the rebuild for the single affected mailbox:

su - zimbra
zmprov rim user@example.com start

The command normally reports that the task has started. That confirms submission, not completion. Do not start repeated jobs just because search remains incomplete immediately afterward; first check the job state and mailstore logs.

3. Check progress

Query the reindex task using the same account and server context:

zmprov rim user@example.com status

Repeat at a reasonable interval rather than polling continuously. Read the response according to your Zimbra release: the CLI reports job state, while mailbox.log can provide account-specific progress or errors. If the command reports an error, the task never completes, or the logs show disk-space or index-writer failures, pause and resolve that underlying issue before trying again.

Zimbra’s command reference lists reIndexMailbox with start, status, and cancel actions. If your release supports cancellation and the job is harming service, confirm local syntax before using it. Do not kill Java processes or remove index files as a substitute for a supported cancellation procedure.

How to confirm the repair worked

After the task completes, test from the affected user’s web client with a few known messages. Search for a distinctive sender, subject phrase, and date range; verify both old messages and recent mail. Check the folders where the messages should appear and compare the result with a known message that the user can open directly. Then send or receive a test message and confirm that it becomes searchable after normal indexing delay.

Look for a sustained improvement rather than a single successful query. The practical success criteria are:

• The mailbox reindex status reaches its completed state without recurring errors.
• Previously missing, known messages appear in the expected searches.
• New mail continues to enter the search index.
• The index volume retains adequate free capacity and other mailboxes remain responsive.

If the command reports completion but specific messages remain absent, verify that the messages still exist and can be opened. Check whether the user’s search terms, date filters, folder scope, or client-side cache explain the difference. A rebuilt index cannot restore messages that were deleted, never delivered, or lost from the underlying store.

When to change the troubleshooting path

If the rebuild repeatedly fails, first address the error named in the logs. Confirm available disk space and inodes, check for broader mailstore or database errors, and make sure the mailbox is being handled on the correct server. If the account can’t access message content or other mailboxes show the same problem, stop repeating the reindex and investigate the store, database, or server-level cause.

Avoid manually deleting /opt/zimbra/index data as a routine step. Zimbra’s public wiki includes a manual index-file removal procedure, but that page is marked as work in progress and is tied to older releases. Manual deletion is more error-prone than the supported account-level reindex command and should only be considered under current, release-specific vendor guidance with an exact mailbox path, verified backups, and a maintenance plan.

Limits of mailbox reindexing

Reindexing rebuilds search metadata; it does not repair MySQL or MariaDB tables, restore missing blobs, fix a damaged filesystem, free a full disk, or correct a server-wide search outage. It also takes longer as mailbox size and server load increase. Search may be temporarily incomplete while indexing runs, and overall performance can dip during the task.

Use the built-in mailbox-level reindex first when the evidence points to one account’s search index. Measure the result using known messages and follow-up mail. If the reindex cannot complete or the data itself is damaged, shift to the relevant storage or database recovery procedure rather than escalating to broad index deletion.

Official references

• Zimbra zmprov command reference — lists the reIndexMailbox command and its action syntax; the page also directs readers to the Administrator’s Guide for release-specific details.
• Zimbra troubleshooting example for a corrupted mailbox index — shows verifyIndex and the account-level reindex command. The page is marked as work in progress, so confirm applicability to your installed version.
• Zimbra wiki procedure discussing index data removal and status checks — an older, work-in-progress reference; use it as context, not as a reason to delete files on a current production system.