Everything USN Journal Disabled or Too Small: How to Fix It

The “Everything USN Journal disabled or too small” warning means voidtools Everything cannot reliably use the NTFS change journal to track recent filename changes on a volume. Everything may still show files from its existing index, but new, renamed, moved, or deleted items can be missing until the index is repaired. The usual causes are a disabled or deleted USN Journal, a journal that wrapped during a large burst of changes, insufficient service permissions, an unsupported file system, or a volume that is not being indexed as expected. The steps below start with safe checks, identify the affected volume, and rebuild only when necessary.

1. Confirm the Symptom With a Small Safe Test

Before changing settings, verify that this is an index-update problem rather than an unexpected search, filter, or exclusion setting. Choose a local NTFS volume that Everything is supposed to index. Do not begin with a network share, removable drive, or NAS because those locations may use a different indexing method.

1. Create a plainly named empty file, such as everything-usn-test-4821.txt, in a normal folder on the affected drive.
2. Open Everything and search for the complete filename.
3. Rename the file to everything-usn-test-7392.txt and search again.
4. Delete the test file and confirm that the old result disappears.

When NTFS change tracking is healthy, the created or renamed filename should normally appear quickly, and a deleted file should stop appearing. If the original file remains visible, the renamed file never appears, or changes become visible only after a manual rebuild, Everything is probably displaying a stale index.

If the test works, stop troubleshooting the USN Journal. The missing result is more likely caused by the current search expression, a filter, an exclusion, result omission, or an index configuration that does not include the actual location. Avoid rebuilding a healthy volume unnecessarily.

1.1 Recognize Typical Journal Failure Symptoms

Missed NTFS changes can present in several ways:

• Recently created files are absent while older files on the same drive remain searchable.
• Renamed files appear under their old names.
• Deleted files remain in results.
• A volume updates correctly after a rebuild but later becomes stale again.
• Everything reports that the USN Journal is unavailable, disabled, deleted, or too small.
• The problem begins after restoring a snapshot, reconnecting a disk, processing a very large file operation, or leaving Everything stopped for an extended period.

A single missing file is not enough to prove journal failure. Repeat the safe test in the same directory and on the same volume as the missing content.

2. Check the Everything Settings Directly Related to the Volume

Open Everything’s Options window and inspect the index pages. Interface labels can vary slightly between builds, but the important task is to find the affected drive under the NTFS volume settings and confirm that it is included.

2.1 Verify NTFS Indexing

Confirm that the drive appears in the NTFS index list and that indexing is enabled for it. If the drive letter changed, a removable disk was reattached differently, or a volume was replaced, Everything may be maintaining information for an old volume identity while the current volume is absent.

If an option allows Everything to include the volume in its database, enable it only for the intended drive. Apply the change and repeat the create, rename, and delete test. Success means the new filename appears promptly and the old name disappears. Once that happens, stop changing unrelated options.

2.2 Clear Filters and Simplify the Search

Set the search filter to Everything, clear the search box, and then search for the exact test filename. Turn off Match Case, Match Path, Match Whole Word, and regular-expression mode unless the test requires them. Also remove advanced search syntax, macros, or commands from the query.

Filters can make a current index look stale. For example, an image filter will intentionally hide a text test file. Path matching can also exclude a file if only its name was entered. If the result appears after simplifying the query, the USN Journal is working and the issue is search configuration.

2.3 Review Exclusions and Result Omissions

Inspect exclusion settings for excluded folders, files, extensions, hidden items, or system items. Pay particular attention to parent directories. Excluding a high-level directory can hide every matching file below it, even when Everything has otherwise detected the volume change.

If your Everything build supports omitting results temporarily, confirm that the file or its parent path has not been omitted. Restore the relevant result and repeat the test. A result that appears immediately after removing an exclusion indicates that rebuilding the NTFS index is unnecessary.

2.4 Distinguish NTFS Indexing From Folder Indexing

Everything can use NTFS metadata and the USN Journal for supported local NTFS volumes. Folder indexing is a separate method commonly used for network shares, NAS folders, non-NTFS locations, or paths that cannot be indexed through local NTFS metadata.

A folder index generally requires rescanning to discover changes because Everything cannot necessarily read a remote server’s NTFS USN Journal through a normal file share. If the missing content is on a mapped drive or UNC path, inspect the folder-index schedule and trigger a rescan rather than treating the problem as a local journal failure.

Avoid indexing the same content through both an NTFS volume and a folder index unless you have a deliberate reason. Overlapping sources can produce duplicate or confusing results.

2.5 Check Portable and Command-Line Settings

A portable copy can load configuration and database files from a different directory than an installed copy. Confirm that you are changing the options in the instance you actually use. If multiple copies are running, close them and start only the intended executable.

Also inspect shortcuts, scripts, scheduled tasks, and command-line options used to start Everything. A custom configuration filename, database path, instance name, or startup option can make the program load a profile different from the one you just repaired. Success means the same instance retains the corrected volume settings after a normal restart.

3. Check Service State, Permissions, and Windows Storage Context

Everything needs sufficient access to read NTFS metadata and monitor the USN Journal. This is commonly provided by the Everything service or by running the application with administrator privileges. Using the service is generally more convenient than elevating the user interface for every session.

3.1 Verify the Everything Service

In Everything’s Options, confirm that the Everything service is installed and running if that is your chosen access method. You can also open the Windows Services console and look for the Everything service. If it is stopped, start it and then restart Everything.

Do not confuse the Everything service with the optional Everything search server or ETP/HTTP features. The local service grants the desktop application the access needed for local NTFS indexing. A network-facing search server is not required to repair local USN tracking and should not be exposed publicly as a troubleshooting step.

After restoring the service, repeat the safe file test. If live changes are detected, no further permission changes are needed. If old entries remain stale, perform a controlled rebuild of the affected volume as described below.

3.2 Test Administrator Access Carefully

As a diagnostic step, close Everything and run it once as administrator. If journal access works only while elevated, the problem likely concerns the service, its installation, or the application’s account context. Repair or reinstall the Everything service using the program’s official options rather than operating the desktop interface as administrator indefinitely.

Portable-app users should pay special attention to this distinction. Portability does not remove the Windows permissions required to read NTFS metadata. A portable executable can still use an installed Everything service where that arrangement is appropriate and authorized.

3.3 Confirm the File System Type

Open the drive’s Properties window or use Windows storage tools to verify the file system. The NTFS USN Journal is an NTFS feature. FAT32, exFAT, many removable-media formats, Linux file systems exposed through another layer, cloud placeholders, and ordinary network shares cannot be assumed to provide the same local NTFS change-tracking path.

If the location is not a directly accessible local NTFS volume, use folder indexing with a suitable rescan schedule or index the data on the machine that owns the storage. Do not attempt to create an NTFS journal on a NAS through a mapped drive.

3.4 Consider Security Software Without Disabling It Permanently

Security controls can sometimes block service installation, executable startup, configuration writes, or database access. Check Windows Event Viewer, security-product history, and controlled-folder-access notifications for a specific block involving Everything. If permitted by your organization, create a narrowly scoped allow rule for the trusted executable or service.

Do not permanently disable antivirus or endpoint protection. If this is a managed computer, ask the administrator to verify the service and policy. Success is demonstrated by stable service startup and reliable test-file updates after a reboot.

3.5 Check Startup and Account Context

If Everything works when opened manually but fails after sign-in, inspect its startup configuration. A startup shortcut might launch another executable, another named instance, or a copy with a different configuration. Fast user switching and multiple Windows accounts can also result in separate settings.

Verify the executable path in Task Manager and confirm that only the intended instance is running. Restart Windows once after correcting service or startup configuration, then perform the small test again.

4. Repair the Index After Journal Loss

The USN Journal records changes to an NTFS volume. Everything initially reads the volume’s file metadata to construct a filename index, then uses journal records to keep that index synchronized efficiently. The journal is not Everything’s database and it is not a complete backup of file contents.

Because the journal has finite storage, older records eventually roll off. If Everything’s last processed journal position is no longer available, it cannot safely infer every change that happened during the gap. A complete rescan or force rebuild is then the correct recovery action.

4.1 Force Rebuild Only the Affected Index

Open the NTFS index options, select the affected volume, and use Force Rebuild if available. Apply the change and allow indexing to complete. During the rebuild, results may be incomplete or change as the database is repopulated.

Rebuilding is safer than manually deleting Everything’s database because the application can recreate the selected index through its supported controls. Do not delete database or configuration files before checking filters, volume inclusion, permissions, and the service.

After completion, repeat the create, rename, and delete test. Success means old names vanish and new changes continue to appear without another rebuild. If the rebuild fixes historical results but live updates immediately fail again, return to service permissions, volume identity, and journal availability.

4.2 Understand Large Bursts of Changes

A journal can wrap when more change records are generated than its allocated storage can retain before Everything processes them. This may occur during bulk extraction, source-tree generation, package installation, synchronization, backup restoration, mass renaming, or movement of very large directory trees.

The key factor is the volume and rate of metadata changes, not merely the number of gigabytes copied. Creating, renaming, and deleting many small files can generate substantial journal activity. A long period during which Everything is not running or cannot access the volume can increase the chance that required records disappear before they are processed.

After such an event, rebuild the affected volume once. If subsequent ordinary changes are tracked, the incident was probably a one-time journal gap and no tuning is needed.

4.3 Increase Journal Size Cautiously

Consider increasing the USN Journal allocation only when diagnostic evidence shows repeated wrapping during legitimate workloads. Windows provides the fsutil usn command family to query, create, and manage a volume’s journal, but these commands require administrative rights and should be used with care.

First query the journal and record the existing values. Make sure the drive is healthy and backed up, and follow Microsoft’s current documentation for your Windows edition. Avoid copying arbitrary size values from forum posts because suitable capacity depends on workload, free space, operational policy, and how long the indexing application may be offline.

Increasing the journal consumes disk space and does not repair an already stale Everything database. Rebuild after a confirmed journal gap, then observe whether the adjusted journal prevents recurrence. If the problem does not recur under the workload, stop tuning.

5. Use Diagnostics to Isolate Persistent Failures

5.1 Read the Status Bar and Index Information

Check Everything’s status bar while searching. It can reveal whether results are still being indexed, whether a filter is active, and how many objects match. Inspect the index options to confirm the expected volume and object counts. An unexpectedly small count can indicate an unindexed volume or exclusion rather than a search-engine failure.

If your build exposes Index Journal information, use it to review changes Everything has processed. This can help distinguish “Windows never supplied the expected change” from “Everything processed the change but the current query hides the result.” Treat the journal view as diagnostic evidence, not as a replacement for rebuilding after records have been lost.

5.2 Enable Debug Logging Temporarily

Everything provides debugging facilities that can show volume discovery, service communication, index operations, and journal-related errors. Enable logging only long enough to reproduce the safe test, note the time and affected path, and then review messages around that event.

Logs may contain filenames and local paths, so handle them as potentially sensitive. Disable verbose logging after the test and redact private paths before sharing diagnostics. Look for repeated access failures, volume removal, journal deletion, invalid journal positions, or reconnect events rather than assuming every warning is fatal.

5.3 Run a Narrow Search-Syntax Test

Search first for the exact filename without special syntax. Then search for a unique substring. Finally, if needed, include the parent path using Everything’s documented path-search behavior. If a simple query works but a complex query does not, troubleshoot the expression rather than the index.

Also compare the file’s actual location in File Explorer. Windows Search and Everything are separate products: Windows Search typically uses Microsoft’s content and property indexing infrastructure, while Everything is primarily a fast filename indexer with specialized NTFS support. A file appearing in one product does not prove that the other product’s index is current.

6. Run a Clean Temporary Test Before Broad Changes

If the cause remains unclear, create a temporary clean Everything profile or use a separate named instance according to the official documentation. Preserve the existing configuration and database. The purpose is to test default behavior without destroying the working profile or losing custom filters.

1. Close extra Everything instances.
2. Start a clean temporary instance with its own configuration and database location.
3. Enable only the Everything service and the affected local NTFS volume.
4. Do not import filters, exclusions, folder indexes, servers, or command-line customizations.
5. Run the create, rename, and delete test.

If the clean profile works, compare settings methodically, beginning with exclusions, NTFS volume selection, startup arguments, and filters. Change one item at a time and rerun the test. If the clean profile also fails, focus on the service, Windows permissions, volume file system, journal state, and storage health.

Stop once the test succeeds consistently across an application restart. Continuing to alter unrelated settings after recovery can introduce a second problem and make the original cause harder to identify.

7. Quick Fix Checklist

• Confirm the missing item is on a local NTFS volume.
• Create, rename, and delete a uniquely named test file.
• Clear filters, advanced syntax, Match Path, and regular-expression mode.
• Check exclusions and omitted results for the file and its parent folders.
• Confirm the affected volume is enabled in Everything’s NTFS index settings.
• Verify that the Everything service is installed and running.
• Use one intended Everything instance, profile, and executable.
• For NAS or mapped paths, check folder indexing and its rescan schedule.
• Force rebuild the affected volume after confirmed journal loss.
• Test live updates again after the rebuild completes.
• Investigate journal sizing only if wrapping repeatedly follows large change bursts.
• Use temporary debug logging or a clean profile if the fault persists.

8. Frequently Asked Questions

8.1 What Does the USN Journal Do for Everything?

The NTFS USN Change Journal records changes made to files and directories on an NTFS volume. Everything can use those records to update its filename index without rescanning every directory after each change. If required records are unavailable, Everything may need to rebuild its view of the volume.

8.2 Does “Journal Too Small” Mean My Files Are Damaged?

No. The warning normally concerns the history of change records available to Everything, not the contents of your files. It means Everything may not be able to account for every change since its last known position. Rebuilding the affected index restores synchronization. Separate disk errors or file-system warnings should still be investigated with appropriate Windows storage tools.

8.3 Why Does Everything Need a Service or Administrator Rights?

Reading NTFS metadata and monitoring the journal requires access that a standard desktop process may not have. The Everything service can provide that access while allowing the visible application to run under the normal user account. Running as administrator can be a useful test, but fixing the service is generally the cleaner long-term approach.

8.4 Will Rebuilding Delete My Files?

No. Force Rebuild recreates Everything’s filename index for the selected source; it does not delete the indexed files. Allow the operation to finish before judging search completeness. Use the supported rebuild control rather than manually deleting databases or configuration files.

8.5 Why Are NAS or Mapped-Drive Changes Missing?

A normal network share does not automatically give the client direct access to the server volume’s NTFS journal. Everything commonly handles such paths through folder indexing and scheduled rescans, or through an Everything instance running on the host machine. Check the folder index and connection state instead of trying to repair a local USN Journal.

8.6 When Should I Increase the USN Journal Size?

Increase it only after confirming repeated journal wrapping under a known high-change workload. A one-time warning after a restore, bulk extraction, or long shutdown usually calls for a rebuild, not immediate resizing. Query the current journal, follow Microsoft’s documented administrative procedure, choose values suitable for the environment, and verify that normal live updates continue afterward.