Everything Offline Folders Still in Results: How to Fix It

If Everything still shows files and folders from a network share, NAS, removable drive, or portable disk that is currently offline, the results are usually coming from a stored folder index. They do not prove that the path is connected or that the files remain accessible. The safest fix is to identify the relevant folder index, decide whether you want to preserve its offline snapshot, and then rescan or remove that index deliberately.

This symptom is different from Windows Search behavior. Windows Search relies on Windows indexing components and configured search locations, while voidtools Everything maintains its own filename database. Everything can index NTFS volumes directly and can also index ordinary folders, network shares, and other file systems through folder indexing. Folder indexes are especially important here because their entries can remain in the database when the source becomes unavailable.

Before rebuilding anything, confirm which index supplied the stale results. Most cases can be resolved without deleting the entire Everything database, changing security software, or resetting every option.

1. Confirm the Symptom With a Small Safe Test

Start with one known offline location rather than judging the database from a broad search. Choose a distinctive folder or filename that exists only on the disconnected source. For example, if an offline NAS share contained a folder named NAS-Archive-2023, search for that exact name.

1. Search for the distinctive folder or file in Everything.
2. Right-click the result and inspect its full path.
3. Try to open the containing path in File Explorer.
4. Note whether Windows reports that the drive, share, or network path is unavailable.
5. Check whether current files from connected locations still appear normally.

If Everything shows the result but File Explorer cannot open the location, you have confirmed the key distinction: Everything has a cached filename record, but Windows does not currently have live access to the source.

1.1 Check Whether the Result Comes From a Folder Index

Open Tools > Options > Indexes > Folders. Look for the drive root, UNC path, mapped drive, or subfolder associated with the stale result. Examples include Z:\, \\nas\archive, or a removable-drive path.

If the source appears in this list, Everything is maintaining a folder index for it. This is the most likely explanation for offline entries remaining searchable. Folder indexing stores names and paths in the Everything database and may retain the previous snapshot if a source cannot be scanned.

Success at this stage means you can match the stale search result to a specific configured folder index. Once you have that match, stop investigating unrelated Windows Search settings or NTFS indexing options.

1.2 Rule Out a Duplicate Path

The same storage may have been added more than once, such as through both a mapped drive and a UNC path. A NAS folder might therefore appear as both Z:\Projects and \\server\projects. One entry can be online while the other is stale.

Search for a distinctive filename and compare every matching full path. Then review the Folders options page for duplicate representations of the same source. Removing an obsolete duplicate folder index is often safer and faster than rebuilding the complete database.

2. Check the Everything Settings Directly Related to Offline Results

Do not change every setting at once. Work through the folder entry responsible for the symptom and verify the result after each change.

2.1 Decide Whether Offline Entries Should Be Kept

Keeping offline entries can be intentional and useful. A laptop user may want to search the catalog of a USB archive without carrying the disk. A sysadmin may want to locate a filename on a temporarily unavailable NAS before reconnecting it. In those cases, the stored index acts as a filename catalog, not a live availability check.

If that behavior is useful, no repair may be necessary. Keep the folder index and treat its results as references to files that require the source to be reconnected. Stop changing settings once you confirm that the displayed paths belong to the expected offline index.

If you need search results to represent only currently available locations, remove the offline folder from the folder-index configuration or arrange a deliberate reconnect-and-rescan routine.

2.2 Understand Manual Rescan Behavior

A manual rescan asks Everything to enumerate the configured folder again. It does not necessarily mean that an unreachable source will be interpreted as an empty folder. Retaining the previous snapshot is safer than erasing a useful catalog merely because a network connection or removable disk is temporarily unavailable.

For that reason, repeatedly selecting Rescan Now while the share is offline may not remove the old entries. A failed scan and a successful scan of an empty location are not equivalent.

If you want to refresh the index, reconnect the source first, confirm that File Explorer can enumerate it, and then run the rescan. Success means newly created files appear, deleted files disappear, and existing results open normally. Once those conditions are met, stop troubleshooting.

2.3 Remove an Unwanted Folder Index

If the source has been retired or you no longer want its offline catalog, remove its entry from Tools > Options > Indexes > Folders. Select the exact folder, choose the available remove action, apply the change, and allow Everything to update its database.

Removing the configured folder index is more targeted than deleting the whole database. It preserves indexes for your local volumes and other working sources.

After removal, repeat the distinctive filename search. Success means results belonging only to that indexed path disappear while results from unrelated locations remain intact. If this happens, no Force Rebuild is needed.

2.4 Review Exclusions and Result Omission Separately

Exclusions can hide an unwanted path without removing its underlying folder-index configuration. This may be appropriate when you want to preserve the catalog but omit it from ordinary searches. However, exclusions can also make troubleshooting confusing because an index may still exist even though its results are hidden.

Review the exclusion settings for rules matching the offline drive, share, or folder. Also check whether you are using a filter, bookmark, macro, or search expression that includes or omits specific paths.

Use a plain filename search with the normal Everything filter when testing. If the entry appears only under a particular filter or bookmark, correct that search configuration instead of rebuilding the index.

2.5 Check Startup and Command-Line Options

A shortcut, script, scheduled task, or portable launcher can start Everything with command-line options or a nondefault configuration file. That can make a removed folder index appear to return because you are opening a different Everything profile.

Inspect the shortcut target and any startup scripts. Look for arguments that select another instance, configuration file, database, or startup mode. If Everything is portable, verify the directory from which it is running and where its configuration is stored.

Success means every launch opens the same intended profile and the Folders page contains the expected entries. Stop changing index settings if the real problem was simply that two profiles were being used.

2.6 Consider Server and Client Configurations

If your Everything installation receives results from another Everything instance or server configuration, the stale folder index may belong to the remote instance rather than the local computer. Changing local folder-index settings will not alter a database maintained elsewhere.

Confirm which instance owns the index, then make changes on that system. Keep file-search services limited to trusted networks and protected configurations. Do not expose an Everything server directly to the public internet merely to test connectivity.

3. Check Windows Access and Account Context

Everything can rescan a folder only when the process performing the scan can access it. A share that opens in one account may remain inaccessible to a service or to another user session.

3.1 Test the Exact Path in File Explorer

Paste the configured path from Everything into File Explorer. For a mapped drive, also test the equivalent UNC path if you know it. Mapped drive letters are associated with a user session and may not exist for a service account, elevated process, or different login session.

If Z:\Archive fails but \\nas\archive works, consider configuring the reachable UNC path instead of relying on the mapped drive. Avoid indexing both unless you intentionally want duplicate paths.

Success means the exact path configured in Everything opens and lists files under the account context used for scanning.

3.2 Verify Credentials and Permissions

A cached index can remain searchable even after credentials expire or share permissions change. Confirm that Windows can authenticate to the share and that the relevant account has permission to list the folder.

If Everything runs as a Windows service or under a different account, remember that access available to your desktop account is not automatically available to the service. Review the Everything service arrangement and the permissions of the account performing folder access. Do not broaden share permissions beyond what is necessary.

3.3 Check Network and Security Controls Carefully

For a NAS or remote Windows share, confirm that the host is online, name resolution works, and the required file-sharing connection is allowed on the trusted network. A firewall or endpoint-security product may block access, but disabling protection permanently is not an appropriate fix.

Use logs and narrowly scoped allow rules where required. First prove that the same path is inaccessible in File Explorer. If Windows itself cannot enumerate the folder, Everything cannot perform a reliable folder rescan.

3.4 Account for Removable Media and File System Type

Everything can maintain fast, directly updated indexes for supported local NTFS volumes, while folder indexing is used for locations that are not indexed in the same way, including many network shares and non-NTFS removable devices. A USB device formatted as exFAT or another file system may therefore depend on scheduled or manual folder rescans.

Also confirm that Windows assigned the expected drive letter. If a removable disk previously appeared as E: but now appears as F:, the old folder index and the newly connected path can coexist as separate locations. Assigning a stable drive letter in Windows Disk Management may prevent repeated mismatches, provided that doing so is appropriate for the system.

4. Use Focused Everything Diagnostics

If the folder setting looks correct but the problem remains, collect evidence before using broader repair actions.

4.1 Watch the Status Bar During Tests

The status bar can help confirm whether a search is still processing and how many results match. Run the exact-name test before and after changing one folder index. A falling result count is useful, but the decisive check is whether the stale full path has disappeared.

4.2 Use Path-Limited Search Syntax

Limit a search to the affected location rather than scanning visually through thousands of results. You can search for the distinctive filename together with its path, or use Everything's path-oriented search features. Test the mapped-drive form and UNC form separately when duplicate indexing is suspected.

This identifies whether only one representation is stale. If the obsolete mapped-drive results disappear after its folder index is removed while UNC results remain current, the repair is complete.

4.3 Use Force Rebuild Only After Targeted Checks

A Force Rebuild can regenerate the Everything database from the currently configured indexes. It is reasonable when the configuration is correct but database results remain inconsistent after a successful rescan or folder removal.

Before rebuilding, verify that the unwanted folder is no longer configured. Otherwise, a rebuild may simply add it again or preserve the same intended configuration. Rebuilding can also temporarily reduce search availability while indexes are recreated.

Success means the rebuilt database contains current locations and no longer returns the removed offline path. Do not delete database files manually before trying the supported folder removal, rescan, and rebuild controls.

4.4 Review Debug Output or the Index Journal When Available

Everything diagnostic output can reveal failed folder enumeration, inaccessible paths, repeated reconnect attempts, or configuration loading from an unexpected location. If your installation exposes an Index Journal or related diagnostic view, use it to look for changes involving the affected folder.

Capture only the period in which you reproduce the problem. Logs can contain filenames, usernames, server names, and internal paths, so redact sensitive information before sharing them.

5. Run a Clean Temporary Test Before Changing More Settings

If you cannot tell whether the issue comes from the database, a portable configuration, a startup argument, or a filter, run a temporary clean test. Do not overwrite the working profile.

1. Record the exact affected path and one distinctive filename.
2. Close unnecessary Everything instances.
3. Start a separate temporary instance or clean profile using supported instance or configuration controls.
4. Add only one small, accessible test folder.
5. Confirm that its files appear.
6. Make that test source unavailable and observe whether its folder-index records remain.
7. Reconnect it, verify access in File Explorer, and rescan.
8. Remove the test folder index and confirm that its results disappear.

This test demonstrates the difference between live file access and a stored filename catalog without risking your primary database. It also reveals whether the original profile contains a duplicate folder entry, exclusion, custom filter, or startup configuration.

If the clean profile behaves correctly, return to the original profile and compare only the relevant Folders, Exclusions, Filters, service, and startup settings. Avoid copying the entire clean configuration over the working setup unless you are prepared to recreate intentional customizations.

6. Quick Fix Checklist

• Search for one distinctive filename from the offline source.
• Confirm that its full path cannot be opened in File Explorer.
• Open Tools > Options > Indexes > Folders.
• Match the stale path to its configured folder index.
• Check for duplicate mapped-drive and UNC entries.
• Keep the index if you want an offline filename catalog.
• Reconnect the source before requesting a meaningful rescan.
• Verify credentials, permissions, drive letters, and account context.
• Remove the folder index if the source is retired or no longer wanted.
• Retest with the same exact filename and path.
• Use Force Rebuild only if targeted removal or rescan does not update results.
• Check alternate profiles, shortcuts, server instances, and portable settings if entries return.

The correct stopping point is when the behavior matches your intent. If the offline catalog is useful and correctly identified, there is nothing to fix. If you removed the folder index and its paths no longer appear, do not continue resetting unrelated settings.

7. Frequently Asked Questions

7.1 Why does Everything show files that I cannot open?

Everything searches its filename database. A result can remain in that database after a folder-indexed network share or removable device goes offline. Opening the file still requires Windows to reach the original path and grant access.

7.2 Will Rescan Now remove an offline folder automatically?

Not necessarily. If the source cannot be reached, a rescan may be unable to establish its current contents. Retaining the prior index avoids treating a temporary outage as proof that every file was deleted. Reconnect the source and rescan, or remove its folder-index entry if you no longer want the catalog.

7.3 How do I remove only the stale offline results?

Find the responsible entry under the folder-index settings and remove that specific folder. Then search for a distinctive path from the source. This is safer than deleting the complete database because unrelated indexes remain configured.

7.4 Why do the offline results return after I remove them?

Common causes include a duplicate UNC or mapped-drive index, another Everything instance, a portable profile, startup command-line options, or results supplied by a remote Everything configuration. Confirm which process and profile are active, then remove the source from the instance that owns the index.

7.5 Is Everything search not working if it shows cached results?

No. The search engine may be working exactly as designed by returning records from its database. The failure is usually live access to the source, an outdated folder snapshot, or a configuration that intentionally retains the catalog. Test the path in File Explorer to separate database search from file availability.

7.6 When is keeping offline folder results useful?

Offline results are useful when removable archives, backup disks, NAS shares, or field-storage devices are connected only occasionally. You can find which disk or share contains a filename before reconnecting it. The important limitation is that the result records a path and name, not current availability or guaranteed file contents.