Everything ETP Server Not Connecting: How to Fix It

When an Everything ETP server is not connecting, the failure usually belongs to one of four categories: the ETP/FTP server is not enabled or listening, the client is using the wrong address or credentials, Windows security or network routing is blocking the connection, or the connection succeeds but Everything returns incomplete results. These problems can look similar, so the fastest solution is to identify exactly where communication stops before rebuilding indexes or changing multiple settings.

This guide focuses on ETP connection failures in voidtools Everything on Windows. ETP is used to search an Everything server remotely, while FTP clients can use the server's FTP-compatible functionality where configured. It is not the same as Windows Search, SMB file sharing, Remote Desktop, or a general-purpose public FTP service. The computer running Everything must be available, the appropriate server option must be enabled, and the client must be able to reach its listening port.

1. Confirm the Symptom With a Small Safe Test

Begin with a controlled test on the local network. Do not start by forwarding ports through a router, deleting the Everything database, or disabling security software. Those actions add risk without proving whether the server works.

1.1 Identify whether the failure is connection or search related

A genuine connection failure normally produces a timeout, connection-refused message, authentication failure, or immediate disconnection. If the client connects and displays the server's files, the ETP connection itself is working. Missing or stale results are then an indexing, filtering, permission, or drive-sharing issue.

Use these outcomes to classify the problem:

• Connection refused: The destination computer responded, but nothing accepted the connection on that port.
• Connection timed out: The address, routing, firewall, or network path may be wrong.
• Authentication failed: The server was reached, but the username or password was rejected.
• Connected with missing results: Troubleshoot the server's index, exclusions, filters, and drive shares.

1.2 Test locally on the server computer

Open Everything on the computer intended to act as the server. Confirm that its normal search window returns a known local file. Next, connect through the ETP client using the local computer as the target. Depending on the client, use the loopback address 127.0.0.1 or the computer's local name, together with the port configured in Everything.

A successful local test proves that Everything is running, the server feature is enabled, and the configured port is accepting connections locally. Stop changing index settings at this point. If another LAN computer still cannot connect, concentrate on the firewall, address, network profile, and routing.

1.3 Test from another computer on the LAN

Find the server's LAN IPv4 address in Windows network settings or by running ipconfig in Command Prompt. It commonly resembles 192.168.x.x or 10.x.x.x. Enter that address and the exact configured port in the ETP or FTP client.

Test the IP address before relying on the Windows computer name. If the IP works but the name does not, the Everything server is operating correctly and name resolution is the remaining problem. You can stop modifying Everything and investigate DNS, local network discovery, or the spelling of the hostname.

2. Verify the Everything Server and Client Settings

The server feature must be explicitly enabled in Everything. Running the desktop application or the Everything service does not necessarily mean an ETP/FTP listener is active. Open Everything's Options and locate the ETP/FTP server settings. Confirm that the server is enabled and note the configured port, username, password, and any connection restrictions.

2.1 Enable the correct server option

Enable the ETP/FTP server option required by your client, apply the change, and leave Everything running while testing. If Everything indicates that a restart is needed, close and reopen it normally. Avoid launching several portable and installed copies simultaneously because one copy may already be using the port.

Success means the client no longer receives a connection-refused response and reaches either the authentication stage or the result list. Once that occurs, do not change the listening port or rebuild the database unless another specific symptom requires it.

2.2 Match the server name, IP address, and port

The client must use the address of the computer running the server, not the address of a NAS merely containing indexed files. If Everything runs on a Windows PC and indexes a NAS share, the Windows PC is the ETP destination.

• Verify that the server name has no typing errors.
• Try the server's current LAN IP address.
• Enter the port shown in Everything's ETP/FTP options.
• Check whether the client expects an ETP connection or a conventional FTP connection.
• Do not assume that a default port matches a customized server configuration.

If an IP address works while a hostname fails, retain the working IP temporarily and repair name resolution separately. If neither works but a loopback connection succeeds, the issue is outside the Everything index.

2.3 Re-enter the username and password

Authentication errors are distinct from network failures. Carefully re-enter the credentials configured on the server. Check capitalization, keyboard layout, pasted spaces, and saved credentials in the client. If you change a password for testing, use a strong temporary password and update the client immediately.

A login prompt or explicit authentication rejection proves that the client reached Everything. At that stage, firewall and indexing changes are unlikely to help. Stop changing network rules and resolve the credential mismatch.

2.4 Review command-line and portable settings

Everything can be started with command-line options, and portable installations can maintain settings separately from an installed copy. Verify which executable is running and which configuration it loaded. A shortcut, scheduled task, startup entry, or script may start another copy with different server settings.

Exit unintended duplicate instances, launch the intended copy directly, and inspect its Options pages. If the correct settings appear and the server begins accepting connections, correct the shortcut or startup task rather than repeatedly changing the application configuration.

3. Check Windows Networking, Security, and Account Context

3.1 Create a narrowly scoped firewall rule

Windows Defender Firewall or a third-party security product can allow local connections while blocking LAN clients. Permit inbound TCP traffic for the configured Everything ETP/FTP port or the appropriate Everything executable. Restrict the rule to trusted private networks or specific local addresses whenever practical.

Do not disable the firewall permanently. If policy permits a brief diagnostic test, use a controlled test on a trusted network and restore protection immediately. A safer approach is to create the narrow rule first and test again.

Success means the LAN client connects using the same address and port that previously timed out. Once it connects, stop adding firewall exceptions. Remove duplicate or overly broad test rules.

3.2 Confirm that the network path is reachable

Check that both computers are online and connected to the expected LAN or VPN. Guest Wi-Fi and client-isolation features may prevent devices from communicating even when they have internet access. Corporate VLANs can also block traffic between network segments.

Basic reachability tools can help, but a failed ping does not conclusively prove that ETP is unavailable because networks often block ICMP. In PowerShell, an administrator can test the specific TCP destination with Test-NetConnection and the server's configured port. A successful TCP test shows that the listening service is reachable, although authentication may still fail.

3.3 Understand service and user-account differences

The Everything service primarily supports indexing and privileged access. The interactive Everything process provides the user interface and may host enabled server functions. Confirm that the intended Everything process remains running after sign-out, startup, or reboot according to your deployment design.

Account context matters especially for network shares. A process running under a service account may not see the same mapped drives or stored credentials as your signed-in desktop account. Windows drive mappings are generally associated with a user session, so a mapped drive visible as Z: in File Explorer may be unavailable to another account or elevated process.

3.4 Verify NAS and network-share access

If Everything indexes a NAS or SMB share through a folder index, test whether the account running the relevant Everything instance can open the share. Prefer a UNC path such as \\server\share when practical because it identifies the network location without depending on a session-specific mapped letter.

If the ETP connection works but NAS files are missing, verify the folder index path and credentials rather than changing the ETP port. The server can only return entries present in its active index.

4. Diagnose Missing Results After the Connection Works

An Everything index not updating is not normally the cause of a refused or timed-out connection. It becomes relevant only after the client successfully logs in. Keep these troubleshooting paths separate to avoid unnecessary rebuilds.

4.1 Clear searches and filters

Use an empty search or a simple filename known to exist. Clear active filters, case matching, whole-word options, path restrictions, regular-expression mode, and advanced search syntax. A filter can make an operational server appear empty.

Check Everything's status bar for the number of indexed objects and displayed results. If the local server window finds the file but the remote client does not, compare the client search syntax and server result settings. If neither local nor remote search finds it, inspect the index source.

4.2 Review indexes, exclusions, and result omissions

Open the index-related Options pages and verify that the required NTFS volumes or folder indexes are enabled. Confirm that the target path is not excluded and that the volume is online. Folder indexes are especially relevant for NAS shares, non-NTFS volumes, removable storage, and locations that Everything does not cover through its normal NTFS indexing method.

Also check result-omission or exclusion settings that may deliberately hide system files, temporary locations, particular extensions, or selected folders. Remove only the rule that explains the missing file, then test again.

4.3 Configure drive shares for usable remote paths

Everything may return paths containing local drive letters such as D:\Media. That path is meaningful on the server but may not be directly accessible from a remote computer. In the ETP/FTP server settings, configure drive shares or mappings so server drive letters correspond to appropriate network-accessible locations.

This setting addresses access to returned files, not basic server connectivity. A connection that displays results has already succeeded. Correct drive mapping is confirmed when selecting or opening a result leads to the intended shared location instead of a nonexistent local drive on the client.

4.4 Rebuild only when evidence points to index corruption

Use Force Rebuild only after confirming that a required local volume or folder is configured correctly but its files remain absent or seriously stale. Rebuilding can take time and does not repair a blocked TCP port, incorrect password, or wrong IP address.

After a rebuild, wait for indexing to finish and verify the known filename in the server's local window first. If it appears locally and remotely, stop troubleshooting. If it appears locally but not remotely, return to client filters and server result settings.

4.5 Use diagnostics carefully

If the issue persists, enable Everything's diagnostic or debug output using the documented method for your installation. Reproduce one connection attempt, record the time and exact error, and then review the output for listener, authentication, socket, index, or path messages. Avoid posting logs publicly without removing usernames, internal hostnames, addresses, and file paths.

The Index Journal can help explain indexing activity and changes, but it is not a substitute for a network connection test. Use it when files are stale or missing after successful authentication, not when the client cannot reach the server.

5. Run a Clean Temporary Test

When configuration history is uncertain, a clean temporary test can separate application settings from Windows networking. Do not overwrite the working profile or delete the existing database. Instead, use a separate portable Everything folder in a temporary location, ensuring the test instance uses its own settings.

1. Exit other Everything user-interface instances so they do not compete for the same port.
2. Start the temporary copy with a clean configuration.
3. Enable only the required local index and ETP/FTP server option.
4. Choose an unused test port and a temporary strong credential.
5. Test through 127.0.0.1 on the server.
6. Create a restricted firewall rule and test from one trusted LAN computer.

If the clean instance works, the network path is sound and the original profile likely contains a conflicting option, port, startup argument, or filter. Compare settings methodically instead of replacing everything at once. If the clean instance also fails locally, inspect port conflicts, security software, and whether the server option actually started.

Once the test identifies the cause, close the temporary instance, remove its test firewall rule, and apply only the confirmed fix to the regular installation.

6. Quick Fix Checklist

• Confirm that Everything finds a known file locally on the server.
• Enable the required ETP/FTP server option in Everything.
• Verify the exact server port shown in Options.
• Test 127.0.0.1 before testing another computer.
• Use the server PC's LAN IP before troubleshooting its hostname.
• Re-enter the configured username and password carefully.
• Allow only the required inbound TCP port on trusted networks.
• Test from the LAN before considering VPN or remote access.
• Check for duplicate installed and portable Everything instances.
• Verify which Windows account launches Everything at startup.
• Use UNC paths for NAS folder indexes when mapped drives are unreliable.
• Clear client searches, filters, exclusions, and advanced syntax.
• Configure drive shares when returned drive-letter paths are unusable remotely.
• Use Force Rebuild only for confirmed indexing problems.
• Stop changing settings as soon as the failed stage begins working.

7. Frequently Asked Questions

7.1 Why does Everything connect locally but not from another PC?

This usually means the server is running but Windows Firewall, another security product, an incorrect LAN address, or network isolation is blocking remote traffic. Confirm the server's current IP and create a narrowly scoped inbound rule for its configured TCP port.

7.2 Why can I connect but see no Everything results?

Clear the client search and filters, then inspect the server's status bar and local results. Verify the relevant NTFS volume or folder index, exclusions, and result-omission settings. If files are absent locally too, correct the index source before changing ETP settings.

7.3 Does the Everything service automatically enable ETP?

No. Treat service operation, indexing, the user-interface process, and ETP/FTP server configuration as separate checks. Open the intended Everything instance and verify that its ETP/FTP server option is enabled.

7.4 Why are mapped NAS drives missing from Everything?

Mapped drives can be tied to a particular Windows user session. An elevated process, service account, scheduled task, or different user may not see the same drive letter. Configure an appropriate folder index and use a UNC path when possible, while ensuring the running account has permission to access it.

7.5 Should I expose the Everything ETP server to the internet?

Direct public exposure is generally a poor first choice because filename indexes can reveal sensitive information. Prove the configuration on the LAN first. For remote access, prefer a properly secured VPN or another controlled private-network solution, apply strong authentication, and restrict firewall access.

7.6 Is Everything the same as Windows Search?

No. Everything is a separate filename-search application with its own indexes, settings, service components, and ETP/FTP features. Repairing or rebuilding the Windows Search index will not normally fix an Everything ETP connection failure.