Skip to content
DuoBolt

NAS Duplicate File Finder

A NAS accumulates duplicates faster than any other storage you own. Years of phone backups, photo libraries synced from three devices, a spouse’s media library, a second copy “just in case”, a torrent that overlapped with a streaming rip — it all stacks up on the same volume and grows invisibly for years.

This page covers how DuoBolt handles NAS scanning specifically: why network storage is the hardest case a duplicate finder faces, how DuoBolt’s engine was built around the problem, and a step-by-step guide for scanning Synology, QNAP, TrueNAS, Unraid, and any SMB/NFS share.


Why NAS Is the Hardest Place to Find Duplicates

Section titled “Why NAS Is the Hardest Place to Find Duplicates”

Scanning a NAS is fundamentally different from scanning a local SSD. Three things work against any scan of it:

Cold, spun-down disks

A power-saving NAS parks its HDDs after idle minutes. First-access latency jumps from milliseconds to seconds as each drive spins up. Tools that read files sequentially stall on every new directory.

Network I/O latency

Every file open, stat, and read is a round-trip over Ethernet. A local scan doing 50,000 files/sec might drop to 500/sec over SMB. Legacy tools never see saturation — they’re always waiting on the wire.

One file at a time

A scan that hashes one file, then the next, spends most of a NAS run waiting on the wire rather than on the CPU. On an 8-core machine that is seven cores idle while the eighth waits for a network read to land.

The result is that a NAS scan is decided by latency rather than by hashing. In our benchmark suite, 1.09 TiB of music and video over SMB took DuoBolt 10 seconds and Czkawka 11 — a tie, within that tier’s measurement resolution. dupeGuru took 17 seconds, also too close to separate. Gemini 2 took 3m39s.

So speed is not what sets DuoBolt apart over a network share; on that medium the wire decides, and any well-built scanner runs into the same wall. What differs is what happens around the scan: the rescan cache with its own network threshold, clone-aware accounting, and a removal you can undo.


DuoBolt was designed from day one with NAS and terabyte-scale storage in mind. Four architectural decisions compound to deliver the speed advantage:

  1. Per-root parallelism

    Multiple scan roots run in parallel instead of sequentially. If you point DuoBolt at /Volumes/NAS/photos and /Volumes/NAS/videos, both walk concurrently, so the bottleneck becomes disk and network throughput — not tool pacing.

  2. Streaming chunked I/O

    Reads are chunked and streamed, overlapping disk access with hashing. While BLAKE3 processes one chunk, the next is already on the wire. CPUs stay busy; the network is never the limiter waiting for a free core.

  3. Multi-core BLAKE3 hashing

    BLAKE3 is tree-structured and multi-core by design. On an M2 Max scanning a NAS, DuoBolt uses all performance cores in parallel to process chunks, saturating whatever I/O the NAS can deliver.

  4. Head+tail prehash

    Before any full-content hash, DuoBolt hashes just the first and last N KiB of each candidate file. Non-matches are eliminated from the candidate pool before touching the rest of the file — a massive I/O saving on large media files that look similar by size but differ at the edges.


Cold scan — 38 seconds

1.09 TiB over SMB 3.1.1 — 699 GiB video and 420 GiB music — with the NAS restarted first so neither end held a cached thing. DuoBolt discovers, prehashes, full-hashes and groups all of it in well under a minute.

Warm scan — 6 seconds

Same volume, caches warm on both ends. DuoBolt’s cache layer short-circuits unchanged files, and repeat runs landed between 2 and 6 seconds. Measured 20 September 2026 on an M2 Max.

For side-by-side comparison with Czkawka, dupeGuru, Gemini 2 and Nektony’s Duplicate File Finder on the same hardware, see the full benchmark results. The figure there is 10s rather than either of these, because that comparison runs with the client’s cache cleared and the NAS’s own cache left warm — the one state that can be reproduced for every tool in a single session.


Cache Layer — Why Warm Scans Finish in Seconds

Section titled “Cache Layer — Why Warm Scans Finish in Seconds”

The difference between a 38-second cold scan and a 6-second warm one is not magic — it is DuoBolt’s cache layer working as designed. When DuoBolt hashes a file, it records the full-content BLAKE3 hash keyed by path, size, and modification time. On subsequent scans, files whose (size, mtime) signature is unchanged skip hashing entirely and pull their hash from the cache.

For a NAS this matters more than for any other target. Every hash retrieved from cache is one file DuoBolt does not read over the network — the single biggest win on a medium dominated by SMB or NFS latency.

Configure the cache under Settings → Storage. Toggle the hash cache on or off, and set separate minimum sizes for local and network volumes — the network one defaults lower on purpose, because re-reading a small file over SMB costs far more than caching it does. Every control, with its default.

The Settings Storage panel: the hash cache toggle above minimum file size sliders for local and network volumes, set to 64 and 32 KiB, followed by the buttons that clear each cache and compact the cache file.

The Minimum file size (network) slider is the one to reach for on a NAS — lower it to cache smaller files on slow NAS shares, raise it to keep the cache lean. Compact cache file reports what the cache is holding and returns the room it no longer uses, without dropping anything it has cached.


  1. Mount the share on your machine

    • macOS: Finder → Cmd+K → smb://your-nas.local/volume (or afp://, nfs://)
    • Windows: File Explorer → right-click “This PC” → Map Network Drive
  2. Open DuoBolt and click Add Folder

    Navigate to the mounted share and select the directory you want to deduplicate (e.g., /Volumes/NAS/photos).

  3. Configure filters (optional but recommended)

    • Min size: set to 1 MiB or higher to skip thumbnails and metadata files
    • Ignore hidden files and Ignore system files on
    • Exclude directory extensions: .photoslibrary, .aplibrary, .tmbundle (macOS managed bundles)
  4. Run the scan

    First scan is “cold” — expect the times shown in our benchmark. Subsequent runs benefit from DuoBolt’s cache layer.

  5. Review before deleting


DuoBolt runs on a desktop that has the share mounted, not on the NAS itself. It never speaks to the appliance: it reads whatever the host operating system presents as a folder. That is worth stating plainly, because it decides what we can and cannot claim below.

Measured here:

  • Synology DS920+, DSM 7, three HDDs, over SMB on a gigabit link. The 1 TB figures on this page and in the benchmarks come from that machine and no other.

Works because the mount works:

Any share the host can mount — Synology, QNAP, TrueNAS, Unraid, Asustor, TerraMaster, UGREEN, a Windows file server, a Linux Samba or NFS export. DuoBolt sees a folder in /Volumes or behind a drive letter and treats it as one. We have not measured these, and we are not going to imply otherwise; if your host mounts the share, the scan works the same way it does on the Synology above.


DuoBolt does not speak network protocols directly. It scans through whatever the host operating system mounts, so the protocol choice lives entirely on the mount side — but it materially affects scan throughput, especially on long cold scans.

  • SMB (SMB3) — what macOS and Windows use to mount a modern share, and the configuration every figure on this page was measured on. Supports multichannel, encryption and signing. Start here.
  • NFS (v4) — common on Linux hosts and ZFS-backed NAS. Lower per-operation latency than SMB in many setups, at the cost of trickier UID/GID permission semantics. We have not benchmarked it, so treat that as a reason to try it rather than a result.
  • AFP — on the way out. Apple’s own guidance is that Time Machine backups to a NAS over AFP are not recommended, and will not be supported in macOS 27 or later. Mount over SMB instead.
  • SSHFS — convenient (any machine with SSH access works), but the per-file round-trip overhead is punishing on scans of tens of thousands of small files. Usable for ad-hoc scans; a poor default.
  • iSCSI / block-level mounts — appear as local disks to the OS and to DuoBolt. Fast, but the target is exclusive to one client at a time.

When in doubt: SMB3. NFS only if you have a specific reason.


Not everything on a NAS that looks like a duplicate is one. Backup tools and media apps store managed copies and metadata that inflate scan counts without representing redundancy you would want to remove. Knowing what to skip shortens the scan and produces cleaner results.

Your NAS may keep other system directories of its own. DuoBolt has no list of them by vendor, and inventing one would be guessing — check your vendor’s documentation for what it writes inside a share, and add those names to the scan’s ignore rules.

Recycle bins. Both major vendors put one inside each shared folder, and both are full of files you deleted on purpose — which is to say, intentional copies of things that may still exist elsewhere.

  • #recycle/ — Synology. Created in a shared folder when the Recycle Bin is enabled for it (DSM documentation).
  • @Recycle/ — QNAP. Created in every shared folder after QTS is installed (QTS documentation).

Whether to exclude them is a judgment call rather than a rule: if you are reclaiming space, the recycle bin is where some of it already is.

Time Machine on a network share is stored as a .sparsebundle disk image rather than as loose files. It is a directory underneath, so a scan will walk into it and find its internal band files. Exclude by directory extension: sparsebundle.

macOS metadata on a non-Mac filesystem. ._* AppleDouble sidecars carry the resource fork and metadata that the share’s filesystem cannot store natively, and .DS_Store carries Finder’s per-folder view settings. Both are covered by Ignore system files.

Managed library bundles (macOS):

  • *.photoslibrary, *.aplibrary, *.itlp, *.imovielibrary — appear as single files in Finder but are massive directory trees internally. Exclude by directory extension: photoslibrary, aplibrary, itlp, imovielibrary.

Windows noise: Thumbs.db and desktop.ini, also covered by Ignore system files.

All of the above can be handled in one pass by toggling Ignore system files, Ignore hidden directories, and Exclude directory extensions in the scan setup.


QNAP’s QuTS hero and TrueNAS are both ZFS, and ZFS can deduplicate inline: identical blocks are stored once and referenced twice, with no sign of it at the file level. Two files can be byte-for-byte identical, and real, and occupy one copy’s worth of pool.

That is the same problem APFS clones create on a Mac, and DuoBolt solves it in exactly one place: APFS, on macOS. There is no equivalent check for ZFS. On a deduplicated pool the reclaimable figure DuoBolt reports is an upper estimate — every duplicate it finds is genuinely a duplicate, but removing one may free less than the number says, or nothing.

The verdict is unaffected either way. A BLAKE3 match is a statement about the contents of two files, and it stays true whatever the pool did with the blocks underneath.


  • Warm the cache on the first pass. Cold-scan timings are not representative of steady state; the second run is what day-to-day workflow feels like.
  • Set a sensible minimum file size. Thumbnails, sidecar metadata, and app config files are rarely worth hashing and inflate scan counts without reclaiming space.
  • Exclude managed library bundles (.photoslibrary, .aplibrary, .itlp). These look massive but are not user-facing duplicates. A NAS is where photo libraries usually end up, and the repeats inside one are rarely byte-identical: bursts, exports and re-saves need the duplicate photo finder rather than a hash.
  • Scan during off-peak hours if the NAS is also handling Time Machine backups, streaming, or other heavy workloads — network contention kills scan throughput.
  • Re-run an audit from Scan History. It keeps the exact setup a scan used, so a monthly NAS pass is one click rather than a set-up job.

No, and it does not need to be there. DuoBolt runs on your Mac or PC and reads the share the way any other application does. Nothing is installed on the appliance, no package is added to DSM or QTS, and there is no daemon left running when you close the app.

How do I find duplicate files on a network drive?

Section titled “How do I find duplicate files on a network drive?”

Mount the share first — in Finder, Go → Connect to Server; in File Explorer, map it to a drive letter or type the UNC path. Once it appears as a folder, add it as a scan root like any other. The scan is the same one you would run on an internal disk; only the speed is different, which is what the cache layer above exists for.

Czkawka is open source, actively developed, and hashes with BLAKE3 by default — the same algorithm DuoBolt uses, so its verdicts about which files are identical are as trustworthy as ours.

The part to check is what its delete does. Files are removed outright unless you enable Move deleted files to trash in its settings, and it documents no review step before a removal and no way to restore after one. On a NAS holding things you cannot re-create, that is worth knowing before you start rather than after.

On our 1 TB Synology share it took 142 seconds cold against DuoBolt’s 64, and 59 seconds warm against 20. Those are our measurements, on our hardware, with the methodology published.

There is a second thing worth knowing, and it comes from dupeGuru’s own documentation: network storage is listed as a case where sending files to the Trash can fail, with a “directly delete files” option offered as the workaround. Taking that workaround on a NAS turns a recoverable removal into a permanent one.

A scan reads. Hashes, thumbnails and similarity data are cached on the machine running DuoBolt, not on the share — you can see the cache and clear it under Settings → Storage. Nothing on the NAS changes until you choose an operation and confirm it on the Review screen.