Everything NTFS Volumes Not Indexed: How to Fix It

When a local NTFS drive is missing from voidtools Everything, the cause is usually narrower than it first appears. The volume may not be enabled for NTFS indexing, Everything may lack the access needed to read the NTFS metadata, the drive may be removable or mounted differently than expected, or an exclusion, filter, or search option may be hiding otherwise indexed results. Less commonly, the index is stale, USN Journal monitoring has stopped, or Everything is running under an unexpected account or portable configuration.

This guide focuses specifically on local NTFS volumes. Everything is not the same as Windows Search: Windows Search typically crawls file contents and selected locations, while Everything builds its fast filename index primarily from NTFS file-system metadata. Therefore, rebuilding the Windows Search index generally does not fix a local drive missing from Everything.

1. Confirm the Symptom With a Small Safe Test

Before changing settings, determine whether the volume is absent from the database or whether its results are merely hidden by the current search. These are different problems and require different fixes.

1.1 Create a uniquely named test file

On the affected local drive, create an empty text file in a folder you can access. Give it an unusual name, such as everything_ntfs_test_8472.txt. Wait several seconds, clear the Everything search box completely, and search for the exact filename.

Interpret the result as follows:

• If the file appears immediately, the volume is indexed and the original missing results were probably caused by search syntax, a filter, an exclusion, or permissions on particular folders.
• If older files appear but the new file does not, the existing index may be stale or USN Journal monitoring may not be working.
• If no files from that drive appear, the entire volume is probably excluded, disabled, unavailable, or inaccessible to Everything.

If the test file appears, stop making index-level changes. Move directly to the filter, exclusion, and search checks below. There is no reason to rebuild a healthy index.

1.2 Test the drive path directly

Clear any active search and enter the drive path followed by a backslash, such as D:\. You can also search for the exact test filename while restricting the path, for example D:\ everything_ntfs_test_8472.txt.

Check the status bar at the bottom of Everything. It can help reveal whether the search has returned zero objects, whether a filter is active, or whether the total indexed object count is unexpectedly low. A drive with substantial data should normally contribute files and folders to the database once it is included successfully.

1.3 Verify that the volume is actually NTFS

In File Explorer, right-click the drive, select Properties, and read the value next to File system. You can also open Command Prompt and run fsutil fsinfo volumeinfo D:, replacing D: with the affected drive letter. The command may require an elevated terminal.

If the drive is exFAT, FAT32, ReFS, or a network-mounted file system, it cannot be handled as a local NTFS volume in Everything's NTFS index. Such locations may need a folder index instead. If Windows reports NTFS, continue with the NTFS-specific checks.

2. Check the Everything Index Settings Directly

The most important place to inspect is the NTFS indexes page in Everything's options. Opening unrelated Windows indexing settings will not address this symptom.

2.1 Enable Include in database

Open Tools, select Options, expand Indexes, and open the NTFS page. Select the affected volume from the volume list and verify that Include in database is enabled.

If it is disabled, enable it and apply the change. Everything should begin adding the volume's files and folders to its database. The exact completion time depends on the number of objects and the availability of the drive.

Success means the unique test file appears, searches restricted to the drive return results, and the status bar's total object count increases appropriately. Once those signs are present, stop changing index options.

2.2 Check fixed and removable NTFS volumes separately

Do not assume every NTFS device is treated identically. An internal disk is commonly presented as a fixed volume, while a USB hard drive, flash device, card reader, or certain enclosure can be reported as removable. A removable NTFS volume may not be included automatically, may be disconnected during startup, or may return with a different drive letter.

Connect the device, wait for Windows to mount it, and revisit the NTFS indexes page. Select the volume that corresponds to the device and enable Include in database. Match it by volume label, drive letter, size, and other available identifying information rather than relying only on the letter.

If the device reconnects under a different letter, test again after reconnection. Assigning a stable drive letter in Windows Disk Management can reduce confusion, but change drive letters cautiously because shortcuts, scripts, and applications may depend on the existing path.

2.3 Enable USN Journal monitoring

Everything uses the NTFS Master File Table to build a fast filename index. It can then use the NTFS USN Change Journal to monitor file-system changes efficiently. On the affected volume's NTFS settings, verify that USN Journal monitoring is enabled when the option is available.

A disabled or inaccessible journal can explain why an older index exists but new files, renames, and deletions are not reflected. After enabling monitoring, create or rename the unique test file and watch for the change in Everything.

Success means newly created, renamed, and deleted files are reflected promptly without a manual rebuild. If live changes now work, do not continue altering journal or database settings.

2.4 Inspect folder indexes without duplicating the drive

Folder indexing is useful for file systems and locations that cannot use Everything's native local NTFS indexing, including many network shares. It is not normally the preferred replacement for an available local NTFS index.

Under Tools, Options, Indexes, inspect the folder index page. Make sure an old folder-index entry, unavailable path, or unexpected configuration is not being mistaken for the local NTFS drive. Avoid indexing the same local content through both an NTFS index and a broad folder index unless you have a deliberate reason to do so.

3. Eliminate Filters, Exclusions, and Result-Hiding Options

An indexed volume can appear missing when Everything is applying a filter or omitting matching paths. Perform these checks before forcing a rebuild.

3.1 Reset the active filter and search syntax

Set the search filter to Everything. Clear the entire search box, including punctuation, quotes, path operators, regular expressions, and modifiers. Turn off options such as regex, whole word, match path, match case, or diacritics matching if they were enabled for a previous search.

Then search only for the exact unique test filename. If it appears, the index is healthy. Reconstruct the original search gradually until you identify the filter or expression that hid the results.

3.2 Review exclusions and omitted results

Open the index exclusion settings and inspect excluded folders, files, patterns, hidden items, and system items. A broad path exclusion such as an entire drive root can remove all of that volume's objects from the database. A wildcard can also hide more than intended.

Temporarily disable only the exclusion that plausibly covers the affected path. Do not remove every exclusion blindly, especially on managed systems where exclusions may exist for privacy or operational reasons.

Also check whether results have been omitted through Everything's result-list features. Clear temporary omissions and repeat the exact filename test. Success means the test file appears after the relevant exclusion or omission is removed.

3.3 Separate server settings from local indexing

Everything's HTTP, ETP, or other server-related options do not normally determine whether the local application can add a local NTFS volume to its own index. A server configuration matters when another client is querying an Everything instance over a network, not when the local NTFS volume itself is absent from the local database.

If you are viewing remote results, test directly in the Everything application running on the computer that physically hosts the NTFS volume. Do not expose an Everything server directly to the public internet as a troubleshooting shortcut. Use authenticated, firewalled, and appropriately secured remote-access methods.

3.4 Check command-line and portable settings

A shortcut, script, scheduled task, or portable launcher may start Everything with a different configuration, database location, instance name, or startup option. This can make settings changed in one instance appear ineffective in another.

Right-click the shortcut used to start Everything and inspect its target. Compare it with the executable shown in Task Manager. Also check whether multiple Everything processes or differently named instances are running. Portable copies may store their configuration beside the executable and therefore behave differently from an installed copy.

Success means launching the intended instance shows the expected NTFS volume settings and returns the test file. Once the correct instance is identified, update the shortcut or workflow rather than repeatedly changing both configurations.

4. Check the Everything Service and Windows Access Context

Everything needs sufficient access to read NTFS metadata. The usual choices are to use the Everything service or run the application with elevated administrator rights.

4.1 Prefer the Everything service for normal daily use

The Everything service allows the user interface to run under a standard user account while the service performs the privileged NTFS indexing work. This is generally more convenient than launching the entire interface as administrator every time.

Open Everything's general options and verify that the Everything service is installed and enabled if that is your chosen setup. You can also open the Windows Services console and confirm that the service exists and is running. If it is stopped, start it and test the volume again.

Success means the standard, non-elevated Everything interface can include the NTFS drive and locate the newly created test file. At that point, there is no need to continue running the interface as administrator.

4.2 Use Run as administrator as a diagnostic test

Exit Everything completely, then right-click its executable or shortcut and choose Run as administrator. Check whether the affected drive appears on the NTFS indexes page and whether the test file becomes searchable.

If elevation fixes the problem, the likely cause is the missing, stopped, or misconfigured Everything service, or an account-context issue. Treat elevation as a useful diagnostic step, not automatically as the permanent solution. Repairing or installing the service is usually cleaner for daily use.

4.3 Check startup timing and account context

External drives may not be mounted when Everything starts. Encrypted volumes may remain locked until a user signs in, and a portable installation may launch before its target disk is ready. Disconnect and reconnect the device, unlock it if necessary, and then restart Everything or rescan the relevant index.

If Everything is launched by Task Scheduler, a service account, or a different Windows user, verify that the active process is using the expected configuration. A configuration changed under one account may not apply to another account's instance.

4.4 Distinguish local volumes from mapped drives and NAS shares

A mapped drive letter does not turn a NAS share into a local NTFS volume. Even if the NAS internally uses NTFS or another journaled file system, Windows generally presents the share through a network protocol rather than as a directly attached NTFS volume. It will not appear in the local NTFS volume list in the same way as an internal disk.

For a share, consider a folder index or run Everything on the computer that locally hosts the data and connect through a properly secured supported method. Firewall and antivirus checks are relevant mainly when a remote client communicates with an Everything server. They are not the first explanation for a directly attached NTFS drive missing from the local index.

If security software appears to block Everything, review its logs and add the narrowest appropriate allow rule if organizational policy permits. Do not permanently disable antivirus or firewall protection.

5. Rebuild and Diagnose Only After Safer Checks

If the drive is confirmed as local NTFS, included in the database, accessible through the service or elevation, and not hidden by exclusions, the index itself may need refreshing.

5.1 Use Force Rebuild

Open Everything's index options and select Force Rebuild. This tells Everything to reconstruct its index from the configured sources. It is safer than manually deleting database files because it preserves the opportunity to verify configuration first and uses the application's supported rebuild process.

Allow the rebuild to finish before judging the result. Watch the status bar and avoid repeatedly restarting Everything during reconstruction. Then search for the unique test file and create a second test file to confirm both the initial build and live monitoring work.

Success means existing files from the drive appear after rebuilding and newly created files appear afterward. If both tests pass, stop troubleshooting.

5.2 Inspect the Index Journal and status information

If the database rebuilds but later stops updating, inspect Everything's Index Journal and available status information. Look for whether changes from the affected volume are being recorded. This helps distinguish a search-display issue from a journal-monitoring issue.

A journal that reflects the test file's creation while the result remains hidden points toward search options, filters, or omissions. No observed changes after creating the file points toward volume monitoring, access, disconnection, or journal problems.

5.3 Capture a short debug log

Use Everything's supported debug logging or debug console only long enough to reproduce the problem. Start logging, connect or rescan the affected drive, create the unique test file, and stop logging. Look for messages concerning the volume, NTFS access, USN Journal, database loading, or exclusions.

A debug log is most useful when it captures one controlled reproduction rather than hours of unrelated activity. Remove or protect logs before sharing them because filenames and paths can reveal sensitive information.

6. Run a Clean Temporary Test Before Broad Changes

If the problem remains unexplained, test with a clean Everything configuration. This can reveal whether the cause is an accumulated setting, portable profile, startup argument, or damaged configuration.

1. Record or export important settings from the current installation.
2. Exit all Everything interfaces and confirm which service, if any, remains active.
3. Place an official portable copy in a separate temporary folder.
4. Run it with a clean configuration, preferably as administrator for the first diagnostic test.
5. Enable only the affected local NTFS volume and create a new unique test file.
6. Do not add folder indexes, servers, custom filters, exclusions, or complex startup arguments yet.

If the clean copy indexes the drive, Windows and the file system are probably functioning. The fault is likely in the original profile's exclusions, instance selection, command-line options, or index configuration. Compare settings methodically instead of replacing everything at once.

If the clean elevated copy also cannot see the confirmed local NTFS volume, investigate the disk's mount state, encryption, file-system health, Windows permissions, security logs, and whether the device is truly presented as a local volume. Avoid deleting the original database until these safer tests have been completed.

7. Quick Fix Checklist

• Create a uniquely named file on the affected drive and search for its exact name.
• Confirm Windows reports the drive's file system as NTFS.
• Set the active Everything filter to Everything and clear all search syntax.
• Open the NTFS index options and select the correct volume.
• Enable Include in database for that volume.
• Enable USN Journal monitoring and test a new file or rename.
• Check exclusions, result omissions, hidden-item rules, and system-item rules.
• Confirm a removable NTFS drive is connected and identified correctly.
• Verify that the Everything service is installed and running.
• Run once as administrator to diagnose a service or access problem.
• Check for multiple instances, portable profiles, and modified shortcuts.
• Use Force Rebuild only after confirming the configuration.
• Use a clean temporary profile if the original configuration remains suspect.

Stop as soon as the affected drive returns expected existing results and newly created files appear promptly. Additional changes after success can obscure the original cause or introduce a new problem.

8. Frequently Asked Questions

8.1 Why does Everything not show my NTFS drive?

The most common causes are that Include in database is disabled, the Everything service is unavailable, the volume is removable and was not mounted during startup, an exclusion covers the drive, or a filter is hiding its results. First confirm the file system, create a unique test file, and inspect the NTFS index settings.

8.2 Should I rebuild the Windows Search index?

No. Everything and Windows Search use different indexing systems. Rebuilding Windows Search does not normally add a missing local NTFS drive to Everything. Use Everything's NTFS options and Force Rebuild when an Everything rebuild is actually needed.

8.3 Is Run as administrator the same as using the Everything service?

No. Running as administrator elevates the entire Everything application for that session. The Everything service performs the privileged indexing work while allowing the visible application to run as a standard user. Elevation is a useful test, while the service is usually the more convenient ongoing setup.

8.4 Why are old files visible but new files are missing?

That pattern usually indicates a stale index or a USN Journal monitoring problem. Verify monitoring for the volume, create and rename a test file, inspect the Index Journal, and use Force Rebuild if the configured index no longer matches the disk.

8.5 Can Everything index an NTFS-formatted NAS drive as a local NTFS volume?

Not merely because the NAS uses NTFS internally. A share accessed through SMB or another network protocol is not presented to the client as a directly attached local NTFS volume. Use an appropriate folder index or run Everything where the storage is locally attached, then secure any remote access properly.

8.6 Will deleting the Everything database fix missing results?

It may trigger reconstruction, but it should not be the first step. A disabled volume, wrong instance, exclusion, stopped service, or non-NTFS drive will remain a problem after deletion. Verify settings and use the built-in Force Rebuild command before considering manual database removal.