Everything Service Not Indexing as Standard User: How to Fix It

When voidtools Everything finds files while running as an administrator but shows missing or stale results as a standard Windows user, the problem is usually not the search box itself. The most likely causes are a stopped or inaccessible Everything Service, a conflict between the service and the Run as administrator option, an NTFS volume that is not included in the index, or a difference between the administrator and standard-user configurations. Network shares, portable installations, exclusions, filters, and startup behavior can produce similar symptoms.

The key distinction is the service and client privilege split. The Everything desktop client provides the interface, searches the database, and uses your user-specific settings. The Everything Service runs with the privileges required to access NTFS indexing information, allowing a normally launched client to maintain the NTFS index without elevating the entire interface. If that connection fails, the client may open normally while its index remains incomplete. The steps below isolate that failure without deleting the database or making broad security changes.

1. Confirm the Symptom With a Small Safe Test

Before changing settings, verify that the failure is specifically tied to the standard-user context. This prevents an unrelated filter, search expression, or network-share problem from being mistaken for a service failure.

1.1 Create a controlled local test

Choose an indexed local NTFS volume and create a harmless file with a distinctive name, such as C:\Users\Public\everything-standard-user-test-4821.txt. Use the Public folder so that different local accounts can see the file through ordinary Windows permissions.

1. Open Everything normally, without using Run as administrator.
2. Clear the search box completely.
3. Select the Everything filter from the Search menu.
4. Search for everything-standard-user-test-4821.txt.
5. Rename the file in File Explorer and check whether the result updates within a short time.

Success means the file appears and its renamed filename is reflected in the results. If that happens, local NTFS indexing through the service is working, so stop changing service settings. Investigate only the location or search that remains missing.

If the test appears only after launching Everything as an administrator, continue with the service and privilege checks. If it appears under neither launch mode, inspect the volume selection, exclusions, filters, and file system type instead.

1.2 Remove search-side causes

An active filter or advanced search option can make a healthy index look broken. Clear the search field, choose the Everything filter, and temporarily turn off options such as Match Case, Match Whole Word, Match Path, Regex, and diacritics matching if enabled. Also confirm that a leading exclamation mark or other search operator is not excluding the target.

Search for the exact filename first, then for a unique fragment such as 4821. If the fragment works but the original query does not, the issue is search syntax rather than indexing.

2. Check the Everything Service and Client Privilege Split

For this symptom, the highest-value check is whether the Everything Service is installed, running, and being used by a non-elevated client. Running the complete application as an administrator can mask a broken service connection, but it is not the preferred long-term arrangement for routine searching.

2.1 Verify the service inside Everything

Open Everything normally and go to Tools > Options > General. Confirm that Everything Service is enabled. If the interface offers to install the service, approve the Windows elevation prompt using an administrator account. Installing or changing a Windows service requires administrative authorization even though day-to-day use does not.

After enabling the service, close every Everything window and exit any remaining Everything process from its notification-area icon. Start Everything again normally. Restarting the client matters because an already running process may retain its previous connection state.

Success means the standard-user client starts without an elevation prompt, the controlled test file appears, and filename changes update. Once those conditions are met, stop. Do not rebuild the index merely because administrator mode also works.

2.2 Confirm the Windows service state

Press Win + R, enter services.msc, and locate Everything. Its status should be Running, and its startup configuration should allow it to start with Windows. If it is stopped, start it and then restart the Everything client.

If the service starts and immediately stops, check Windows Event Viewer and Everything diagnostics before repeatedly reinstalling it. A damaged executable path, a security product block, or an installation copied to a different location can prevent service startup.

You can also use an elevated Command Prompt to inspect the Windows service:

• sc query Everything checks whether Windows knows about the service and reports its state.
• sc start Everything asks Windows to start an installed service.
• sc stop Everything stops it for controlled troubleshooting.

Everything also supports service-management command-line options, including -install-service, -uninstall-service, -start-service, and -stop-service. Run installation or removal commands from an elevated terminal and use the executable belonging to the installation you intend to keep. Avoid mixing commands from multiple portable and installed copies.

2.3 Resolve the Run as administrator conflict

In Tools > Options > General, turn off Run as administrator when using the Everything Service. The intended arrangement is an elevated service plus a normal desktop client. Also check the executable and any shortcut:

1. Right-click the Everything shortcut or executable and select Properties.
2. Open the Compatibility tab.
3. Clear Run this program as an administrator.
4. Check the advanced shortcut properties for the same setting.
5. Exit Everything fully and reopen it from that shortcut.

Success means Everything opens without a User Account Control prompt and still indexes the local NTFS test file. That confirms the service is supplying the privileged indexing access while the client remains in the standard-user context.

2.4 Understand the service security boundary

The Everything Service supports filename indexing. It does not grant the standard-user interface permission to open protected files, read their contents, or bypass normal Windows access controls. A filename may therefore appear in results even when the current user cannot open the file.

This distinction is useful but privacy-sensitive: filenames can themselves contain confidential information. Limit service use to trusted local systems, apply appropriate NTFS permissions, and do not assume that filename visibility is harmless in every environment.

3. Check the Index, Exclusions, and Per-User Configuration

If the service is healthy but results remain missing, inspect the settings loaded by the affected user. Everything configurations can differ between Windows accounts, installations, named instances, and portable copies.

3.1 Confirm that the NTFS volume is included

Open Tools > Options > Indexes > NTFS. Locate the volume containing the test file and confirm that it is included in the database. Verify that the drive letter and volume identity match the currently mounted disk, especially after disk cloning, drive-letter changes, or reconnecting external storage.

Everything uses NTFS metadata, including the Master File Table and change journal, to build and update its fast filename index. A local FAT32, exFAT, ReFS, optical, or other non-NTFS volume cannot be treated as an NTFS index merely because it has a Windows drive letter. Such locations may need to be configured as folder indexes if supported by the installed application and use case.

Success means the correct volume is listed and enabled, followed by the test filename appearing after the index catches up. If only one volume was missing, do not alter the settings for healthy volumes.

3.2 Inspect folder indexes and exclusions

Folder indexing is relevant for locations that are not covered by local NTFS indexing, including many network shares and non-NTFS drives. In Tools > Options > Indexes > Folders, confirm that the intended folder exists, is reachable in the affected account, and has an appropriate update schedule.

Then check the Exclude page. Look for excluded folders, volumes, hidden or system-item rules, and wildcard patterns that could match the missing path. Temporarily disabling one suspicious exclusion is safer than removing every rule.

Success means the affected path appears after the relevant index updates. Re-enable any unrelated exclusion immediately and keep the narrowest configuration that works.

3.3 Compare administrator and standard-user settings

If administrator mode works, compare its Options pages with those loaded by the standard account. Pay particular attention to:

• The enabled NTFS volumes
• Folder index entries and update schedules
• Excluded paths and wildcard rules
• Active filters and bookmarks
• Database and configuration locations
• Named-instance or command-line parameters
• Store settings and data in the same location as the executable options

Do not assume the two launch modes are loading the same configuration. An elevated process may run under a different account or resolve user profile paths differently.

3.4 Check portable and command-line launches

A portable copy can have separate settings from an installed copy. It may also be unable to write its configuration or database beside the executable when stored under a protected directory. Move a temporary test copy to a user-writable folder rather than weakening permissions on Program Files.

Inspect shortcuts, scheduled tasks, scripts, and startup entries for command-line options that select a different instance, configuration file, database, service behavior, or server mode. Launch the intended executable directly with no extra options for comparison.

If the direct launch works, the index is not fundamentally broken. Correct the shortcut or startup command and stop troubleshooting the service.

4. Check Windows Account Context and Storage Type

Everything is not Windows Search. Windows Search builds a separate index that can include properties and file contents, while Everything is primarily a high-speed filename search tool. Rebuilding the Windows Search index will not repair an Everything Service connection or an omitted Everything volume.

4.1 Test from a second standard account

Create or use a second trusted standard Windows account and repeat the Public-folder test. Do not make the second account an administrator for this test.

• If both standard accounts fail but administrator mode works, focus on the Everything Service, its connection, installation path, and security controls.
• If only one standard account fails, focus on that account's Everything settings, filters, startup shortcut, profile permissions, or configuration files.
• If both standard accounts work, the original problem may already be resolved or tied to a specific saved search.

This test is especially valuable because it separates a machine-wide service failure from a single-profile configuration problem without deleting anything.

4.2 Treat mapped drives and network shares separately

The Everything Service's access to local NTFS metadata does not automatically make a mapped network drive indexable as a local NTFS volume. Drive mappings are usually user-session specific, so a service account may not see the same mapped letter that appears in File Explorer.

For a NAS or share, test the UNC path, such as \\server\share, from the affected standard account. Confirm that the account can list the directory in File Explorer. Configure a folder index or an appropriate Everything server arrangement rather than expecting the local service to read the remote disk's NTFS journal.

If you use Everything's server features, bind and firewall them conservatively. Do not expose a filename-search service directly to the public internet. Use trusted networks, restrictive firewall rules, and a secure remote-access layer such as a properly administered VPN.

4.3 Review firewall and antivirus events narrowly

Security software can block service installation, interprocess communication, database writes, or execution from portable locations. Check protection history, quarantine, application-control logs, and Windows Event Viewer for an event at the time of failure.

If a block is confirmed, create the narrowest appropriate allow rule for the genuine Everything executable and service. Verify the executable's source and signature first. Do not disable antivirus or firewall protection permanently. A temporary diagnostic change should be brief, controlled, and reversed immediately.

4.4 Verify startup behavior

Multiple startup entries can launch the wrong executable or launch one copy elevated and another normally. Check Task Manager's Startup apps, the Startup folders, Task Scheduler, and shortcut targets. Keep one intentional client startup entry and one installed Everything Service.

Success means the same expected client opens after sign-in, without elevation, and the service is already running. If the problem occurs only immediately after boot, wait for the service to start, restart the client once, and then correct the startup ordering or duplicate entry.

5. Use Diagnostics Without Destroying Useful State

When basic checks do not identify the problem, gather evidence before rebuilding. The status bar, Options pages, index diagnostics, and debug output can reveal whether Everything is searching a small database, rebuilding, paused, or connected to an unexpected instance.

5.1 Read the status bar and index information

Clear the search box and inspect the result count shown by Everything. A dramatically smaller total under the standard account suggests a different database or configuration. Compare enabled volumes and indexed-object counts rather than relying only on one missing filename.

Use the relevant Indexes pages to inspect volume state and journal information. If the application reports a journal or volume error, confirm that the volume is online, still NTFS, and identified correctly before taking stronger action.

5.2 Use Force Rebuild only after configuration checks

A forced rebuild can help when the selected volumes and service are correct but the database is demonstrably stale or inconsistent. It should not be the first step because a rebuild cannot fix a stopped service, excluded path, wrong portable profile, unavailable share, or unsupported file system.

Before rebuilding, record the current index and exclusion settings. Trigger Force Rebuild from the appropriate index options, keep Everything open, and allow the process to finish. Success means the controlled file appears and subsequent renames update normally. If the rebuilt database immediately becomes stale again, investigate the service connection or journal access instead of repeatedly rebuilding.

5.3 Capture debug information

Everything provides debugging facilities that can expose startup parameters, service communication, indexing activity, and errors. Start a diagnostic session using the documented debug option or debug console appropriate to your installation, reproduce the missing-file test, and save only the relevant output.

Review the log for service connection failures, inaccessible configuration paths, unavailable volumes, journal errors, or evidence that a different instance started. Remove personal filenames and paths before posting logs publicly.

6. Run a Clean Temporary Test Before Broad Changes

A clean test determines whether the failure is caused by saved settings without destroying the working profile. Do not delete the existing database or configuration as an opening move.

1. Exit every running Everything client.
2. Record the executable path and back up the current settings if practical.
3. Use a separate temporary, user-writable folder and a clean Everything configuration or named test instance.
4. Launch the client normally with no custom shortcut arguments.
5. Enable or connect to the installed Everything Service as appropriate.
6. Include only the local NTFS volume containing the Public-folder test file.
7. Search for the distinctive test filename.

If the clean standard-user test works, the Windows service and core indexing path are healthy. The fault is in the original profile, such as an exclusion, wrong volume selection, filter, portable setting, or command-line option. Compare settings one category at a time.

If the clean test fails for two standard accounts but succeeds when elevated, repair the service installation or investigate a machine-wide security restriction. If it fails even when elevated, return to volume type, NTFS selection, and installation integrity.

7. Quick Fix Checklist

1. Create a uniquely named test file on a local NTFS volume.
2. Clear the query and select the Everything filter.
3. Confirm Everything Service is installed and running.
4. Disable Run as administrator in Everything and shortcut compatibility settings.
5. Exit the client fully and restart it normally.
6. Confirm the correct NTFS volume is enabled.
7. Check exclusions and folder-index settings for the missing path.
8. Compare administrator and standard-user configurations.
9. Check portable copies, named instances, startup entries, and command-line options.
10. Test from a second standard Windows account.
11. Treat mapped drives and NAS shares as remote folders, not local NTFS journals.
12. Review security logs instead of permanently disabling protection.
13. Use a clean temporary profile before forcing a rebuild.
14. Force a rebuild only when the service and configuration are already correct.

Stop as soon as the normally launched client finds the test file and tracks a rename. Continuing to change settings after success can introduce a second problem and obscure which fix worked.

8. Frequently Asked Questions

8.1 Why does Everything work as administrator but not as a standard user?

The elevated process may be able to access NTFS indexing information directly, while the standard client depends on the Everything Service. It may also load different per-user settings. Confirm the service is running, disable Run as administrator, restart the client normally, and compare the two configurations.

8.2 Should Everything always run as administrator?

No. When the Everything Service is installed, the normal arrangement is to run the desktop client without elevation. The service performs the privileged NTFS indexing work. Keeping the interactive client non-elevated reduces unnecessary privilege and avoids elevation prompts.

8.3 Does the Everything Service bypass file permissions?

The service enables filename indexing, but it does not give the current user permission to open or read protected file contents. Normal Windows access controls still apply when the user tries to access a result. Remember that filenames may still reveal sensitive information.

8.4 Why are files from my NAS or mapped drive missing?

A mapped drive is a user-session mapping to remote storage, not a local NTFS volume available through the local change journal. Confirm the share works under the affected account, then use an appropriate folder index or securely configured Everything server setup. Do not expose server features directly to the public internet.

8.5 Will rebuilding the Windows Search index fix Everything?

No. Everything and Windows Search maintain separate indexes and use different mechanisms. Rebuilding Windows Search does not repair the Everything Service, Everything database, NTFS selection, exclusions, or folder indexes.

8.6 When should I use Force Rebuild?

Use Force Rebuild after confirming that the service is running, the correct volume is enabled, the path is not excluded, and the client is using the intended configuration. It is appropriate when the database is clearly stale or inconsistent, not when the underlying location is unavailable or incorrectly configured.