Contents

• Overview
• Prerequisites
• Solution
  • 1. Confirm the symptom and the log pattern
  • 2. Verify antivirus and backup exclusions before retesting
  • 3. Run a controlled upgrade retest
  • 4. Capture evidence before rolling back if the issue returns
  • 5. Rebuild .journal.db only when logs identify a specific SQLite journal problem
• Validation
• Frequently asked questions

Overview

Use this article when Kerio Connect Client webmail accepts the login but does not finish loading after an upgrade to Kerio Connect 10.0.9 on a Windows server, and the user-facing error is:

Message store DB is not available.

This failure means the webmail login or synchronization path cannot obtain a usable message-store database for the mailbox or folder it is trying to load. The same failure pattern can also appear in server logs as Error opening message store database, WebmailSyncKey.cpp: Message store DB is not available, or ChangesManFacade.cpp: Message store DB is not available.

Important: Do not treat the webmail error by itself as proof that a .journal.db file is corrupt. The same visible symptom can be caused by broader file-access contention, antivirus or backup software scanning Kerio Connect files, Kerio Antivirus plugin timeouts, or a specific SQLite/journal problem. The safe approach is to confirm the log pattern first, correct the file-access and antivirus conditions that can affect many mailboxes, and rebuild a .journal.db file only when the logs name a specific affected journal database.

Prerequisites

• Full administrator access to Kerio Connect Webadmin.
• Operating system administrator access to the Windows server where Kerio Connect is installed.
• A maintenance window, because upgrade retesting and mailserver.cfg changes require stopping or restarting Kerio Connect.
• A full Kerio Connect backup before any upgrade retry. Kerio’s upgrade guidance lists a full backup as a prerequisite for upgrading Kerio Connect. See Upgrading Kerio Connect Server to the Latest Version.
• The last known-good installer or rollback plan for the version currently keeping production stable.
• Access to error.log, warning.log, debug.log, and a fresh support_info.txt.

Solution

Follow the sections in order. The order matters: exclusions and timeout corrections reduce the chance of repeating a file-access failure, while log collection preserves the evidence needed to distinguish a file-locking problem from a targeted SQLite/journal problem.

1. Confirm the symptom and the log pattern

1. Ask an affected user to sign in to Kerio Connect Client webmail to trigger the error
2. Open Kerio Connect Webadmin > Logs.
3. Open Error and search for entries similar to these:

   WebmailSyncKey.cpp: Message store DB is not available. username=<user@example.com>
   EwsOperation.cpp: EWS request FindItem: error occurred; code 132, description: Error opening message store database, auth user: <user@example.com>
   ChangesManFacade.cpp: Message store DB is not available. fld=#public@example.com/Contacts

4. Open Warning and search for repeated message-store entries across mailbox folders or public folders:

   Message store DB is not available. fld=~<user@example.com>/Contacts
   Message store DB is not available. fld=~<user@example.com>/Calendar
   Message store DB is not available. fld=#public@example.com/Resources

5. Decide whether the pattern is broad or targeted:

   What the logs show	What it usually means operationally	What to do next
   The same message-store errors appear for multiple mailboxes, public folders, or both.	The failure is not isolated to one mailbox. File-access contention, antivirus or backup scanning, Kerio Antivirus plugin timeouts, or a version-specific message-store problem must be ruled out before targeted database repair.	Continue with antivirus and backup exclusions, then check Kerio Antivirus timeout errors before retesting.
   The logs name one specific mailbox and also name a specific .journal.db file with SQLite errors.	The issue may be a targeted journal database problem for that mailbox.	Skip broad repair actions and go to Rebuild .journal.db only when logs identify a specific SQLite journal problem.
   The webmail error appears, but the logs do not show message-store, EWS, folder lock, antivirus, or SQLite evidence.	The visible webmail symptom is not yet proven to be this failure mode.	Collect full logs and support_info.txt before changing server files.

Why this matters: Message store DB is not available tells you that webmail could not load the message-store state it needs. It does not tell you why the database was unavailable. If you delete or rebuild database files before checking the broader log pattern, you can add risk without addressing the real cause.

2. Verify antivirus and backup exclusions before retesting

Before retrying the upgrade, exclude the Kerio Connect server directories from real-time scanning by antivirus and backup tools. Kerio documents that improper third-party antivirus or backup settings can cause Webmail/Webadmin loading issues, file-access problems, performance issues, and data corruption. See Antivirus Exclusions for Kerio Connect.

1. Confirm the actual Kerio Connect paths in your environment. Do not assume the defaults if Kerio Connect was installed or migrated with custom locations.
2. Find the store directory in Administration Console > Configuration > Advanced Options > Store Directory.
3. Find the archive directory in Administration Console > Configuration > Archiving and Backup > Archiving.
4. Find the backup directory in Administration Console > Configuration > Archiving and Backup > Backup.
5. Add exclusions in your antivirus or backup product for the relevant Kerio Connect paths (ref: Store Directory Locations):

   Path type	Why it must be excluded
   Kerio Connect installation directory	Contains Kerio Connect binaries, configuration files, plugins, and working files used by the service.
   Kerio Connect Mailstore directory	Contains mailbox data and message-store files. Scanning or locking this path can interfere with mailbox access.
   Kerio Connect Archive directory	Contains archived mail data that Kerio Connect may read or write.
   Kerio Connect Backup directory	Contains backup output. Backup tooling and antivirus scanning should not compete with Kerio Connect for the same files.

Why this works: Kerio Connect stores mailbox state in files that the Kerio service must be able to open, read, and update quickly. Real-time scanning can lock, quarantine, or delay access to those files. Excluding the Kerio paths removes a common source of file-access contention before you test the upgrade again.

What can go wrong if this is skipped: A retest can reproduce the same message-store errors even if the Kerio Connect build itself is not the root cause, because the same external file-locking condition is still present.

3. Run a controlled upgrade retest

1. Keep production on the last known-good Kerio Connect version until you are ready for a maintenance-window retest.
2. Confirm the full backup is complete and usable before starting.
3. Confirm that antivirus and backup exclusions are in place for the Kerio Connect paths.
4. Upgrade according to Upgrading Kerio Connect Server to the Latest Version. 
5. After the upgrade, test webmail with:
   • one regular mailbox,
   • one administrator mailbox, and
   • public folders, if your environment uses them.

Why this works: A controlled retest changes one risk area at a time. By confirming exclusions and timeout settings before upgrading, you reduce the chance that the retest is invalidated by the same file-access or antivirus timeout condition that was present during the failed attempt.

4. Capture evidence before rolling back if the issue returns

If you once again encounter the error Message store DB is not available, capture evidence before rolling back unless service restoration is urgent.

1. Record the approximate start and end time of the failed upgrade attempt, including the server time zone.
2. Record the exact Kerio Connect version and build that was tested.
3. Generate a fresh support information file from Kerio Connect Webadmin > Status > System Health > Support Information. This generates support_info.txt. See Collecting Log Files and Support Information File for Kerio Connect.
4. Save the full log files, not only the last lines shown in support_info.txt:
   1. Open Kerio Connect Webadmin > Logs.
   2. Open Error, right-click the log area, and select Save Log > Plain text + Full file > Ok.
   3. Repeat the same action for Warning.
   4. Repeat the same action for Debug, especially if Kerio Antivirus, EWS, HTTP, or message-store debug logging was enabled for the test.
5. Save a screenshot of the exact webmail error if the browser displays it.
6. When contacting Support, provide all of the following:
   • error.log
   • warning.log
   • debug.log
   • support_info.txt
   • the tested Kerio Connect build number
   • the Windows Server version
   • the time window when the error occurred
   • whether antivirus and backup exclusions were verified
   • whether ShortTimeout and LongTimeout were changed
   • whether the issue affects one mailbox, multiple mailboxes, public folders, or all users

Why this matters: support_info.txt includes useful environment details and recent log excerpts, but the full logs preserve the complete sequence around the failed upgrade. Without the full logs, it may be impossible to tell whether the trigger was antivirus/file locking, a Kerio Antivirus plugin timeout, a specific SQLite journal error, or another message-store failure.

5. Rebuild .journal.db only when logs identify a specific SQLite journal problem

Do not delete .journal.db files only because you get error Message store DB is not available. Rebuild a journal database only when the logs explicitly name a specific .journal.db file with SQLite open, I/O, readonly, or corruption errors, such as:

SQLiteDb.cpp: SQLiteDb::open() - SQLite error: file <store_path>\mail\example.com\username\.journal.db, code 14, error SQLITE_CANTOPEN[14]: unable to open database file
SQLiteDbWriteCache.h: <store_path>\mail\example.com\username\.journal.db: runVacuum - SQLite error: code 11, error SQLITE_CORRUPT[11]: database disk image is malformed
SQLiteDbWriteCache.h: write_thread - file '<store_path>\mail\example.com\username\.journal.db', SQLite error: code 8, error SQLITE_READONLY[8]: attempt to write a readonly database

If a specific affected journal file is identified, follow this targeted workflow:

1. Confirm the exact mailbox path from the log line. Do not apply this procedure to unrelated users.
2. Stop Kerio Connect.
3. Navigate to the affected user folder under the Kerio Store folder. The default Windows base path is:

   C:\Program Files\Kerio\MailServer\Store\Mail

4. Open the domain folder and then the affected user folder named in the log.
5. Move or delete only the affected .journal.db file named in the log.
6. Start Kerio Connect so the journal database can be recreated.
7. Retest webmail and check the logs again.

Kerio documents this repair path in Fixing Corrupt .journal.db with SQLite Error. Kerio also notes that journal.db contains synchronization information for clients and that, after moving the file out of the way, some offline clients may need their profile recreated. See SQLLite error message - journal.db file.

Why this works: A targeted rebuild removes the database file that the log has already identified as unreadable or corrupt, allowing Kerio Connect to create a new journal database for that mailbox.

What can go wrong if this is done broadly: Deleting journal databases that are not named in the logs can disrupt synchronization state for users whose mailboxes were not the cause of the failure, while leaving the original antivirus, backup, or file-locking problem unresolved.

Validation

After applying the relevant corrections and retesting the upgrade, validate both the user experience and the logs.

1. Confirm Kerio Connect Client webmail loads completely for at least one regular mailbox.
2. Confirm webmail loads for an administrator mailbox.
3. Confirm public folders load if public folders are used in the environment.
4. Confirm Error and Warning no longer show repeated entries for:
   • Message store DB is not available
   • Error opening message store database
   • Cannot open folder ... locked after 20 retries
   • Kerio Antivirus plugin timeout or non-response errors
5. If mail was queued during the failure, confirm mail flow resumes and the message queue no longer reports antivirus or mailbox access failures.

If the same webmail error returns after exclusions are verified, timeout errors are addressed, and the logs do not point to one specific .journal.db file, contact Support with the evidence listed in Capture evidence before rolling back if the issue returns.

Frequently asked questions

Why can Outlook or KOFF appear to work while webmail fails?

Different clients exercise different access paths and timing. Webmail still needs message-store state during login and synchronization, so webmail can expose message-store database failures even when another client appears to keep working temporarily.

Should I reinstall Kerio Connect again if reinstalling did not help?

Do not repeat a reinstall only because the error returns. If a reinstall while preserving store and config did not change the behavior, the next useful step is log-based isolation: exclusions, Kerio Antivirus timeout evidence, and targeted SQLite journal evidence.

Is a .journal.db rebuild always safe?

No. Rebuild only the specific .journal.db file named in SQLite log errors. The journal database contains synchronization information, and offline clients may need profile recreation after the affected file is moved or recreated.