Everything Network Drive Not Indexing: How to Fix It

When a mapped drive, NAS folder, or Windows network share does not appear in voidtools Everything, the problem is usually not the local NTFS index. Everything can read local NTFS metadata directly, but remote locations generally need to be added as folder indexes and scanned on a schedule. Missing results can also come from a disconnected mapping, account-context mismatch, exclusion, active filter, stale folder index, alternate configuration, or unavailable share.

The safest approach is to confirm the symptom with one small test folder, check the relevant Everything settings, and verify Windows access before rebuilding anything. After each change, search for a uniquely named test file. If it appears with the correct UNC path, stop changing settings because the original indexing path is working.

1. Confirm the Symptom With a Small Safe Test

Start by separating an indexing problem from a search-query problem. Create a temporary folder on the affected share, provided you have permission, and place a harmless empty text file inside it. Give the file a distinctive name such as everything-network-test-4827.txt. Avoid using sensitive material or modifying an important production folder.

In Everything, clear the search box and disable any filter that could hide the file. Then search for the exact filename without adding path restrictions or advanced operators. If the file appears, Everything can index at least that location, and the original query, filter, exclusion, or subfolder may be the problem. If it does not appear, continue with the folder-index and Windows-access checks.

1.1 Compare the UNC path and mapped drive

Test whether Windows can open both forms of the location:

• \\server\share\test-folder
• Z:\test-folder, if the share is mapped as drive Z

A UNC path identifies the share independently of a drive letter assigned within a particular sign-in session. This makes UNC paths more dependable for folder indexing, especially when Everything starts elevated, runs under another account, or launches before mapped drives reconnect.

Success means File Explorer can open the UNC location under the same user account that is running the Everything interface. If Windows itself cannot reach the share, correct that problem before changing more Everything settings.

1.2 Distinguish Everything from Windows Search

Everything and Windows Search are separate systems. Windows Search uses Windows indexing components and can index file contents and selected locations. Everything is primarily a filename search application and maintains its own database. Changing Windows Search indexing locations will not normally add a network share to Everything.

Likewise, the Everything service mainly allows Everything to index supported local file systems without requiring the user interface to run as administrator. Installing or restarting that service does not automatically add every mapped drive or network share to the folder index.

2. Add the Network Share to Folder Indexing

For a network location, the central setting to inspect is folder indexing. In Everything, open Tools > Options > Indexes > Folders. Add the share using its UNC path, such as \\nas01\documents, rather than relying only on a mapped drive letter.

Confirm the folder entry is enabled and points to the intended share. A typo in the server name, share name, or subfolder can produce an empty or incomplete index even if a similar path works in File Explorer.

After adding the folder, allow the initial scan to finish. Search for the distinctive test filename and inspect the full path in the result. Success means the test file appears under the expected UNC location. At that point, do not force additional rebuilds unless other files from the same indexed tree are still missing.

2.1 Configure scheduled folder rescans

Unlike direct local NTFS indexing, folder indexing may depend on rescans to discover changes reliably. This is especially important for NAS devices and network file systems that do not provide change notifications in the same way as a local Windows volume.

In the folder-index settings, configure an update or rescan schedule appropriate for the share. A frequently changing team share may need shorter intervals than an archive that changes once a day. Avoid excessively aggressive scans on a large NAS because repeated directory enumeration can add network and storage load.

To validate the schedule, let the first scan complete, create a second uniquely named test file, and wait for the configured update. Success means the new file appears without manually rebuilding the entire database. Once that happens, the schedule is doing its job.

2.2 Understand stale entries from offline shares

A temporarily unavailable network share can leave older names visible in Everything. Folder-index data is stored in Everything's database, so an offline share does not necessarily cause every previously indexed result to vanish immediately. This can be useful because filenames remain searchable, but the paths will not open while the server is unavailable.

A failed or incomplete rescan may also leave results out of date. Reconnect the share and confirm it opens in File Explorer, then request a normal rescan. Only consider a broader force rebuild after connectivity and permissions are known to be good.

Success means deleted files disappear and newly created files appear after a completed scan. If the share goes offline again, cached names may remain, which is not proof that the files are currently reachable.

3. Check Filters, Exclusions, and Search Options

If the folder is indexed but Everything results are missing, clear the search state before changing the index. Select the broadest filter, commonly Everything, and remove search modifiers, path operators, regular-expression mode, case matching, whole-word matching, and other restrictive options.

Search only for the unique test filename. If it appears after clearing the search state, indexing is working. Reintroduce the original filter or syntax one element at a time to identify the part that hid the result.

3.1 Review exclusions and result omissions

Open the exclusion-related Options page and inspect excluded folders, files, extensions, and patterns. Look for rules matching any of these components:

• The UNC server name
• The share name
• The mapped drive letter
• A parent directory
• The test file's extension
• A wildcard broad enough to match the location

Temporarily disable only the suspicious exclusion, then run the same exact-filename test. Do not erase a long exclusion list without recording it. If the file appears, narrow or correct the rule rather than leaving necessary exclusions disabled.

Also check whether a temporary result-omission feature has hidden the item from the current view. Resetting the search or reopening Everything may clarify whether the omission is temporary or configuration-based.

3.2 Verify the indexed folder scope

A folder-index entry for \\server\share\DepartmentA will not cover its sibling \\server\share\DepartmentB. Compare the missing file's complete path with the configured root. Also verify that the account can enumerate every parent folder needed to reach the file.

If only one branch is missing, test a file directly in the configured root and another in the affected branch. A root-level success with a subfolder failure points toward permissions, exclusions, an inaccessible junction, or a device-specific directory issue rather than a completely broken folder index.

4. Resolve Mapped Drive and Account-Context Problems

Windows drive mappings can differ between user sessions and privilege levels. A drive letter visible to a standard desktop application may not be visible to an application started with Run as administrator. This behavior is a common reason Everything can browse local files but cannot see a mapped network drive.

Where possible, run the Everything user interface as your normal standard user and use the Everything service for supported local indexing privileges. Do not elevate the interface merely to fix network-drive search. For the network folder entry, use a UNC path rather than a mapped letter.

Success means the standard-user Everything interface can open the UNC path and index the test file while the service handles its separate local-indexing role. If that works, keep the simpler configuration and stop troubleshooting elevation.

4.1 Confirm share and NTFS permissions

The account performing the folder scan needs permission to list directories and read filename metadata throughout the intended path. Both share permissions and file-system permissions can affect access. Being able to open the share root does not guarantee access to every subfolder.

Use File Explorer under the same interactive account to navigate to the exact folder and view the test file. If Windows asks for credentials, reports access denied, or shows only part of the tree, resolve those permissions with the share administrator. Do not weaken permissions for everyone merely to make indexing work.

4.2 Check startup and reconnection timing

Everything may start before a mapped drive reconnects after sign-in. Wi-Fi, VPN, domain authentication, and NAS wake-up delays can make the share unavailable during the initial scan.

Prefer a UNC folder entry, ensure the network or VPN is connected, and trigger a rescan after the share becomes reachable. If this consistently fixes the issue, adjust the application or sign-in workflow so scanning occurs after network connectivity is established. Avoid embedding passwords in scripts or command lines.

4.3 Consider the remote file system

A NAS share may be backed by ext4, ZFS, Btrfs, APFS, or another file system, but Windows commonly accesses it through SMB. Everything cannot read the remote disk's local NTFS metadata through an ordinary SMB mapping. It must enumerate the shared folders or query an Everything server that indexes files on the remote Windows machine.

This is why local NTFS troubleshooting instructions, such as checking the USN journal on the workstation, usually do not solve an Everything network drive not indexing problem.

5. Check Service, Server, Portable, and Command-Line Settings

Confirm that you are editing the configuration used by the running Everything instance. Portable copies, named instances, custom configuration files, and different shortcuts can each load separate settings or databases. Adding a folder in one instance will not necessarily add it to another.

Close extra Everything windows, launch the shortcut you normally use, and inspect its folder-index list. Check the shortcut target for command-line options that select an instance, configuration file, database, or portable behavior. Remove nothing until you understand why the option exists.

Success means the folder entry remains present after restarting the same instance and the test filename still appears.

5.1 Understand the Everything service

Check the service state if local indexing or communication with the normal user interface is also failing. However, treat it as a separate component from remote folder enumeration. Restarting the service may correct a service communication problem, but it will not repair an inaccessible UNC path or automatically create a folder-index entry.

Running the interface as a standard user with the service is generally preferable to keeping the entire interface elevated. This also reduces mapped-drive visibility surprises.

5.2 Check server or remote-client mode

If your Everything window connects to another Everything server, its results come from the server's database. Adding a folder index only on the client may not affect searches executed against that server. Configure indexing on the machine that owns the searchable database, then confirm the client is connected to the intended server.

Use authenticated, trusted network access and appropriate firewall rules. Do not expose an Everything search service directly to the public internet. A VPN, private network, or other properly secured access method is safer.

Success means the test file appears when querying the intended server and its path reflects the server's indexed location. Stop changing the client's local folder index if the search is entirely server-backed.

5.3 Review firewall and antivirus behavior carefully

Firewall or endpoint-security controls can block SMB access, server connections, or application activity. First verify whether File Explorer can open the same UNC path. If Explorer also fails, investigate Windows networking, VPN, DNS, SMB policy, or firewall rules rather than rebuilding Everything.

If only Everything fails, review security-product logs and create the narrowest approved rule needed for the executable, destination, or private-network connection. Do not disable antivirus or firewall protection permanently. In managed environments, ask the security administrator to confirm the block and approve any exception.

6. Use Diagnostic Tools Without Destroying Useful State

The status bar can reveal whether Everything is scanning, updating, or returning a limited result set. Watch it after adding the test share or requesting a rescan. A scan that never progresses suggests access, connectivity, or a problematic directory. A completed scan with zero matching results suggests scope, exclusions, or profile mismatch.

Review the relevant Options pages side by side: Folders, Exclude, Filters, service settings, and any server or connection settings. Record the current values before changing them.

6.1 Use Force Rebuild only after basic checks

A force rebuild can be appropriate when the configured path is reachable, permissions are correct, the folder entry is enabled, and normal rescans repeatedly leave the index inconsistent. It is not the first step because rebuilding a large network share can consume time and network resources without fixing the underlying cause.

Before rebuilding, test a normal rescan and confirm the share remains online. After initiating the rebuild, allow it to finish and search for the unique test file. Success means both the test file and representative existing files appear with current paths.

Do not delete the Everything database manually as an opening move. That removes useful diagnostic state and can force unnecessary reindexing of every configured location.

6.2 Inspect debug logs and the Index Journal

If your installed build provides debug logging, enable it only long enough to reproduce the failed scan. Look for the configured UNC path, access-denied responses, unavailable network names, configuration-file differences, or repeated scan failures. Remove or redact server names, usernames, and sensitive paths before sharing logs.

If an Index Journal view is available in your build, use it to see whether the expected add, update, or delete event reached the database. These tools are most useful after the simple filename test has established a repeatable failure.

Disable verbose logging when finished so logs do not grow unnecessarily. Success means the log identifies a specific failing path or the expected index update appears after the correction.

6.3 Run targeted search-syntax tests

Start with the filename alone, then progressively narrow the search. For example, test the unique filename first, then add the share name or a path restriction. This shows whether the file is absent from the database or merely excluded by the original query.

If the plain filename appears but the path-restricted query does not, inspect path spelling, slash escaping, quotation marks, regular-expression mode, and filter state. Do not rebuild the index to solve a query-syntax error.

7. Run a Clean Temporary Test Before Broad Changes

If the cause remains unclear, use a separate temporary Everything profile or portable test copy from the official source. Keep it isolated from the normal database and configuration. Do not overwrite your working profile.

1. Create a small test share containing only a few harmless files.
2. Confirm the UNC path opens as the current standard user.
3. Launch the clean test instance without unnecessary command-line options.
4. Add only the test UNC path under folder indexing.
5. Allow the scan to complete and search for the unique filename.
6. Create another test file and verify the configured rescan discovers it.

If the clean profile succeeds, Windows networking and basic folder indexing work. Compare its folder, exclusion, filter, server, startup, and instance settings with the normal profile one category at a time. If the clean profile also fails, focus on share access, account context, security controls, or the remote server.

Testing with a small share first prevents a lengthy scan from hiding the actual problem. It also provides a clear success condition: initial files appear, a newly created file appears after rescan, and a deleted test file disappears after a successful update.

8. Quick Fix Checklist

• Open the exact share in File Explorer using its UNC path.
• Create and search for one uniquely named test file.
• Clear filters, advanced search modes, and restrictive query syntax.
• Add \\server\share under Options > Indexes > Folders.
• Prefer the UNC path over a mapped drive letter.
• Run the Everything interface as a standard user when possible.
• Use the Everything service for its local-indexing role, not as a substitute for folder indexing.
• Check folder exclusions and confirm the configured root includes the missing path.
• Set a reasonable scheduled rescan for the network folder.
• Reconnect an offline share before judging whether its cached index is current.
• Verify that portable copies, instances, shortcuts, and command-line options use the intended profile.
• Confirm whether searches are local or sent to an Everything server.
• Review security logs instead of permanently disabling protection.
• Try a normal rescan before using Force Rebuild.
• Use a small clean test profile before changing many settings at once.

You are finished when the unique test file appears at the correct UNC path and a second file is discovered through the normal update schedule. Continuing to change unrelated settings after that point can create a new problem.

9. Frequently Asked Questions

9.1 Why does Everything find local files but not my mapped drive?

Everything can index supported local NTFS volumes through file-system metadata. A mapped drive is a network location, so it generally needs to be added under folder indexing or indexed by an Everything server on the remote machine. Add the UNC path and schedule appropriate rescans.

9.2 Why does the mapped drive disappear when Everything runs as administrator?

Windows can maintain different mapped-drive visibility between standard and elevated sessions. Run the Everything interface as your standard user, use the service for supported local indexing, and add the network location by UNC path. This avoids depending on an elevation-specific drive-letter mapping.

9.3 Why are deleted network files still shown?

The network share may be offline, its rescan may not have completed, or the folder index may not yet have received the change. Reconnect the share and run a normal rescan. Cached names can remain searchable while the underlying files are unavailable.

9.4 How often should Everything rescan a network folder?

Choose an interval based on how quickly results must update and how large or busy the share is. Short intervals improve freshness but increase network and NAS activity. Validate the schedule with a new test file instead of assuming the shortest interval is best.

9.5 Should I rebuild or delete the Everything database?

Try access checks, UNC folder indexing, filters, exclusions, account context, and a normal rescan first. Use Force Rebuild only when the share is reachable and the configuration is correct but the index remains inconsistent. Manual database deletion should not be the first troubleshooting step.

9.6 Can Everything search file contents on my NAS?

This troubleshooting process concerns filename and path indexing. Everything is primarily designed for fast filename search, while content-search behavior is a separate feature with different performance and configuration considerations. First confirm that network filenames are indexed correctly before investigating content search.