Everything ReFS Volume Not Indexed: How to Fix It

When an ReFS volume is missing from voidtools Everything, returns stale results, or shows only some files, the problem usually falls into one of four categories: the volume is not enabled for ReFS indexing, Everything lacks the required access context, a filter or exclusion is hiding results, or the index needs to be refreshed. ReFS behaves differently from NTFS, so advice intended for an NTFS index or a mapped network share may not solve the problem.

This guide walks through the safest checks first. Test after each change and stop as soon as the expected files appear. Changing many options at once makes it harder to identify the real cause and can turn a small configuration issue into a lengthy rebuild.

1. Confirm the Symptom With a Small Safe Test

Before changing Everything, verify that the affected location is actually an ReFS volume and create a harmless test file. This separates an indexing problem from a filename, filter, or path misunderstanding.

1.1 Confirm the file system type

Open File Explorer, right-click the affected drive, select Properties, and look for the file system. It should say ReFS. You can also open PowerShell and run Get-Volume to review the drive letter, file system, health status, and volume information.

Do not assume a storage location uses ReFS because it resides on a Windows Server, Storage Spaces pool, NAS, or large disk. A local drive may use NTFS, while a NAS path is usually exposed through SMB and does not appear to Everything as a directly attached ReFS volume.

If the location is a mapped drive or a path beginning with two backslashes, troubleshoot it as a network share and consider folder indexing. Native ReFS volume indexing applies when Windows presents the ReFS volume locally to the computer running Everything.

1.2 Create and search for a unique test file

Create a small empty text file in a folder you are allowed to modify on the affected volume. Give it a distinctive name such as refs-index-test-4821.txt. Search Everything for the complete filename without adding filters.

• If the new file appears quickly, ReFS indexing is operating and the original query, filter, exclusion, or result settings are the likely cause.
• If old files appear but the new file does not, the index may be stale or journal monitoring may not be updating correctly.
• If neither old nor new files appear, check whether the volume is included and accessible.
• If the file appears only after a manual rebuild, initial scanning works but live updates need further investigation.

Success means the exact test filename appears with the correct ReFS path. Once that happens, stop changing volume and service settings and investigate only the narrower search that originally failed.

2. Check the ReFS Index and Search Settings

The most direct Everything ReFS volume not indexed fix is often found in Everything's index options. Names and layouts can vary between builds, so look for an ReFS page or volume list under Tools, Options, and Indexes rather than relying on an exact screenshot.

2.1 Verify that the ReFS volume is included

Open Everything and go to Tools > Options > Indexes. Select the ReFS-related page if one is available. Confirm that the affected volume is listed and enabled for indexing.

Check the volume identity and path carefully. Drive letters can change after reconnecting storage, moving disks between machines, modifying Storage Spaces, or booting with portable storage disconnected. If Everything retains an entry for an old volume while the current one is disabled, results can be absent or stale.

Apply the change and allow Everything to scan. Success means the status bar finishes indexing and the unique test filename becomes searchable. Large volumes may require time for their initial scan, so do not force another rebuild merely because results are not complete immediately.

2.2 Remove accidental search restrictions

Clear the search box and disable any temporary filters. In the Search menu, choose the broadest normal option, commonly Everything, rather than Audio, Documents, Folders, or another limited filter. Turn off options such as Match Case, Match Whole Word, Match Path, and regular-expression mode unless the test requires them.

Search first for the exact test filename. Then search for a path fragment from the ReFS drive. If the file appears in the broad search but not the original one, the index is healthy and the query syntax or active filter is responsible.

Also check whether a custom filter contains a restrictive macro. A filter can silently add extensions, paths, attributes, or other conditions to every query. Everything's search is separate from Windows Search, so rebuilding the Windows Search index will not correct an Everything filter or ReFS index setting.

2.3 Review exclusions and omitted results

In Options, inspect exclusion settings for the ReFS drive letter, volume path, folder, wildcard, or file extension. Remove only exclusions that unintentionally cover the missing content. Keep deliberate exclusions for private, temporary, backup, or high-churn data.

If result omission features are in use, restore omitted results or test with omission disabled. Missing results can also be caused by a command-line option, shortcut parameter, custom configuration file, or portable configuration that starts Everything with a restricted database, path, instance, or filter.

Success means the test file appears after the specific exclusion or restriction is removed. Stop at that point rather than rebuilding the whole database.

3. Check Access, Service State, and Account Context

Everything needs an appropriate way to read and monitor supported local file-system metadata. Depending on its configuration, it may obtain access through elevation or the Everything service. ReFS permissions, security software, startup order, and account context can affect whether the volume is discovered or kept current.

3.1 Check the Everything service

Open Everything's general options and check whether the Everything service is installed and enabled. You can also open the Windows Services console and locate the Everything service. Confirm that it is running and is not repeatedly stopping.

If the service is expected to provide index access, restart Everything after confirming the service is running. A one-time test with Everything launched as administrator can help distinguish an access problem from a search-setting problem. Do not run every application elevated unnecessarily. If elevation fixes the issue, configure the supported service arrangement instead of treating permanent elevation as the only solution.

Success means the ReFS volume becomes available in the index options and the test file appears while Everything runs normally under the intended user account.

3.2 Compare interactive and startup behavior

If the volume works after manually opening Everything but is missing after sign-in or reboot, examine startup timing. Removable disks, Storage Spaces volumes, encrypted storage, and server-mounted data may become available after Everything starts.

Exit and reopen Everything after the volume is fully online. If that resolves the issue, adjust the startup arrangement so Everything or its indexing component sees the volume after Windows has mounted it. Also verify that a startup shortcut is not launching a different Everything instance, executable, configuration, or portable copy.

Portable users should confirm that the configuration and database files are writable. Running one copy from a protected folder and another from a user-writable folder can create two different configurations, making an ReFS option appear to reset or differ between launches.

3.3 Treat network locations separately

A server may store its data on ReFS while exposing the files to your workstation through an SMB share. Your workstation does not receive the server's local ReFS metadata merely because the server uses ReFS. From the workstation's perspective, this is a network folder.

For a network share, use Everything's folder indexing features or query an Everything server configured on the file server, depending on your environment. If using server functionality, bind and firewall it carefully, limit access to trusted networks, and do not expose a file-search service directly to the public internet.

Success means the share is indexed by the method appropriate to a remote folder. Do not expect it to appear in the local ReFS volume list.

3.4 Review security software without disabling protection permanently

Antivirus or endpoint controls can block an executable, service, database file, or configuration folder. Check protection history and event logs for a specific detection involving Everything. If organizational policy permits, create the narrowest approved exception for the trusted executable or required data path.

Do not disable endpoint protection permanently. If there is no recorded block and the ReFS volume is visible to Windows, continue with Everything's diagnostics rather than assuming security software is responsible.

4. Diagnose a Stale or Incomplete ReFS Index

If the ReFS volume is enabled but Everything results are missing or not updating, determine whether the problem affects initial enumeration, live updates, or only one profile.

4.1 Read the status bar and wait for completion

Everything's status bar can indicate whether indexing is underway and how many objects are available. On a large ReFS volume, an initial scan or rebuild can take time and consume storage activity. Results may populate progressively.

Keep the volume connected and avoid repeatedly restarting the application during the scan. Search for several known files in different directories. If the object count is increasing, allow indexing to finish before taking stronger action.

Success means the indexing activity completes, the result count stabilizes, and both old and newly created test files appear. Large-volume expectations should be based on observed progress, not on a fixed completion time, because storage speed, file count, hardware, and system load vary substantially.

4.2 Compare native ReFS indexing with folder indexing

As a controlled diagnostic, add one small folder from the affected volume to Everything's folder index. Do not add the entire large volume immediately. Let the folder scan complete and search for the test file.

• If folder indexing finds the file but native ReFS indexing does not, the search expression and basic read permissions are probably valid. Focus on ReFS volume detection, service access, and native index configuration.
• If neither method finds the file, inspect exclusions, permissions, instance selection, and filters.
• If folder indexing works and meets your needs, it can be a practical fallback, although updates may depend on rescanning rather than the behavior expected from native volume monitoring.

Avoid indexing the same large tree through multiple methods long term unless you have a specific reason. Duplicate indexing can complicate troubleshooting and may produce duplicate or confusing results.

4.3 Use Force Rebuild only after safer checks

Once you have confirmed the correct volume, service state, exclusions, and search mode, use the relevant Force Rebuild control in the index options. A rebuild is appropriate when the configured index is demonstrably stale or internally inconsistent.

Allow the rebuild to complete. Do not delete database files manually as a first step. Manual deletion can discard useful state, affect other indexed volumes, and conceal the configuration issue that caused the symptom.

Success means existing files repopulate and the new test file is detected afterward. If a rebuild restores old files but later changes remain missing, the remaining issue concerns ongoing monitoring, service continuity, or volume availability rather than the initial database population.

4.4 Collect debug information for recurring failures

If the problem returns, enable Everything's supported debug logging or use its debug console long enough to reproduce one event. Note the time, affected volume, whether the service was running, and whether the volume had just mounted or resumed from sleep.

Inspect Index Journal information if your Everything build exposes it. Look for clear errors involving opening, monitoring, or rescanning the affected volume. Avoid posting logs publicly without reviewing them because filenames and paths can reveal sensitive information.

Logs are most useful when the symptom is repeatable. Disable verbose diagnostics after collecting the necessary evidence so logs do not grow indefinitely.

5. Run a Clean Temporary Test

When normal settings look correct, a temporary clean profile can reveal whether the current configuration is responsible. This is safer than immediately deleting the working database or resetting every option.

5.1 Isolate configuration without destroying it

1. Exit the existing Everything instance cleanly.
2. Preserve the current configuration and database files by backing them up or leaving them untouched.
3. Launch a trusted copy with a separate instance name or temporary configuration, using supported instance or configuration options.
4. Enable only the affected ReFS volume and the service arrangement required for the test.
5. Search for the unique test filename with no filter or advanced syntax.

If the clean instance works, compare its ReFS, exclusion, filter, service, database-location, and command-line settings with the original profile. Restore settings gradually until the difference is identified.

If the clean instance also fails, the cause is more likely to involve volume presentation, access, the service, security controls, or compatibility with the current environment. At that point, preserve diagnostic details and consult official voidtools support resources rather than repeatedly rebuilding.

6. Quick Fix Checklist

• Confirm Windows reports the affected local volume as ReFS.
• Verify that the missing location is not actually an SMB share or mapped drive.
• Create a uniquely named test file and search without filters.
• Enable the correct volume in Everything's ReFS index options.
• Clear search syntax, custom filters, exclusions, and omitted-result settings.
• Confirm the Everything service is installed and running when required.
• Check whether launching once as administrator changes volume detection.
• Verify startup shortcuts open the intended instance and configuration.
• Allow large-volume indexing to finish while watching status progress.
• Test one small directory with folder indexing for comparison.
• Use Force Rebuild only after confirming the configuration.
• Run a separate clean-profile test before deleting databases or resetting everything.

After any step makes the test file appear and remain current, stop changing settings. Confirm the result by renaming the file once and creating one additional file. If both changes appear as expected, the Everything index is working.

7. Frequently Asked Questions

7.1 Why does Everything show my NTFS drive but not my ReFS drive?

The two file systems can have separate index pages and access requirements inside Everything. Confirm that the ReFS volume is enabled explicitly and that the Everything service or elevated access is available as required. Also verify that Windows presents the storage as a local ReFS volume rather than a network share.

7.2 Will rebuilding Windows Search fix Everything?

No. Everything and Windows Search are separate products with different indexes and search behavior. Rebuilding Windows Search does not rebuild Everything's database. Use Everything's own ReFS options, status information, and Force Rebuild function.

7.3 Should I delete the Everything database?

Not initially. First check the ReFS volume selection, filters, exclusions, service state, startup instance, and indexing progress. Use Everything's supported rebuild control if the index is stale. A clean temporary instance is a better diagnostic step than immediately deleting the existing database.

7.4 Why does folder indexing find files that ReFS indexing misses?

Folder indexing reads the directory tree through normal folder access, while native volume indexing uses a different mechanism and configuration. That contrast suggests the files are readable and the search itself works, narrowing the fault to ReFS volume detection, native index settings, service access, or update monitoring.

7.5 How long should a large ReFS volume take to index?

There is no universal time. File count, directory structure, storage speed, system load, connection type, and whether this is an initial scan or rebuild all matter. Watch the status bar and object count. If progress continues, wait. If progress stops and known test files remain absent, investigate logs and volume access.

7.6 Can Everything index an ReFS volume on my NAS?

Only according to how that storage is presented to the machine running Everything. If the NAS exposes an SMB share, treat it as a network folder even if the NAS internally uses ReFS or another file system. Use folder indexing or an appropriately secured Everything server on the host that sees the volume locally.