Everything Portable Settings Not Saving: How to Fix It

When Everything portable settings are not saving, the usual cause is not a broken search index. More often, Everything cannot write to its portable folder, is loading a different Everything.ini file, is being closed incorrectly, or is starting under a different account, instance, or command-line configuration. USB write protection, synchronization conflicts, and the option to store settings in AppData can also make preferences appear to vanish after a restart.

This guide focuses specifically on portable settings persistence in voidtools Everything for Windows. It explains how to test one harmless preference, locate the active configuration file, verify write access, and separate a settings problem from missing results or an outdated index. Everything is a third-party filename search utility with its own indexes and services. It is not Windows Search, so rebuilding the Windows Search index will not normally fix this symptom.

1. Confirm the Symptom With a Small Safe Test

Before changing permissions or rebuilding an index, determine exactly what is being lost. Options, filters, bookmarks, folder indexes, exclusions, and index data can have different storage and update behavior. Testing one harmless setting helps establish whether the entire configuration is failing to persist or only one feature is affected.

1.1 Test one visible preference

1. Open Everything from the portable folder you normally use.
2. Change a harmless, easy-to-recognize display preference, such as showing or hiding a column.
3. Note the current location of Everything.exe and the Windows account running it.
4. Close the Options window with OK if one is open.
5. Exit Everything from its notification-area tray icon instead of ending it in Task Manager.
6. Wait a few seconds, then start the same Everything.exe again.

Success means the test preference remains changed after Everything restarts. Stop troubleshooting settings persistence at that point unless a specific filter, index, or exclusion still resets. If the preference reverts, continue with the configuration-file checks below.

1.2 Distinguish lost settings from missing results

If the option remains selected but files are missing, the configuration may be saving correctly. The problem could instead involve an exclusion, a disabled volume, folder indexing, stale network data, search syntax, or a service running under a different context.

Use a known test file with a distinctive name, such as everything-persistence-test.txt. Search for the exact filename without extra filters. If the file appears and the test option survives a restart, portable persistence is working. Avoid a database rebuild unless the index itself is demonstrably incomplete.

2. Verify the Active Everything.ini Location

Portable Everything commonly stores configuration in an Everything.ini file associated with the executable or selected instance. However, Everything can also store settings and data under the Windows user profile. A command-line option, named instance, launcher, or copied executable can cause a different configuration to load.

2.1 Find the configuration file beside the executable

Exit Everything normally, open its portable directory in File Explorer, and look for Everything.ini. Check its modified timestamp, but do not edit or delete it yet. Start Everything, change the harmless test preference, exit from the tray, and refresh File Explorer.

Success means the INI file receives a new modified timestamp and the preference survives another launch. If the timestamp does not change, Everything may lack write permission or may be storing its active settings elsewhere.

2.2 Check the AppData storage option

In Everything, review the general settings for the option commonly labeled Store settings and data in %APPDATA%\Everything. When enabled, the active configuration is tied to the current Windows user profile rather than solely to the portable directory.

This choice involves a practical tradeoff:

• Portable-folder storage: Settings can travel with the application, but the folder must be writable and reliably synchronized.
• AppData storage: Settings work well in locked-down locations, but they stay with one Windows user and do not travel automatically with the executable.

If you need true portability, disable AppData storage only after confirming the portable folder is writable. If the application is installed in a protected directory or used on a read-only device, AppData is usually the safer location. After changing the option, exit Everything normally and restart it under the same account. Stop when the selected storage mode consistently preserves the test preference.

2.3 Check shortcuts, launchers, and command-line options

Inspect the shortcut or script used to launch Everything. Compare its target with the executable you tested directly. Command-line options can select configuration files, instance names, startup behavior, servers, or other settings. A portable-app launcher may also redirect writes into its own data directory.

For a controlled test, launch Everything.exe directly from its folder without an additional script. If settings persist only during the direct launch, the launcher or command line is selecting another profile or overriding an option. Correct that startup configuration instead of repeatedly editing Everything.ini.

3. Check the Setting Directly Related to the Problem

If ordinary preferences save but one feature does not, inspect that feature before changing Windows permissions or rebuilding the index. This is especially important when Everything results are missing even though the interface settings persist.

3.1 Filters, search options, and result omissions

Clear the search box and choose the broadest normal filter, typically Everything. Disable temporary matching modes such as case matching, whole-word matching, path matching, diacritics matching, or regular expressions unless you need them. Also check whether a filter contains an unexpected macro or search expression.

Test a known filename first as plain text and then with an explicit path expression if necessary. Success means the file appears when restrictive search modes are removed. If it does, the index is probably healthy, and no rebuild is needed.

3.2 Volumes, folder indexes, and exclusions

Open the Indexes pages in Options and verify that the relevant local volume or indexed folder remains configured after restart. For a folder index, confirm that its path still exists and is accessible. Review exclusions for drive letters, folders, filenames, and wildcard patterns that could omit expected results.

Mapped drive letters can differ by user account and might not exist in elevated sessions, services, scheduled tasks, or remote desktop sessions. For network content, a UNC path such as \\server\share\folder can be more consistent than a mapped letter, provided the current account has access.

Success means the volume or folder remains listed after restart and a newly created test file becomes searchable after the relevant index updates.

3.3 Service and server settings

The Everything service helps Everything access and monitor NTFS volumes without requiring the user interface to run as administrator. It should not be confused with a public search server. A service-state problem may affect indexing, but it does not automatically explain why every interface preference resets.

If service options fail to remain enabled, check whether Everything was restarted under the same account and whether administrative approval was required for the service change. For ETP or HTTP server features, confirm that the server option itself persists before investigating firewall connectivity. Keep search servers limited to trusted networks and authenticated or otherwise protected environments. Do not expose a filename index to the public internet casually.

4. Check Windows Write Access and Storage Conditions

If Everything.ini does not update, test whether Windows can write to the portable directory. This is more useful than granting broad permissions immediately.

4.1 Perform a simple folder write test

1. Exit Everything from the tray.
2. In the portable folder, create a small text file.
3. Rename the file.
4. Edit and save it.
5. Delete the test file.

If any step fails or prompts for administrator approval, the folder is not suitable for ordinary portable settings under that account. Move the portable installation to a user-writable directory, adjust only the necessary folder permissions, or use AppData storage. Avoid granting all users full control over a system directory.

Success means the current account can create, modify, rename, and delete a file in the folder without elevation.

4.2 Inspect read-only USB drives and file systems

USB media can become read-only because of a hardware lock, device policy, file-system damage, security software, or failing storage. File properties may also show Everything.ini as read-only. Remove the read-only attribute only if you understand why it was set, then repeat the safe write test.

Also check that the drive has free space and can be safely written. If Windows reports file-system errors or the device repeatedly becomes read-only, copy the portable folder to a healthy local directory and test there. If settings save locally, the removable storage is the relevant failure point.

4.3 Account context and elevation

Running Everything once as administrator and later as a standard user can produce confusing differences, especially when AppData, mapped drives, services, or virtualized paths are involved. Test with the same Windows account and privilege level you normally use.

Do not use permanent administrator execution merely to make settings save. A better fix is a writable configuration location with the service configured appropriately when NTFS indexing requires it.

4.4 Antivirus and controlled folder access

Security software can block or isolate configuration writes, particularly from removable media or protected folders. Review Windows Security protection history and the logs of any managed endpoint product for a block involving Everything.exe or Everything.ini.

If a block is confirmed, create the narrowest appropriate allow rule approved by your organization, or move the application to an allowed writable directory. Do not permanently disable antivirus, ransomware protection, or endpoint controls as a troubleshooting shortcut.

5. Rule Out Sync Conflicts and Abnormal Shutdowns

Portable folders stored inside OneDrive, Dropbox, NAS synchronization tools, roaming profiles, or bidirectional USB sync systems may receive an older copy of Everything.ini after Everything exits. Conflict files and rapid timestamp changes are strong clues.

5.1 Pause synchronization for one controlled test

Exit Everything, pause the relevant synchronization client briefly, make a backup copy of Everything.ini, then run the preference test. Resume synchronization after the test.

If the setting persists while sync is paused but later reverts, configure the sync workflow so only one machine edits the portable profile at a time. Resolve conflict copies instead of deleting every INI file. A device-specific profile or AppData storage may be more reliable for systems used concurrently.

5.2 Close Everything normally

Closing the search window may leave Everything running in the notification area. Conversely, ending the process, forcing a shutdown, unplugging a USB drive, or terminating a remote session can interrupt pending writes.

Use the tray icon to exit, wait until the process closes, and eject removable media safely. Success means Everything.ini updates and remains intact after reopening. Once this works repeatedly, stop changing unrelated index settings.

6. Use Built-In Diagnostics Without Starting Over

Diagnostics should answer a specific question: Is Everything loading the expected profile, indexing the expected location, or applying an exclusion? Collect evidence before using Force Rebuild.

6.1 Read the status bar and Options pages

The status bar can reveal the number of indexed objects or displayed results. Compare it before and after restart. Review the relevant Options page and record the exact setting, path, or exclusion with a screenshot.

If the total index appears healthy but one query returns nothing, simplify the search syntax and inspect filters. If an indexed folder disappears from Options after restart, return to configuration location and write-permission checks.

6.2 Use Force Rebuild only for an index problem

Force Rebuild is appropriate when a configured index is clearly stale or inconsistent, not when an interface checkbox or folder definition disappears after restart. First verify that the volume or folder is enabled, accessible, and not excluded. Then use the rebuild control for the affected index and allow it to finish.

Success means the known test file appears and newly created files are detected afterward. A rebuild that temporarily restores results but does not preserve the folder configuration still points to a settings persistence problem.

6.3 Review debug information and the Index Journal

If your Everything build provides debug output or an Index Journal view, use it to look for configuration paths, inaccessible folders, failed volume monitoring, or repeated rescans. Capture only the period surrounding startup and the failed test. Logs may contain filenames and paths, so sanitize them before sharing publicly.

Sysadmins should also compare the interactive process, service state, account identity, mapped-drive availability, and startup command. This often exposes a context mismatch more quickly than reinstalling the application.

7. Run a Clean Temporary Test

When the cause remains unclear, create a separate temporary test rather than deleting the working database or configuration. This isolates corrupted settings, launcher behavior, and folder permissions without risking the current setup.

1. Exit all Everything instances.
2. Create a new writable local folder outside protected system directories and synchronized locations.
3. Place a clean portable copy of Everything in that folder.
4. Launch it directly, without startup scripts or custom command-line options.
5. Change one harmless preference.
6. Exit from the tray and reopen the same executable.

If the clean copy saves correctly, Windows can run Everything and preserve portable settings. Compare its storage location, INI behavior, startup target, instance name, and permissions with the failing copy. Transfer settings gradually instead of copying the old configuration wholesale.

If the clean copy also fails, inspect security logs, account restrictions, profile redirection, and endpoint policies. Stop after each successful test so you retain a clear cause-and-effect trail.

8. Quick Fix Checklist

• Change one harmless preference and exit Everything from the tray.
• Confirm which Everything.exe is actually launched.
• Locate the active Everything.ini and watch its modified timestamp.
• Check whether settings are stored in the portable folder or AppData.
• Verify create, edit, rename, and delete access in the portable directory.
• Test outside a read-only USB drive, protected folder, or sync location.
• Use the same Windows account and elevation level on each test.
• Inspect shortcut arguments, launchers, and named instances.
• Check filters, exclusions, indexed folders, and mapped-drive availability.
• Review security logs rather than disabling protection.
• Use Force Rebuild only after confirming an actual index problem.
• Run a clean local portable copy before deleting existing data.

9. Frequently Asked Questions

9.1 Where is Everything.ini in portable mode?

It is normally associated with the portable Everything installation, often beside Everything.exe. However, the AppData storage option, a named instance, launcher behavior, or a command-line configuration can change which file is active. The most reliable test is to change one preference, exit normally, and observe which INI file receives a new timestamp.

9.2 Why do settings save locally but not on my USB drive?

The USB device may be read-only, lack free space, have file-system problems, or be controlled by security policy. It may also be unplugged before Everything finishes closing. Confirm that you can create, modify, rename, and delete a test file on the device. If the same portable copy works in a local writable folder, investigate the USB device rather than the search index.

9.3 Should I enable Store settings and data in AppData?

Enable it when the application folder is protected, read-only, synchronized unreliably, or shared among users. Keep settings in the portable folder when you need them to travel with Everything and the folder is reliably writable. Remember that AppData is specific to the Windows user profile, so another account may appear to have default settings.

9.4 Why are Everything results missing even though settings now save?

That is likely a separate indexing or query issue. Clear filters, simplify search syntax, verify the volume or folder index, inspect exclusions, and confirm network access. Everything does not use the Windows Search index, so Windows Search troubleshooting usually does not apply.

9.5 Will Force Rebuild fix settings that reset?

No. Force Rebuild recreates relevant index information; it does not repair a read-only portable folder or make Everything load the intended INI file. Use it only when the configuration remains present but indexed results are stale or incomplete.

9.6 When should I stop troubleshooting?

Stop changing settings when one controlled preference survives several normal restarts, Everything.ini or the intended AppData configuration updates correctly, and a known test file appears in results. If only a specific network folder, filter, or startup shortcut still fails, narrow further work to that component rather than resetting the whole application.