Why SMB browsing feels slow on a Synology or QNAP, and what a caching mount changes

Here is the complaint, almost word for word, every time it arrives. "I bought a 10 GbE card and a switch. The speed test says 900 megabytes a second. I open the footage folder and it takes fifteen seconds to draw, and scrolling stutters, and searching for a filename is a coffee break." Then, usually: "is my NAS broken?"

Almost certainly not. You measured the one thing that is not the problem. A speed test measures throughput, which is how many bytes per second the wire can carry once bytes are moving. Browsing a folder is a metadata workload, which is a long conversation of tiny questions and answers, and the cost of a conversation is not bandwidth. It is the number of times you have to wait for a reply.

This piece is about that gap: what SMB is actually doing when a folder opens, where the seconds really go on a Synology or a QNAP, which fixes are free, and, at the end and stated carefully, what a caching mount changes and what it does not.

The four words you need first #

SMB is Server Message Block, the file-sharing protocol macOS and Windows use to talk to a NAS. When you connect to smb://nas.local/media in Finder, that is SMB. Synology and QNAP both implement it with Samba, the open-source SMB server.

A round trip is one question sent to the server and one answer received. The clock cost of a round trip is the network's latency, not its bandwidth. On a good wired LAN a round trip costs somewhere around 0.1 to 0.5 milliseconds. That sounds free. It is not free when there are a hundred thousand of them.

Metadata is everything about a file that is not the file's contents: its name, size, type, dates, permissions, and any extra attributes the operating system has attached. Finder needs metadata to draw a row. It does not need the file's contents to draw a row, unless it wants a thumbnail, which it usually does.

An index is a local database of that metadata, kept up to date, so a question about it can be answered without asking the server at all. Almost every performance difference in this article comes down to whether such an index exists on your side of the wire.

What actually happens when you open a folder #

Opening a directory over SMB is not one request. It is a sequence, and the sequence is longer than most people picture.

1. Connect and negotiate. If this is a fresh connection, the client and server agree on a protocol version, authenticate, and connect to the share. This happens once per session, so it is not the ongoing cost, but it is why the first folder after a sleep feels worse than the rest.
2. Open the directory. A create request on the directory itself, which returns a handle.
3. Enumerate it. One or more query-directory requests. The server returns a batch of entries with basic attributes. A large directory takes several batches, and each batch is another round trip.
4. Fill in what the enumeration did not carry. Finder's list view shows Kind, Size, and Date Modified. Some of that arrives in the enumeration. Some of it does not, and the client asks per file.
5. Check the extras. macOS keeps its own metadata on files: Finder flags, tags, colour labels, and the resource fork. On SMB these live in a named stream or an AppleDouble sidecar. Finder checks for them.
6. Draw the icons. This is the expensive one, and it gets its own section below.

Every one of those steps is a wait. Not a transfer, a wait. And the waits are mostly serialised, meaning each depends on the answer to the one before, so they add up in single file rather than overlapping.

Now do the arithmetic on a real directory. A camera-card dump of a two-day shoot: 4,000 clips, each with a sidecar, so 8,000 entries. If the enumeration is efficient and returns a hundred entries per round trip, that alone is 80 round trips, which at 0.3 ms is 24 milliseconds. Genuinely fine. But if the client also asks a per-file question about even a quarter of those entries, you have added 2,000 round trips, and now you are at six-tenths of a second before anything is drawn. Add thumbnails and you leave the land of milliseconds entirely.

Where the seconds really go #

Four costs dominate, and in my experience they arrive in roughly this order of severity for a media volume.

Thumbnails and previews. This is the big one, and it is almost always the answer. In icon view, and in list view with "Show icon preview" enabled, Finder does not draw a generic film-strip icon for your clips. It asks QuickLook to generate a real thumbnail, which means opening the file and reading enough of it to decode a frame. For a ProRes or BRAW or R3D file, "enough" is a header plus some amount of the stream. Multiply a partial read by four thousand clips and you are now doing file I/O, over the network, on a folder you only wanted to look at. This is why the same folder is instant in a terminal and glacial in Finder.

Per-file attribute queries. The "Kind" column has to come from somewhere. So do the extended attributes macOS wants to check. Each of those is a round trip, per file, and on a share you have not visited recently none of it is cached.

Directory sizes. If "Calculate all sizes" is on in View Options, Finder recursively walks every subdirectory to sum it. On a media volume with nested project folders, that is a tree walk you did not ask for, running in the background, generating thousands of round trips while you try to scroll.

.DS_Store writes. Finder stores per-folder view settings in a hidden .DS_Store file in each directory it displays. On a network share that is a create, a write, and a close, per folder, and on a share several people are browsing at once it is contention on top of chatter.

None of that is a Synology bug or a QNAP bug. It is Finder doing what Finder does, over a protocol that charges per question, against a volume with a very large number of files in it. A Windows client is chattier in some places and less chatty in others; the shape of the problem is the same.

Why a faster wire barely helps #

Take the folder that took ten seconds on 1 GbE and put it on 10 GbE. What changed?

Bandwidth went up tenfold. Latency did not. A round trip on a 10 GbE LAN is not ten times shorter than a round trip on 1 GbE; it is very slightly shorter, because the serialisation delay of a small packet shrinks, but the dominant cost is switch and stack processing, which is roughly the same. So the thousands of small questions cost what they cost. The only part of your ten seconds that got faster is the thumbnail reads, and only the part of those that was actually bandwidth-bound, which for a few hundred kilobytes of file header is close to none of it.

That is the whole reason a fast LAN and a slow-feeling share coexist so comfortably. Bandwidth fixes transfers. Latency fixes browsing. Buying a bigger pipe is a fix for the wrong problem.

The corollary is worth stating, because it is the honest version: if your complaint is that a 200 GB file takes too long to copy, then bandwidth is your problem, and 10 GbE is exactly the right purchase. The two complaints sound similar and have opposite answers. Our checklist for diagnosing a slow NAS walks the layers in order so you can tell which one you have.

The free fixes, in the order I would try them #

Do these before you spend anything. Several of them are large.

1. Turn off icon previews. In the folder, press Command-J for View Options and uncheck "Show icon preview". Do it in list view, and set it as the default for that view if you can. This is the single biggest lever and it costs nothing.
2. Turn off "Calculate all sizes." Same View Options panel. There is no reason for Finder to be recursively summing a media tree while you work.
3. Use list view, not icon view or gallery view. Gallery view is a thumbnail generator with a file browser attached.
4. Split enormous directories. A folder with 20,000 items in it is a bad shape for any network filesystem. Date-based or card-based subfolders cost nothing and change the arithmetic above by an order of magnitude.
5. Turn on SMB3 Multichannel if your hardware qualifies. On Synology this is in the SMB service settings, and per Synology's own documentation it needs either multiple network adapters of the same speed on both ends, or a single adapter that supports receive-side scaling. It helps throughput and parallelism. It does not remove round trips, so treat it as a transfer fix, not a browsing fix.
6. Leave macOS directory caching alone. macOS already caches SMB directory enumerations, which is why the second visit to a folder is faster than the first. Apple documents a dir_cache_max_cnt setting in /etc/nsmb.conf for turning that cache off, which you would only want when stale listings are causing a correctness problem. Setting it to zero for "performance" makes browsing worse, not better. Worth knowing because the advice circulates backwards.

If your problem is only that the same handful of folders are slow the first time each day, this list may be the entire fix, and you can stop reading here with my blessing.

What a caching mount actually changes #

If the list above did not get you there, the remaining problem is structural: the metadata lives on the far side of the wire, and every question about it has to cross.

A caching mount changes where the answers live. Two separate mechanisms, and they are worth keeping apart because they solve different halves.

Local metadata. Instead of asking the server what is in a directory, the client keeps its own database of the filesystem's structure and consults that. A directory listing becomes a local database query. JuiceMount keeps this in SQLite on your Mac's own SSD. On a volume with more than 100,000 entries, directory opens measured 15–120 ms, against 3 to 10 seconds through raw FUSE without that layer. Filename search across roughly 131,000 entries answered in about 29 ms, because it is an index lookup rather than a tree walk. Those are the author's measurements on the author's hardware.

A local block cache. File contents are stored as blocks, and a block you have read once sits on your SSD. The second read does not cross the wire. Cached reads through the full path measured 226–571 MB/s. This is what makes revisiting a clip feel local, and it is also what makes thumbnails cheap the second time.

There is a third thing, which matters more than it sounds: when the network is gone, a mount with a local index can say so in 4–67 ms rather than hanging Finder through a thirty-second retry. A beachball is not slowness, it is an unanswered question, and an unanswered question is what a network filesystem does when the network stops.

What it does not change, stated plainly #

I would rather you find these out here than after installing something.

• The first read of anything still crosses the wire. A cache is a memory, not a teleporter. Cold media is exactly as fast as your link, and no faster.
• It does not fix a slow array. If your pool is a handful of spinning disks and you are trying to run four 4K streams off it, the disks are your ceiling and no client-side software touches that.
• It does not fix throughput problems. See above: transfers are bandwidth, and bandwidth is bandwidth.
• It adds a service to run. There is now a thing on your NAS that has to be installed, updated, and occasionally troubleshot. That is a real cost and I am not going to pretend it is free.
• The cache costs SSD. You are trading local disk for latency. If your Mac has 256 GB of storage and 40 GB free, this trade is not available to you.
• These numbers are one person's rig. Everything measured above is an Apple-Silicon Mac talking to a TrueNAS SCALE box on 10 GbE, measured by me, published with the methodology and the harness so you can run it yourself. Your hardware will differ, possibly a lot.

The short version #

Browsing a media volume over SMB is slow because it is a conversation, and the conversation has thousands of turns, and each turn costs a wait that bandwidth does not shorten. Thumbnails are usually the largest single contributor and they are free to switch off. Splitting oversized directories is the next largest and also free. Past that, the only structural fix is to stop asking: keep the metadata on your side of the wire in an index, and keep the blocks you have already read on your own SSD.

That is what a caching mount is for, and it is worth being precise that this is all it is for. It makes the questions cheap. It does not make your disks faster or your internet wider.

If your slow share is a remote one rather than a LAN one, the same round-trip arithmetic applies with a much larger multiplier, and we worked that case separately in why your NAS feels slow over a VPN. The search half of this problem gets its own treatment in why finding a clip on a NAS is slow. If you are weighing this against paying a vendor to solve it, what a mounted drive really costs per seat has the current numbers, and Frame.io Drive versus a self-hosted mount covers the newest entrant.

Sources, checked 16 August 2026

• SMB protocol behavior: Microsoft's SMB protocol documentation for the open, create, query-directory and query-info request types that a directory listing is composed of. Behavior described here is the protocol's normal operation, not a defect in any vendor's implementation.
• macOS directory caching: Apple Support, Disable local SMB directory enumeration caching. macOS caches SMB directory enumerations by default; the article documents the dir_cache_max_cnt setting in /etc/nsmb.conf for the case where you need listings to be fresher rather than faster. /etc/nsmb.conf does not exist by default.
• Synology's own Finder guidance: Synology Knowledge Center, What can I do to improve browsing experience when viewing files on Synology NAS via Finder on Mac?. The article body is rendered by JavaScript and could not be captured verbatim; it is listed here as the vendor's own page on this exact question.
• SMB3 Multichannel on Synology: Synology Knowledge Center, What is SMB3 Multichannel and how is it different from Link Aggregation? and the SMB Settings help page. Multichannel needs either multiple network adapters of the same speed on both ends, or a single adapter that supports receive-side scaling.
• JuiceMount figures (directory opens, filename search, cached reads, offline refusal): the performance page ledger and the public methodology in the app repository. Measured by the author on an Apple-Silicon Mac and TrueNAS SCALE over 10 GbE. Point-in-time author measurements on one Mac and one NAS, not independent benchmarks.