Everything Database Location Permission Denied: How to Fix It

The “Everything database location permission denied” error usually means voidtools Everything can search supported volumes, but it cannot create, update, replace, or reopen its database file at the configured location. The most common causes are a database path under Program Files, restrictive permissions on a portable folder, antivirus controlled folder access, an unavailable network share, or a mismatch between the Windows account that configured Everything and the account currently running it.

This problem is different from Windows Search. Everything maintains its own filename index and database, while Windows Search uses Windows indexing services and supports content indexing. Repairing Windows Search normally will not resolve an Everything database path permission error. The safest approach is to test whether the configured database folder is writable, correct that specific problem, and stop as soon as Everything can save and reopen its database normally.

1. Confirm the Symptom With a Small Safe Test

Before changing indexing options or rebuilding anything, confirm that the database location is the real failure point. An empty result list can also be caused by filters, exclusions, search syntax, an offline folder index, or a stopped Everything service. Those problems require different fixes.

1.1 Record the exact error and database path

Open Everything and note the complete permission message, including any file or folder path. Then open Everything’s Options pages and locate the configured database location under the indexing or database settings available in your installation. The precise labels can differ between Everything editions and builds, so focus on the path shown rather than assuming a default.

Expand environment variables such as %LOCALAPPDATA% in File Explorer if necessary. A normal per-user data location generally resolves to a folder inside the current user’s profile. A portable installation may instead place its settings and database beside the executable.

Do not delete the existing database yet. First record:

• The full database path
• Whether the path is local, removable, mapped, or UNC-based
• The Windows account currently running Everything
• Whether Everything was started normally or as administrator
• Whether the error appears at startup, shutdown, or during an index update

1.2 Perform a write test in the destination folder

Using File Explorer under the same Windows account that runs Everything, browse to the database folder. Create a small text file, rename it, and delete it. This is a safer diagnostic than immediately rebuilding the database.

If Windows refuses any of those operations, Everything is encountering a folder permission or security-control problem. Correct the folder or choose a writable database location. If all three operations work, the folder is broadly writable, but Everything may still be blocked from replacing its specific database file, using a temporary file, or writing under a different account context.

Success means the test file can be created, renamed, and removed without an elevation prompt. Once Everything also starts without the database permission error and retains its index after a restart, stop changing settings.

2. Check the Everything Settings Directly Related to the Error

A permission message can be accompanied by symptoms such as Everything search not working, an index not updating, or results missing. Check the database option first, then verify only the settings that could explain the remaining symptom.

2.1 Verify the database location

Avoid storing a writable Everything database directly under C:\Program Files or C:\Program Files (x86). Windows protects these locations, and standard desktop applications normally should not modify files there during routine use. An installed executable can remain in Program Files while its changing data is stored in the user profile.

For a conventional single-user setup, choose a folder owned by the user, such as a dedicated directory below %LOCALAPPDATA%. For example, create an Everything data folder inside Local AppData and select it as the database location. Use the application’s setting to change the path rather than moving files while Everything is running.

Success means Everything can close, reopen, update the index, and save the database without requesting administrator rights.

2.2 Check portable mode and portable folder permissions

A portable copy often keeps writable data near Everything.exe. That works when the portable folder is owned by the user, but fails if the folder was copied into Program Files, extracted by an administrator, inherited restrictive access control lists, or placed on read-only media.

Right-click the portable folder, open Properties, and check both the General and Security tabs. Clear a read-only condition on the destination where applicable, and confirm that the intended user has Modify permission. Do not grant Full Control to broad groups such as Everyone unless there is a documented organizational reason.

A practical alternative is to leave the portable executable where it is and configure its changing database data to use a writable per-user folder. This preserves portability less completely, but it avoids weakening a protected directory.

2.3 Review command-line and startup overrides

A shortcut, scheduled task, startup entry, script, or command-line option may override the location selected in the graphical interface. Inspect the shortcut’s Target field and any scripts used to launch Everything. Also check whether multiple copies are starting with different configurations.

If Everything works when launched directly but fails from a shortcut or scheduled task, the launcher is likely changing the account, working directory, configuration file, or database path. Correct that launcher instead of repeatedly changing the interactive Options page.

2.4 Separate database errors from filters and index settings

Once the permission error is gone, clear the search box and select the broadest normal filter, usually Everything. Review exclusions and result-omission options if known files are missing. Confirm that the relevant NTFS volume, ReFS volume, or folder index is enabled in the appropriate indexing page.

A filter or exclusion cannot normally cause Windows to deny access to the database file. It can, however, make a repaired database look empty. Use a simple exact filename or extension test after fixing the path rather than a complex search expression.

3. Check Windows Permissions and Account Context

3.1 Compare standard-user and administrator contexts

Running Everything once as administrator can create its data folder or database under an elevated context. Later, the standard user may be able to read that file but not modify or replace it. The reverse can also cause confusing behavior when elevated and non-elevated instances use different profile paths or settings.

Check the database file’s owner and effective permissions in Properties, Security, Advanced. The normal user that launches Everything should have permission to read, create, modify, and delete files in the database directory. Apply changes narrowly to the Everything data folder rather than to an entire profile, drive, or Program Files tree.

Do not treat permanent elevation as the preferred voidtools Everything fix. Running as administrator may hide the permission problem while increasing the privileges available to the application. Correct ownership or move the database to an appropriate user-writable location instead.

3.2 Check antivirus and controlled folder access

Microsoft Defender Controlled folder access and comparable ransomware protection can block an application from changing files in protected locations even when NTFS permissions appear correct. Review Windows Security protection history or the security product’s event log for a block involving Everything.exe or the database path.

If a block is confirmed, prefer moving the database to a suitable application-data folder. If policy requires the current location, allow the trusted Everything executable through the security feature according to your organization’s rules. Do not disable antivirus or ransomware protection permanently.

Success means no new block event appears and the database timestamp changes after a legitimate index update or clean application exit.

3.3 Treat network shares and mapped drives carefully

A mapped drive can be visible to one logon session but absent from an elevated process, service, scheduled task, or different user account. A UNC share can also be unavailable during startup, before networking and credentials are ready. Both situations can produce access errors even when the share works later in File Explorer.

If the database must be stored on a NAS, test the UNC path under the exact account and launch method used by Everything. Confirm share permissions and file-system permissions, because access may be restricted at either layer. Also confirm that the share supports ordinary file creation, rename, and replacement operations.

For reliability, storing the active database on a local per-user path is usually simpler. Everything can index configured folders or connect through supported server features without placing its actively changing database on an intermittently available share. Do not expose an Everything server directly to the public internet. Use trusted networks, authentication controls, and a VPN or similarly protected access design where remote access is required.

3.4 Consider startup timing and removable storage

If the error occurs only immediately after signing in, the database destination may not be mounted yet. This is common with NAS mappings, encrypted containers, removable drives, and synchronization clients. Delay Everything’s startup until the destination is available, or move the database to a local folder that exists throughout the session.

A removable device can also be write-protected, formatted with a file system that handles permissions or file replacement differently, or disconnected without notice. Confirm free space and run the same create, rename, and delete test on the device.

4. Validate the Index After Permission Access Is Restored

Fixing database access should come before forcing a rebuild. A rebuild still needs a writable destination, so running it while permission is denied usually adds work without addressing the cause.

4.1 Use the status bar and simple search tests

Watch the Everything status bar for indexing activity, object counts, errors, or a paused state. Then create a uniquely named test file in a location that should be indexed. Search for the full filename without regex, advanced operators, or restrictive filters.

If the test file appears and remains searchable after restarting Everything, the database is updating and persisting. Remove the test file and confirm that the result disappears after the relevant index mechanism processes the change.

4.2 Check service state without confusing its role

The Everything service can provide low-privilege access to NTFS indexing information, depending on the configuration. It does not automatically grant the desktop process permission to write any arbitrary database folder. Check the service if NTFS volumes are not being indexed, but repair the database directory permissions under the account that writes the database.

If the service is expected, verify its state through Everything’s Options or the Windows Services console. If it repeatedly stops, review Windows logs and the application’s diagnostic output. Do not repeatedly reinstall the service merely to solve an obvious Program Files write restriction.

4.3 Use Force Rebuild only after the path works

After confirming that the destination is writable, use Force Rebuild from the relevant indexing Options page if Everything reports stale or structurally inconsistent results. A rebuild is appropriate when the database opens successfully but the index does not reflect enabled volumes or folder indexes.

Allow the rebuild to complete before judging the results. Success means the status settles, expected volumes are represented, a new test file appears, and the repaired database survives an application restart.

4.4 Use diagnostics when the error remains unexplained

If a normal write test succeeds but Everything still reports permission denied, enable the official debug or diagnostic mode available for your installed edition and reproduce the error once. Look for the exact path and Windows operation that failed. The failure may involve a temporary database file, configuration file, journal, or rename operation rather than the main database file itself.

If your edition exposes an Index Journal, use it to determine whether changes are being received after the database opens. Journal evidence can help distinguish a persistence failure from a volume-update failure. Preserve useful log lines, but remove usernames, share names, and sensitive paths before sharing them publicly.

5. Run a Clean Temporary Test Before Changing More Settings

When the cause remains unclear, run a temporary clean test without deleting the working configuration. Exit all Everything instances. Copy or back up the existing configuration and database files, then start a separate portable test from a user-owned folder such as a temporary directory under the current profile. Configure its database to another writable local folder.

Do not point the test instance at the production database, and do not run both instances against the same writable files. Start with a small, understood index scope. If the clean instance saves and reopens normally, Windows and the executable can work together, and the problem is likely tied to the original path, ACLs, startup parameters, or profile configuration.

If the clean instance fails in multiple ordinary user-owned folders, inspect security software events, disk health, free space, profile redirection, and organizational policies. At that point, diagnostics are more useful than changing unrelated filters or search syntax.

5.1 Move the database location safely

1. Record the current database path and take a backup if the file is accessible.
2. Create a new folder under a writable local application-data location.
3. Verify create, rename, and delete operations in that folder.
4. Change the database location through Everything’s settings.
5. Exit Everything cleanly and confirm that no process remains.
6. Restart Everything and allow it to load or rebuild as required.
7. Create a uniquely named test file and verify that it appears in results.
8. Restart Everything again and confirm that the result and index persist.

Keep the old database temporarily until the new setup has passed both restart tests. Remove it later only when you are confident that the new location is active and backups are no longer needed.

6. Quick Fix Checklist

• Record the exact denied path before changing anything.
• Test file creation, rename, and deletion in the database folder.
• Move writable data out of Program Files.
• Use a per-user AppData location for a conventional installation.
• Check ACL inheritance and ownership on portable folders.
• Run Everything consistently as the intended standard user.
• Inspect Controlled folder access or antivirus block history.
• Check shortcut, script, scheduled-task, and command-line overrides.
• Prefer a local database over an intermittently available mapped drive.
• Confirm service state only when volume indexing is also affected.
• Clear filters and exclusions when testing repaired results.
• Force a rebuild only after database writes succeed.
• Stop troubleshooting once the database updates and survives a restart.

7. Frequently Asked Questions

7.1 Why does Everything work as administrator but fail normally?

The database folder or file is probably writable only by an administrator, or the elevated instance is using a different profile or configuration. Compare the paths, correct the folder ownership and permissions, or move the database to a user-writable AppData location. Permanent elevation is not the preferred repair.

7.2 Can the Everything database stay in Program Files?

It should not be the active writable location in a standard setup. Program Files is designed for installed application files and is protected against routine standard-user modification. Keep the executable there if desired, but put the changing database in an appropriate application-data folder.

7.3 Does reinstalling Everything fix database permission denied?

Not necessarily. Reinstallation may leave the same database path, ACLs, security rule, or startup override in place. Test and correct the destination first. Reinstall only when program files are missing or damaged, not as the first response to a clear path-permission error.

7.4 Why is the Everything index not updating after the error disappears?

The database may now be writable while an index source remains disabled, excluded, offline, or dependent on a stopped service. Clear filters, review enabled volumes and folder indexes, check exclusions, and test a unique filename. Use Force Rebuild only after verifying write access.

7.5 Can I place the database on a NAS?

It may work when the share is continuously available and the launching account has reliable create, modify, rename, and delete permissions. However, startup timing, credentials, mapped-drive visibility, latency, and disconnections make a local database more dependable. Index or query network resources through supported, securely configured methods when possible.

7.6 What proves that the Everything database location permission denied fix worked?

Everything starts without the permission message, its database file can be updated, a uniquely named test file appears in search, and the result remains correct after Everything or Windows is restarted. Once those checks pass, stop changing options. Additional rebuilding, permission edits, or security exclusions are unnecessary and could create new problems.