OpenMediaVault SMB Slow? 4 Checks Before Tuning

Slow SMB transfers are almost never a Samba problem, which is why the standard advice of pasting tuning parameters into a configuration file so often fails to help and sometimes makes things worse. A file copy crosses four layers, and each one has its own ceiling: the network wire, the storage underneath the share, the SMB protocol itself, and the client at the far end. The fix is to find which ceiling you have hit before touching anything.

This is a documentation-based diagnostic order, not a list of settings to copy. Work down it and stop at the first layer that explains the number you are seeing.

First, know what “slow” should look like

The OpenMediaVault prerequisites page states the constraint that decides most cases: NAS write speed to storage is limited to the speed of the network interface, and to the speed of the network itself. It also recommends full-duplex network cards, noting that half-duplex parts typically run at 10/100 Mbit while storage drives far exceed those speeds.

Do the arithmetic once and write the number down. A 1 Gbit/s link carries 125 MB/s before overhead. Ethernet framing plus TCP and SMB headers take a slice, so a healthy gigabit transfer of large files lands somewhere in the low 110s of MB/s. If you are seeing 110 MB/s, nothing is broken. The wire is full and no Samba setting will change that.

The numbers that indicate a real problem look different:

• Around 11 MB/s: a link negotiated at 100 Mbit rather than 1 Gbit, usually a cable or a switch port.
• 40 to 70 MB/s on large sequential files over gigabit: something below Samba is limiting throughput.
• Fast at first, then collapsing after several gigabytes: a write cache filled and you are now seeing the true sustained speed of the disks.
• Fine for one large file, painful for thousands of small ones: this is protocol round-trip cost, not bandwidth, and it is normal to a degree.

That last distinction matters more than anything else on this page. Bandwidth problems and latency problems have different causes and different fixes, and a single large-file copy plus a folder-of-small-files copy will tell them apart in two minutes.

Layer 1: prove the network

Test the network without touching storage at all. A memory-to-memory throughput tool such as iperf3 between the client and the NAS reports what the path can carry with no disks involved. If that test comes back near line rate, the network is exonerated and you can stop looking at it. If it does not, nothing else on this page is worth doing yet.

Check link speed on the NAS interface and on the switch port. Autonegotiation failures that drop a gigabit link to 100 Mbit are common and are usually a marginal cable, a damaged connector, or a port set to a forced speed on one side only. Powerline adapters and WiFi bridges in the path will also cap throughput far below what the endpoints report, because the bottleneck is a segment neither end can see.

If the network is genuinely the limit and everything is already correct, then the fix is hardware rather than configuration. Moving to 2.5 GbE, which many current boards include, or to 10GBASE-T with a card such as the Intel X550-T2 raises the ceiling. Both ends and the switch have to change together, which is the part that gets underestimated. What to look for in the rest of the build is covered in the OpenMediaVault hardware guide.

Layer 2: prove the storage

Now test the array locally on the NAS, with no network involved. Write a large file to the shared folder’s underlying path and read it back, using a size several times larger than system memory so that caching does not flatter the result. If local write speed is already below your network number, the array is the constraint and Samba is irrelevant.

Several storage-side causes are common and specific.

SMR drives. The prerequisites documentation warns that for RAID, SnapRAID or mergerfs setups you should prefer CMR drives over SMR, because SMR drives can stall during rebuilds and parity sync, and the recording technology is usually not obvious from the model number. The same behaviour shows up in ordinary use as writes that start fast and then fall off a cliff once the drive’s staging area fills. No configuration fixes it.

A degraded or rebuilding array. A rebuild reads every remaining disk and competes directly with your transfer. Check array state before blaming the protocol.

ZFS record size against the workload. OpenZFS datasets use a 128 KB record size by default, and partial record writes require the record to be read first, from cache if it is there and from disk if it is not. That read-modify-write cost is invisible on large sequential copies and very visible on workloads that rewrite small pieces of large files. The record size only applies to newly written files, so changing it is not retroactive.

Encryption on a weak processor. Full-disk encryption runs in software, and throughput follows the AES performance of the CPU.

The share sitting on the system disk. The documentation is explicit that the system drive cannot officially be used for shared resources or user data. A share placed there competes with logging and package activity, and the layering that prevents this is set out in planning an OpenMediaVault NAS.

Layer 3: what not to change in Samba

Only now is Samba worth looking at, and the most valuable guidance is subtractive. The Samba project’s own performance tuning page opens by saying that in most cases performance problems are caused by incorrectly set parameters.

Do not set socket options. The Samba wiki states this directly: modern UNIX operating systems are tuned for high network performance by default, Linux auto-tunes buffer sizes, and setting this parameter overrides that mechanism. In most cases it decreases performance. If it is present in your configuration because a forum post from a decade ago recommended it, remove the entry from the global section.

Do not set server max protocol. The wiki recommends leaving it unset, because when it is not specified, updating Samba to a version providing a newer SMB dialect makes that dialect automatically available to clients. Pinning it freezes you on an older protocol version and forfeits the improvements each one brought.

Both of these appear constantly in copied configuration snippets and both are, per the maintainers, more likely to hurt than help. Removing them is the highest-value Samba change most installations can make.

One tuning that is documented and does help, narrowly. For shares holding directories with more than 100,000 files, the wiki describes converting all filenames to lowercase and setting case sensitive = true, default case = lower, preserve case = no and short preserve case = no in the share section, then reloading with smbcontrol all reload-config. This removes the need for Samba to scan directories for case variants. The warning attached to it is serious: after applying it, files with uppercase characters are no longer listed on the share, so every existing filename must be converted first. This is a real fix for a real and narrow problem, and a bad idea everywhere else.

For any other parameter, read its entry in the smb.conf manual page before setting it. A parameter you cannot explain is a parameter that will confuse you in a year.

Layer 4: the client

If one machine is slow and everything else is fast, the problem is that machine. Real-time antivirus scanning of network paths is a frequent cause, and it is easy to confirm by testing with scanning temporarily excluded for the share. Windows power plans that park cores, aggressive endpoint security products, and a client on WiFi while everything else is wired all produce the same symptom.

Test from a second client before spending any more time on the server. This one step resolves a surprising share of cases and costs nothing.

The small-files problem, honestly

Thousands of small files will always transfer far slower than one large file of the same total size, on every SMB implementation. Each file involves protocol operations to create, write, set metadata and close, and those round trips are bounded by latency rather than bandwidth. A faster network card does very little for this workload.

If you need to move a large tree of small files, pack them into a single archive first so the transfer becomes one large sequential stream instead of thousands of round trips. Where that is impractical, rsync over SSH is usually the better tool, because it pipelines its work rather than waiting on an SMB exchange per file, though it does not remove the per-file cost entirely. Either way this is a workflow change rather than a fix, because there is nothing to fix.

A checklist that fits on one screen

1. Copy one large file and one folder of small files, and record both numbers.
2. Run a memory-to-memory network test. If it is slow, stop and fix the network.
3. Test the array locally with a file larger than system memory. If it is slow, stop and fix the storage.
4. Check array health and whether any rebuild or parity sync is running.
5. Remove socket options and server max protocol from smb.conf if present.
6. Test from a second client, and disable real-time scanning on the share path to check.
7. Only then consider a documented tuning that matches your specific workload.

If step 2 or step 3 reveals that the build itself is the limit, the capacity and protection arithmetic behind a rebuild is worth revisiting in the OpenMediaVault Array and ZFS Sizer, and the choice of platform in the first place is compared in OpenMediaVault vs TrueNAS vs Synology.