You press Ctrl+F on a mapped drive, type a filename you know exists, and watch Explorer's green progress bar crawl for minutes — while the same search on your local C: drive is instant. This is an architecture problem, not a tuning problem, and no registry tweak fixes it. This article explains exactly why file-server search is slow, then compares every realistic fix: Windows Search on the server, Everything's folder indexing, on-demand scanners, and a client-side index with realtime updates. By the end you'll know which one fits your setup.
Fast file search on Windows always comes down to one question: can the tool read the file system's own bookkeeping, or does it have to ask about every folder individually?
Every NTFS volume keeps a Master File Table (MFT) — a single compact structure listing every file and folder on the volume. A search tool can read it in one sequential pass and hold millions of filenames in memory within seconds. After that it never needs to rescan, because NTFS also keeps a USN change journal: an append-only log of every create, rename, move, and delete. Subscribe to the journal and the index stays permanently current. This is why Everything feels like magic on a local drive — it reads the volume's own ledger instead of walking folders.
Now put the same files on a file server and access them as \\server\share or a mapped drive letter. The SMB protocol does not expose the server's MFT or USN journal to clients — deliberately, since a share may not even be NTFS underneath (it could be a Linux box running Samba, or a NAS). The only listing primitive SMB offers a client is "give me the entries of this one directory." So any client-side search must enumerate: request the root's contents, then each subfolder's, then each of theirs, one network round-trip after another. A share with 200,000 folders means hundreds of thousands of round-trips, and per-request latency — not bandwidth — dominates. That is the crawling green bar.
This one asymmetry explains everything below: tools that are instant locally (Explorer's indexer, Everything, UltraSearch) all quietly fall back to slow enumeration the moment the path starts with two backslashes.
The Windows client-side indexer never indexes network locations — that's by design, not a misconfiguration. Searching a UNC path or mapped drive in Explorer triggers a live crawl of every folder, every time. Microsoft's supported fix is server-side: install the Windows Search service on the file server itself, after which Explorer clients get indexed results for that share.
It works and it's free — but only if the server is actually Windows Server, you have admin rights on it, and the service is installed. It is simply not an option when the "file server" is a Synology, QNAP, TrueNAS, or Samba share — there is nowhere to install the service. We cover the setup and its limits in how to index a network share on Windows.
Windows also offers Offline Files ("Always available offline"), which makes a share searchable by syncing it to local disk. That costs local storage equal to the synced data and brings sync conflicts — workable for a few gigabytes, unrealistic for multi-terabyte shares.
Everything is free and, on local NTFS drives, as good as this category gets: it reads the MFT, subscribes to the USN journal, and results are instant. If you only search local drives, install Everything and stop reading this article.
Network shares are a different story, for exactly the mechanical reason above. Everything indexes a share through "folder indexing" — a full directory walk over SMB, the same slow enumeration Explorer does, just performed in advance. And in this mode there is no realtime change detection over SMB: the index updates only when a scheduled or manual rescan runs, so between rescans it shows deleted files and misses new ones. On a large share, each rescan itself takes a long time.
Voidtools' documented answer is to run Everything on the server and expose its index through the ETP/HTTP server, which clients connect to. That restores instant, current results — but it requires the server to be Windows and requires the rights to install software on it, which puts you back in Option 1 territory. If you're weighing Everything against other tools more broadly, see our Everything alternatives comparison.
These tools keep no persistent index; they scan when you ask. Agent Ransack (FileLocator Lite) stands out for a different reason than speed: it searches file contents, not just names. A content scan of a big share is slow because it has to read the files, but when the question is "which document contains this phrase," it's the right tool and nothing else on this page replaces it. UltraSearch reads the MFT on local NTFS drives (fast locally) and falls back to live enumeration on shares.
For an occasional search on a modest share, on-demand scanning is fine. As a daily driver on a large file server, it means paying the full multi-minute enumeration cost on every single search — the exact pain you came here to fix.
Malvicsearch (our product — judge accordingly) exists for the specific gap the options above leave open: you search a big share every day, you don't have admin access to the server, and rescanning constantly isn't acceptable. It's a Windows 10/11 (64-bit) desktop app that searches file and folder names and paths — not file contents.
How it deals with the SMB problem:
Verified numbers from our own workstation (screenshots on the site): with 9,363,175 files indexed, a query returned results in 12 ms; a query matching 5.4 million files across local and network drives returned in 56 ms; a saved index of 1.88 million entries loads in about one second at startup and is searchable immediately. The index never leaves your machine — nothing is uploaded, and search works offline.
When NOT to use Malvicsearch: if you only search local drives, use Everything — it's free and excellent. If you need to search inside files, use Agent Ransack; Malvicsearch matches names and paths only. And it's Windows-only — there is no macOS or Linux version.
Pricing is $29 one-time for a lifetime license (1 PC), with a full-featured 5-day trial — no credit card — and a 14-day money-back guarantee. Download the trial or see pricing.
| Approach | First search on a share | Index freshness on a share | Server access needed? | Content search | Price |
|---|---|---|---|---|---|
| Explorer (no server index) | Minutes — live crawl | n/a — crawls every time | No | Yes, slowly | Free |
| Windows Search service on server | Fast | Current (server-side index) | Yes — Windows Server + admin | Yes | Free |
| Everything (folder indexing) | Fast after initial walk | Stale between scheduled/manual rescans | No | No | Free |
| Everything ETP/HTTP server | Fast | Realtime | Yes — Windows server + install rights | No | Free |
| Agent Ransack / UltraSearch | Minutes — on-demand scan | Always current (full rescan each time) | No | Agent Ransack: yes | Free tiers |
| Malvicsearch | Instant after one-time initial scan (12 ms on a 9.36M-file index in our tests) | ~2 s median via SMB notifications + 15-min re-sweep | No | No | $29 lifetime |
No. A mapped drive letter is just an alias for the UNC path; both go through the same SMB redirector, so performance is identical. Every tool discussed here treats them the same, and Malvicsearch indexes both forms.
The server-side options disappear: you can't install the Windows Search service or Everything's ETP server on a NAS. QNAP's Qsirch and Synology's Universal Search index on the NAS itself, but they're vendor-specific and live in the NAS's own web UI and apps rather than in your Windows workflow. Client-side approaches — on-demand scanners and Malvicsearch — work unchanged, because the NAS is just another SMB server. We go deeper in why NAS file search is slow from Windows.
Yes — once the names are in a local index, scale stops being the problem. Our measured examples: 9,363,175 indexed files with a 12 ms query, and a 56 ms query matching 5.4 million files across local and network drives. The cost that grows with share size is the one-time initial enumeration, which is why Malvicsearch runs up to 64 directory enumerations in parallel.
SMB carries change notifications that a client can subscribe to. Malvicsearch uses them — median ~2 seconds from change to index update in our test suite — and backstops missed notifications with an automatic re-sweep every 15 minutes by default, plus a manual refresh command. Everything's folder indexing doesn't use SMB notifications, which is why it depends on scheduled or manual rescans instead.
By design, the Windows client indexer excludes network locations, so Explorer falls back to a live crawl on every search of a share. Microsoft's supported route is the Windows Search service on the server itself; the closest client-side workaround is Offline Files, which syncs the share to local disk — fine for small folders, unrealistic for multi-terabyte shares.
Searching a file server shouldn't cost minutes per query. Malvicsearch keeps an always-fresh index of your shares with nothing installed on the server — try the free 5-day trial (no credit card) or see pricing: $29 once, 14-day money-back guarantee.