Answering "who can reach this file?" across a dozen servers
- Sector
- Multi-site IT operations
- Period
- 2025
- Role
- Sole developer
- Stack
- .NET · PostgreSQL · NTFS
Situation
Years of Windows file servers across several sites, and no shared view of any of them. Three questions had no reliable answer.
What is actually on these servers? Nobody could say without logging into each one. What changed? Only noticeable once something was missing. And the one that matters at audit time: who can reach this directory?
That last question looks answerable — NTFS permissions are right there in the properties dialog. But permissions are granted to groups, groups contain groups, and the real answer is a resolved list of people. Producing that by hand, for hundreds of thousands of directories across a dozen machines, is not a task anyone completes.
What I built
An indexer service that runs on each file server and walks its own volumes, reading file metadata and NTFS permissions locally rather than dragging everything across the network, and writing into one central PostgreSQL database. A single web interface then reads across every server at once.
What's there is a searchable inventory spanning all servers: sizes, ages, types, and where the weight actually sits.
What changed works because scans are kept as history rather than overwritten. The system answers change over an interval — what appeared, what grew, what disappeared between two dates — which turns storage growth from a surprise into a trend.
What's duplicated is detected across servers, not merely within one. That distinction is where the recoverable space actually is: the same project folder copied onto three machines by three different people over five years.
Who can reach it resolves NTFS permissions through nested group membership into a plain list of people, per directory. That is the form an auditor asks for, and the form no built-in tool produces.
Outcome
Storage decisions became evidence-based rather than instinctive, and an access review became a query someone runs instead of a project someone schedules.
Structurally this is the same shape as the industrial work: collect at the edge where the data lives, centralise into one store, and read across it from a single interface. The domain is unrelated; the architecture is not.