← Blog · July 20, 2026 · 9 min read

How to Index a Network Share on Windows — Why Windows Search Can't, and What Actually Works (2026)

You open Indexing Options, click Modify, and your mapped drive simply is not in the list. You add the UNC path to a Library and Windows refuses, or accepts it and searches at a crawl anyway. Here is the answer almost nobody on the first page of Google states plainly: the Windows Search indexer on your PC does not index network locations, by design, and there is no supported switch to change that. This article explains the actual mechanism, walks through every workaround with its real cost, and ends with a decision matrix so you can pick the right fix for your setup in about a minute.

Why Windows Search won't index network shares (the real technical reason)

This is not a bug and not a missing checkbox. The client-side indexer only builds indexes for local volumes. UNC paths (\\server\share) and mapped drive letters are excluded from its scope on purpose, and the reason comes down to how fast indexing is possible at all.

On a local NTFS drive, the file system cooperates with an indexer. The Master File Table (MFT) is a single, compact record of every file on the volume, so an indexer can read millions of file names in seconds without walking the folder tree. After that, the USN change journal is a running log of every create, rename, move, and delete — so keeping the index fresh costs almost nothing.

Over SMB, neither of those exists for the client. The protocol hands you directory listings, one directory at a time, each costing a network round trip. There is no remote MFT to read and no change journal to subscribe to in the same way. Building an index of a million-file share from the client means brute-force enumeration — and, much worse, keeping it fresh means enumerating again and again. Microsoft's architectural answer was: don't. Index the files where they live (on the server) and forward the query there.

The consequence you actually feel: when you type into Explorer's search box on a network share, there is no index behind it at all. Explorer performs a live recursive crawl of every folder over SMB, which is why a search can take minutes and make the server's disks rattle. We've broken down that failure mode in detail in how to search a network drive fast on Windows.

Fix 1: Windows Search Service on the file server — the official way

The supported solution is to install the Windows Search Service on the machine hosting the share and add the shared folders to its index. Once that's in place, an Explorer search inside the share is remoted: your PC sends the query to the server, the server answers from its index, and results come back fast. From the user's chair it just looks like Windows Search finally works on the share.

The limits are severe, though:

• Windows Search Service is a role service of Windows Server. You need admin rights on the server to install it, and the index consumes server CPU, RAM, and disk.
• If your share lives on a NAS box or a Samba/Linux server — which describes most home labs and a large share of small offices — this option does not exist at all. There is nothing to install.

If you administer a Windows Server file server and your users search from Explorer, do this — it's the clean fix. Everyone else, keep reading.

Fix 2: Offline Files — the hidden cost of syncing the whole share

Right-click a network folder and choose "Always available offline" and Windows syncs it into the local client-side cache. Because the cached copy lives on a local volume, the normal indexer can index it, and searching that folder becomes fast.

The mechanism is honest; the cost is not obvious until you hit it:

• Local disk equal to the data you sync. Making a 4 TB share searchable this way means storing 4 TB on your laptop. For multi-terabyte shares it's simply not practical.
• Sync conflicts when multiple people edit the same files.

Where it genuinely fits: a modest, mostly-yours folder (say, a 50 GB project directory) that you also want available on a laptop that leaves the building. As an indexing strategy for a whole share, it's a sledgehammer.

Fix 3: Library and registry workarounds — what they do and don't fix

Forums are full of tricks for this problem: forcing a UNC path into a Windows Library, creating a local symlink that points at the share, and .reg files that circulate under names like AllowRemoteIndexing. It's worth being precise about what these achieve.

At best, they convince Explorer's UI to accept a network location somewhere it normally wouldn't — into a Library, into a search scope. What none of them do is make the client indexer actually build an index of the share, because the indexer's exclusion of remote locations is architectural, not a permission flag. When you then search that Library, Windows quietly falls back to the same live SMB crawl as before — now hidden behind a Library icon, so it looks like it should be indexed and confuses you when it's slow. Symlink tricks fare no better: the indexer does not traverse a link to a remote target.

These hacks are also unsupported. Verdict: fine for organizing folders you browse; not a fix for search.

Third-party tools that index network drives, compared

Since Windows won't build a client-side index of a share, the practical alternative is a tool that will. They differ sharply in how they handle network locations, so here is the honest landscape:

Two tools deserve a closer look, because the interesting differences are all in the "network" column.

Where Everything shines — and where it struggles on SMB shares and NAS

Everything is the best local file-name search tool on Windows, full stop. It reads the MFT and subscribes to the USN journal, results are instant, and it's free. If all your files are on local NTFS drives, install Everything and stop reading — you don't need to pay anyone anything.

Network shares are where its model runs out of road, per its own documentation. Everything's "folder indexing" for a UNC path is a plain recursive directory walk over SMB — the same slow enumeration Explorer does, just done once and cached. After that, the index only updates when a scheduled or manual rescan walks the entire share again; there is no realtime change detection over SMB. To get true realtime updates on a share, you must run Everything (or its ETP/HTTP server) on the server machine itself — which requires the server to be Windows and requires install rights on it. On a NAS or Samba box, that's a dead end. We compare the whole field in more depth in Everything alternatives for network drives.

So the practical gap is: a persistent, automatically fresh index of a share you can't install anything on. That gap is exactly what Malvicsearch was built for.

How Malvicsearch keeps a network-share index fresh in realtime

Malvicsearch is a Windows 10/11 (64-bit) desktop app that indexes file and folder names and paths — local and network — and returns results as you type. It is purely client-side: nothing is installed on the server or NAS, so it works identically against Windows Server, Synology, QNAP, TrueNAS, or a bare Samba share.

• First index of a share: a parallel directory scanner runs up to 64 concurrent directory enumerations with 256 KB batches per network round-trip — attacking SMB's per-directory latency with parallelism instead of walking the tree one folder at a time.
• Staying fresh: Malvicsearch subscribes to SMB change notifications for indexed shares — in our test suite, changes on the server appear in the index with a median latency of about 2 seconds. Because notifications over SMB can be missed, an automatic re-sweep runs every 15 minutes by default as a safety net, and there's a manual "Refresh network locations now" menu item.
• Local drives: full MFT-based indexing with realtime USN journal updates — without requiring Administrator rights, which matters on locked-down office machines.
• Scale, measured on our workstation: 9,363,175 files indexed, with a query returning 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 1 second at startup and is searchable immediately.
• Privacy: the index stays entirely on your machine, nothing is uploaded anywhere, and search works offline against the last-known state of a share.

What it does not do: Malvicsearch does not search file contents — it finds files by name and path only. If you need "which documents contain this phrase," use Agent Ransack, which is excellent at exactly that. And if your files are strictly local NTFS, Everything is free and superb — you don't need Malvicsearch for that case either. Where it earns its price is shares and NAS boxes you can't install software on.

The trial is free for 5 days with full features and no credit card; after that it's $29 one-time for a lifetime license (1 PC), with a 14-day money-back guarantee.

Which fix should you use? A decision guide by scenario

If your searches are slow specifically against a NAS, we've written a dedicated troubleshooting guide: why NAS file search is slow on Windows (and how to fix it).

FAQ

Why can't I add a network drive to the Windows Search index?

Because the client-side indexer only indexes local volumes. Fast indexing depends on NTFS structures — the MFT for the initial build and the USN change journal for updates — and neither is available to a client over SMB. Microsoft's design is to index on the server and forward queries there, so UNC paths and mapped drives are excluded from the client index with no supported override.

Do the registry hacks like AllowRemoteIndexing actually work?

No. The registry and Library tricks that circulate on forums can make Explorer accept a network location into a Library or search scope, but they don't cause the indexer to build an index of the share. Searches in those locations still run as a live folder-by-folder crawl over SMB.

Does Everything index network drives?

Yes, via its folder indexing feature — but that is a full directory walk over SMB, refreshed only by scheduled or manual rescans. Everything has no realtime change detection over SMB; per its documentation, realtime updates on a share require running Everything or its ETP/HTTP server on the server machine itself, which must be Windows and requires install rights there.

How do I index a Synology, QNAP, or Samba share from Windows?

You can't do it with Windows Search — the server-side fix (Windows Search Service) only exists on Windows Server. Your options are the NAS vendor's own search (Synology Universal Search, QNAP Qsirch — content-capable but confined to the NAS's web UI and apps) or a client-side indexer on your PC. Malvicsearch builds and maintains its index entirely from the client, so it works against any SMB server with nothing installed on the NAS.

Does Malvicsearch need anything installed on the server?

No. It is purely client-side: the first index is built with a parallel SMB directory scan, then kept fresh with SMB change notifications (about 2 seconds median in our tests) plus an automatic re-sweep every 15 minutes. The index never leaves your machine.

Can Malvicsearch search inside file contents?

No — it searches file and folder names and paths only. For content search (finding text inside documents), Agent Ransack is the right tool; for content search hosted on a NAS, look at QNAP Qsirch or Synology Universal Search on their respective platforms.