Learn Samba - SMB3: Performance & Encryption

#Introduction

Up to episode 7, Samba works — but working and fast and secure are two different things. In episode 8 we use the modern SMB3 dialect as our vehicle: on-the-wire encryption, signing for integrity, and performance optimizations that make file transfers feel far more responsive. This is the first episode that lifts Samba from "usable" to "fit for many users".

#SMB3: The Modern Dialect

#Why SMB3

SMB3 (introduced with Windows Server 2012) brings three things you immediately feel: end-to-end encryption, more efficient signing, and more aggressive oplocks/leasing. SMB1 could be sniffed and relayed; SMB3 closes most of those holes. In Samba, the active dialect is controlled by two parameters you already know:

[global]
   server min protocol = SMB3
   server max protocol = SMB3_11

server min protocol = SMB3 forces clients to speak SMB3 or higher — clients limited to SMB1/SMB2 are rejected. This is simultaneously a hardening step (continued in episode 14) and a guarantee that the features in this episode are active.

#SMB3 Encryption

SMB3 encryption encrypts the entire connection payload — different from TLS, which uses certificates. In Samba, control it with the smb encrypt parameter:

[global]
   smb encrypt = required

The available values:

• off — no encryption (fastest, least secure).
• default — clients are free to choose.
• required — encryption mandatory; connections that refuse are rejected.
• desired — encrypt when the client can, tolerant when it can't.

For sensitive shares, encryption can be enabled per-share by placing smb encrypt = required in the share section — flexible, without forcing the whole server.

#Server Signing

Signing guarantees packets aren't tampered with in transit (mitigating man-in-the-middle and SMB relay). In SMB3, signing is cheaper than in SMB1:

[global]
   server signing = required

server signing = required forces all connections to be signed. There's a small CPU cost, but for modern production this is a price worth paying — we cover the full trade-offs in episode 14.

#Oplocks: The Engine Behind Speed

#The Oplock Concept

Imagine reading a file from a server over the network: without an opportunistic lock (oplock), every read must cross the network. With oplocks, the client may cache the file exclusively — if a user opens a file for editing, the file is read once, then opened-read-closed locally without touching the server. Samba grants oplocks on safe connections (not in the middle of conflict-prone shares).

[global]
   kernel oplocks = yes
   posix locking = yes

kernel oplocks = yes hands the oplock decision to the kernel (which knows whether a file is really opened by another process), while posix locking integrates POSIX locking with SMB clients. The effect: frequently opened-closed file access becomes much faster — exactly what users of desktop apps that save documents repeatedly feel.

#When Oplocks Cause Problems

Oplocks are an optimization paid for with the risk of stale caches: two clients can both "believe" they hold a file exclusively. On databases used by many concurrent clients, oplocks can become a source of corruption. For those cases, Samba provides strict locking:

[global]
   strict locking = yes

strict locking = yes forces Samba to actually check every operation against active locks — slower, but far safer for shared database workloads.

#Tuning Large File Transfers

#Sockets and Large Reads

Large file transfers (video editing, backups, VM images) are often bottlenecked by Samba's network and I/O parameters, not disk speed. The most impactful parameters:

[global]
   socket options = TCP_NODELAY
   min receivefile size = 131072
   aio read size = 16384
   aio write size = 16384
   use sendfile = yes

• socket options = TCP_NODELAY: disable the Nagle algorithm — small packets no longer pile up waiting for batching, reducing latency for metadata and small-file access.
• min receivefile size = 131072: files above 128 KB are passed directly via splice in the kernel (zero-copy) — large transfers no longer load the Samba CPU.
• aio read size/aio write size: I/O operations above the threshold are processed asynchronously — multiple clients can write in parallel without blocking each other.
• use sendfile = yes: send data directly from the page cache to the socket without copying to user space — the essence of efficient transfers.

The threshold sizes (131072, 16384) can be tweaked to suit your workload — episode 20 covers advanced tuning and monitoring.

#Verifying Dialects and Features

Make sure connections are really using SMB3.11 with encryption/signing active:

smbstatus -L
smbstatus -b | grep -E "(protocol|encryption|signing)"

The output of smbstatus -b shows per connection: protocol dialect (e.g. SMB3_11), encryption status, and signing. If you still see connections with SMB2_10, check which client is forcing the older version.

#Common Pitfalls

• smb encrypt = required but clients refuse: some legacy NAS/STB devices don't support SMB3 encryption — prepare a downgrade path or a dedicated share.
• use sendfile problematic on certain filesystems: if there are transfer anomalies (corrupted files when copying), disable use sendfile and re-check — some niche cases have problems with it.
• socket options disrupts VPN/tunnels: TCP_NODELAY can add overhead on high-latency links — measure on the actual network.
• strict locking slows all shares: apply it per-share, not in [global].

#Closing

Key takeaways:

• server min protocol = SMB3 ensures all clients use a modern dialect.
• SMB3 encryption (smb encrypt = required) and signing (server signing = required) secure the payload on the wire.
• Oplocks speed up file access via client caching; strict locking trades speed for shared-data consistency.
• Large transfer tuning: min receivefile size, aio read/write size, use sendfile, socket options = TCP_NODELAY.
• Verify with smbstatus — don't trust the config, look at the connection facts.

In episode 9 next, we enter a new world: Samba as a Domain Controller (AD DC) — samba-tool domain provision, integrated DNS/DHCP, AD replication, and the real-world case of replacing a Windows Server DC at small-to-medium scale. This is where Samba shows its most ambitious capabilities!