Missing emails / No search results

If no search results appear or there are missing emails in the search results, first check whether you can find the required emails using MailArchiva's superuser admin account (not Active Directory/LDAP administrator account). The super user account has no search filters applied. If you can find the required emails when logged in as admin, refer to Visibility Incorrect for a resolution.

• Admin User - No search results appear or there are emails missing when logged in to the super user account (admin)
• Active Directory Users - The default admin user can find results, but users logged using Active Directory credentials cannot.
• LDAP Users - The default admin user can find results, but users logged using LDPA credentials cannot.

Admin user

When searching for historical emails, try searching from the master admin account, by subject and without a date range selected. 

Searching using wrong date criteria

Symptom: Emails are missing when searching using a date type of "Receive Date".

Resolution: It is normal for many emails to be missing when searching using received date. The reason being, outgoing emails will not include received date stamps because MailArchiva receives the email before the receiving mail server adds the received date headers. Switch the date to "archive date" in Search Options and reattempt the search.

Incorrect search query

Symptom: You are not searching using correct query syntax, search fields. 

Resolution: Refer to Search, Query Syntax and Search Fields. 

Missing volumes

Symptom: All existing volumes must be present in Configuration->Volumes and must have the status ACTIVE or CLOSED.

Resolution: Import all missing volumes in Configuration->Volumes

Emails stuck in queues

1)  In SMTP Exchange queues - If there are emails in residing in the Exchange SMTP queue, the queue could be flush as described at https://learn.microsoft.com/en-us/exchange/manage-messages-in-queues-exchange-2013-help. There is usually no need to flush these queues.

2)  old journal IMAP mailbox  - Your system is now using SMTP journaling. Previously, it may have been retrieving journaling traffic from an Exchange mailbox and collecting via IMAP. There could still be emails residing in the old journal mailbox. Go to Configuration->Connections->IMAP, click on the Test connection button. If the test fails, then temporarily enable the IMAP service in your Exchange server, and ensure the username and password is correct to the old IMAP journal account. Retest the connection. Assuming connection is ok, enable the connection. Click Save. The server should process the remaining items in the IMAP journal box. If you unsure whether there are still emails left in the box,  login to the box using Outlook Web Access, and examine the contents of the mailbox to verify whether its empty or not.

3) MailArchiva has an inbuilt SMTP receive queues. See How to Recover Lost Items.  Usually, when server is restart this happens automatically.

Items are present in receive folder

Symptom: Blob files are present in [application data]\queue\receive, but the queue size reported in Status->Summary is zero. 

Refer to Receive Queue for information on how to recover orphaned items in the receive and index queues.

Insufficient privileges to read/write volume store/index

Symptom: Volumes listed in Configuration->Volumes are shown as UNMOUNTED. MailArchiva may be running under an account with insufficient privileges to read/write from the directory.

Resolution: Edit the MailArchiva Service in the Windows Services Control Panel applet. Specify a logon account that has rights to read/write to the remote drive. To test access rights: logout of the workstation, and login using the logon account specified, attempt to copy a dummy file to the index and store paths. After the login account has  changed, the MailArchiva server must be restarted for the changes to take effect.

Volumes have zero/low doc counts

Symptom: Some volumes in Configuration->Volumes have zero doc counts or doc counts that are lower than what they should be. The doc count figure is retrieved from the volume index and if the index is incomplete or corrupted, the doc counts may not necessarily reflect the amount of emails that may be in the volume store. 

Resolution: Reindex the affected volumes. If after reindexing, the doc counts are still zero or too low, there may be three possibilities: (1) The server was not allocated enough memory while reindexing. Refer to Out Of Memory. (2) The affected volumes may be encrypted using a different store encryption password. See "Imported Volume Encrypted Using a Different Key" below for a resolution. (4) Not all the data is present in the volume store (5) MailArchiva encountered errors while reindexing. In all cases, refer to the MailArchiva debug.log file in Configuration->Logs to see if there are significant errors occurring while reindexing is taking place.

Volume indexes in wrong format

Symptom: MailArchiva was recently upgraded from V2 to V3. MailArchiva V3 cannot read volume indexes created by the V2 product. 

Resolution: Be sure that you have followed the upgrade instructions and have reindexed all affect volumes. 

Corrupted volume indexes

Symptom: In Status->Volumes, confirm that that the doc counts associated with each of the active/closed volumes are greater than zero.

Resolution: If any volume has a doc count of zero, reindex the affected volume/s in Configuration->Volumes. If reindexing a volume still results in a zero doc count, then the volume could be encrypted using a different password. Refer to "Imported Volume Encrypted Using a Different Key" below.

Missing volume.info file

Symptom: A file called volumeinfo is missing in the root of the store path. When moving volumes to a new server, you forgot to copy the volumeinfo file. The result is that MailArchiva is unable to recognize the volume data.

Resolution: Copy or create the volumeinfo file as follows:

Corrupted audit indexes

Symptom: In Status->Alerts or the MailArchiva debug.log file, errors are appearing indicating that the audit index is corrupted or could not be started. If the audit index is corrupted, it may severely affect the normal operation of the server.

Resolution: From the filesystem, delete the contents of the Audit Log index directory:
 

Thereafter, start the server and reindex your audit logs in Configuration->Logs

Share not mounted correctly (LINUX ONLY)

Symptom: A Linux share was not mounted with the immutable flag set. The result is that if a mount point becomes unstable, data will be written to the local drive instead of the remote share. Thus, volume data will reside in two separate locations - on the remote share and on the local drive.

Resolution: Refer to Network Attached Storage for information on how to mount shares correctly. To correct the problem with volumes created by MailArchiva v1/v2 product only) temporarily mount the share to a different location. Manually copy the .mrc and .att files to the mounted share. Remount the share to the correct location. Reindex the volume in Configuration->Volumes.

Missing emails residing in the journal account

Symptom: Only recent emails are missing from the search results. MailArchiva ran out of diskspace or, for some reason, stopped pulling from the journal account. As such, the missing emails may still be residing in the journal account. 

Resolution: Ensure that there is at least one ACTIVE/UNUSED volume present in Configuration->Volumes. Ensure that there is sufficient disk space available in the ACTIVE volume store directory. Disable and re-enable the IMAP connection. Use a mail client such as Outlook / Mozilla Thunderbird to login to the Journal mailbox via IMAP. 

Tracking down a missing email in the debug.log file

With Troubleshoot logging enabled in Configuration->Logs, the exact subject of a received message will appear in the debug.log file. There will be debug statements inside the log file that indicate whether an email was received, archived and indexed successfully. Thus, it is important to  first enable troubleshoot logging in Configuration->Logs, then try to reproduce the problem by sending a few troublesome emails. Evidence of the email being received, archived and indexed correctly (or otherwise)  will always appear in the debug.log file. If there is no email with a matching subject found in the debug.log file (i.e. if you open the debug.log file and search for the subject name and there is no reference to it in the file), it means that the email would not have been sent to MailArchiva in the first place. The next step is to double check your mail server configuration to ensure that it is configured correctly to send all journaling traffic to MailArchiva. 

Erroneous retention rule

Symptom: There is a retention rule enabled that caused the emails to be deleted.

Resolution: Perform an Audit Search to see if the emails in question were deleted by the retention rule.

Imported volume encrypted using a different key (v3.7.2 and higher)

Symptom: Volume has a status of UNREADABLE

Resolution: Follow the steps in Volume-Reencryption.

Explicit user deletion

Symptom: The emails were explicitly deleted by a user in the search interface.

Resolution: Perform an Audit Search to see if the emails in question were deleted by a user.

Emails deleted from file system

Symptom: The emails were physically deleted from the file system (outside of MailArchiva).

Resolution:Not much that can be done here. 

Hard disk corruption

Symptom: The hard disk were the volume data is stored is corrupted.

Resolution: Take the hard drive to a data recovery specialist.

Active directory users

Local domains not specified correctly

Symptom: Local domains incorrectly specified in Configuration->Domains

Resolution: Check spelling & add all local domains (for example, mailarchiva.com and stimulussoft.com) in Configuration->Domains

Incorrect email attribute

Symptom: For MS Exchange users, the email attribute in Configuration->Logins is not set to "proxyAddresses".  This is the LDAP attribute used to obtain user email addresses for filtering purposes.

Resolution: if using MS Exchange, edit the email attribute field in Configuration->Logins to be "proxyAddresses".

Incorrect email value

Symptom: For MS Exchange users, the email attribute value in Configuration->Logins must be set to "SMTP:(.*)". MailArchiva use this regular expression to parse the value of the email attribute field (specified above). In the default "SMTP:(.*)", MailArchiva will extract the email address from an email value field of (SMTP:test@mailarchiva.com).

Resolution: Edit the email value field in Configuration->Logins to be SMTP:(.*)"

Admin role view filter

Symptom: You have the expectation that AD users assigned the Admin Role will be able to see everyone's emails. This is not the case. By default, only users assigned the Auditor Role, can see everyone's emails.

Resolution: In Configuration->Logins, assign the user the Auditor role, or in Configuration->Roles, remove the contents of the user role's View Filter.

User role filter not defined correctly

Symptom: In Configuration->Roles, the User Role View Filter does not have the value "%email%". This macro is needed to filter out emails belonging to the logged in user. MailArchiva subtitutes "%email%" with the logged in user's email addresses for search results filtering purposes.

Resolution: Edit the User Role filter in Configuration->Roles to be "%email%".

LDAP users

Local domains not specified correctly

Symptom: Local domains incorrectly specified in Configuration->Domains

Resolution: Check spelling & add all local domains (for example, mailarchiva.com and stimulussoft.com) in Configuration->Domains

Incorrect email attribute

Symptom: The email attribute in Configuration->Logins is incorrect.  This is the LDAP attribute used to obtain user email addresses for filtering purposes. The required email attribute value is dependent on the specifiic mail server used. It is often "mail" or "email".

Resolution: Edit the email attribute field in Configuration->Logins to be the name of the LDAP attribute where user email addresses are stored.

Incorrect email value

Symptom: For MS Exchange users, the email attribute value in Configuration->Logins is set to something other than "(.*)".

Resolution: Edit the email value field in Configuration->Logins to be "(.*)"

Admin role view filter

Symptom: You have the expectation that AD users assigned the Admin Role will be able to see everyone's emails. This is not the case. By default, only users assigned the Auditor Role, can see everyone's emails.

Resolution: In Configuration->Logins, assign the user the Auditor role, or in Configuration->Roles, remove the contents of the User Role's View Filter.

User role filter not defined correctly

Symptom: In Configuration->Roles, the user role filter does not have the value "%email%". This macro is needed to filter out emails belonging to the logged in user. MailArchiva substitutes "%email%" with the logged in user's email addresses for search results filtering purposes.

Resolution: Edit the User Role filter in Configuration->Roles to be "%email%".

None of the above

Enable troubleshoot logging in Configuration->Logs. Do a search. Send your debug.log file compressed to MailArchiva support.