Missing emails / No search results

 

Firstly, Don't Panic: There are a variety of reasons why emails may be missing in the search results. Most of these reasons have clear solutions which ultimately result in the data being fully recovered. 

 

Are results returned when logged in as the admin user? If so, refer to Visibility Incorrect for a resolution.

 

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.

 

Hint: Did you recently perform a major version upgrade? If so, did you reindex all volumes as described in the upgrade instructions?

 

Hint: Did you move servers while upgrading? If so, did you use exactly the same server configuration file? Specifically, the same store encryption password? Did you copy the volumeinfo file in the store path to the new volume location? Refer to Move Server for the correct moving instructions.

 

Hint: When trying to figure out where the missing emails have gone and why, it is useful to ask questions such as: Are the missing emails over a specific time period? Do the missing emails pertain to a specific volume or set of volumes? What and when were changes made to the system? 

 

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 SearchQuery Syntax and Search Fields

 

Note: By default, MailArchiva only displays the first 10,000 records in the search results. This is by design. If you wish to change this, change max search results in Configuration->Search, logout and log back in again.
 

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

 

Items are present in receive folder

 

Symptom: Blob files are present in [application data]queuereceive, 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:

 

# Archiva 1.13.12 Volume Information
# note: this file is crucial - do not delete it!
version:3
id:9fba18d6-cf0e-4db1-b4b8-4751f352fc73
status:CLOSED
created:20091117142412
closed:20091117142429
 
Each volume must have a unique id. If you are creating more than one volumeinfo, you'll need to change the ID slightly (in hex). Once the ID is changed, the affected volume/s must be reindexed in Configuration->Volumes.
 

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:
 

[Audit Log Location]index* (Linux)
[Audit Log Location]/index/* (Windows)

 

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)

 

Note: Like MailArchiva v3.7.2, it is no longer necessary to use a commandline utility to reencrypt volumes. A Volume Re-Encryption feature has been added to the server console.

 

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.

Was this information helpful?

Found this information useful? Visit mailarchiva.com to learn more about MailArchiva.

The page cannot be found

The page you are looking for might have been removed, had its name changed, or is temporarily unavailable. Please make sure you spelled the page name correctly or use the search box.