What Is SMB? The Windows File-Sharing Protocol, SMB1 and NFS Compared

Every mapped drive, every scan-to-folder copier and every Hyper-V share in a Windows office runs on the same protocol, and a good share of the tickets about them trace back to how it was configured. The protocol has had five major versions, a 2017 ransomware worm named after its oldest one, and a round of new defaults in Windows 11 24H2 that cut off devices which can't sign. The SMB meaning that matters for IT is the file-sharing protocol, not the small-business acronym, and this guide covers how it works, which version you're running, why SMB1 has to go, and where NFS fits beside it.

TL;DR

• SMB (Server Message Block) is the protocol Windows uses to read and write files, printers and named pipes over a network. A UNC path like \\server\share is an SMB connection on TCP port 445.
• Windows negotiates the highest dialect both sides support, from SMB 2.0.2 up to SMB 3.1.1. Only 3.x gives you encryption, and only 3.1.1 blocks a downgrade to 2.x.
• SMB1 was deprecated in 2014 and hasn't been installed by default since Windows 10 version 1709. It carried the hole WannaCry used in 2017. Remove it, then fix whatever still needed it.
• Windows 11 24H2 and Windows Server 2025 changed the defaults: signing required, NTLM blockable, guest logons off in Pro, a two-second delay on failed logons, and a way to set a minimum dialect.
• NFS is the Unix-side equivalent on port 2049. Windows Server can serve both from one folder; pick by client, not by preference.

What SMB Means in Networking

Server Message Block is a network file-sharing protocol. Microsoft's own definition is plain: SMB lets an application, or the person using it, read, create and update files on a remote server over TCP/IP. The same protocol carries printer queues and named pipes, which is why a print server and a file server speak the same language.

The acronym collides with "small and medium business," and search engines mix the two. If a vendor page says "SMB security," read the next sentence before deciding which one it means. In Microsoft documentation, networking forums and this guide, SMB is the protocol.

SMB started at IBM in the 1980s and Microsoft built its networking on it from the LAN Manager era onward. The name CIFS (Common Internet File System) was Microsoft's 1990s branding for SMB1, which is why old NAS menus still offer "CIFS" as a tickbox. CIFS and SMB1 are the same thing, and both are the version this guide tells you to remove.

Two roles exist in every SMB conversation. The SMB server is whatever shares the resource and answers requests. The SMB client is whatever connects and asks. Both Windows Server and Windows 11 include both, so a laptop can host a share for a colleague while pulling files from a server. The roles describe the protocol, not the Windows edition.

What SMB does not do is as useful to know. It doesn't encrypt your disk; that's BitLocker's job, and Microsoft says so on the encryption page. It doesn't replace a VPN on its own, although SMB over QUIC gets close. And it doesn't decide who may open a file; share permissions and NTFS permissions do that, and SMB carries the identity that those permissions check against. If you're sorting out the file system side, our guide to FAT32 vs NTFS covers which permissions exist on which disks.

If you would rather watch than read, Tech Gee's short explainer covers the same ground:

How an SMB Connection Works

Type \\fileserver\finance into Explorer and five things happen before you see a folder listing.

First, the client resolves the name and opens TCP port 445 to the server. Port 445 is SMB's direct-over-TCP port, and it's the one you'll see in firewall rules and in every port scanner's output. Older setups also used NetBIOS over TCP on port 139 for the same job.

Second, the two sides negotiate a dialect. The client lists the versions it speaks, the server picks the highest one both support, and from that point the connection has a fixed feature set. A Windows 11 client talking to a Windows Server 2022 box lands on SMB 3.1.1; the same client talking to a 2012-era NAS might land on SMB 2.1 with no encryption available.

Third, session setup authenticates the user. On a domain this is Kerberos, which issues a ticket for the server. Fall back cases, including connecting by IP address or to a workgroup device, use NTLM, which is weaker and which Microsoft now lets you block. The session key that comes out of this step is what signing and encryption build on, so a weak password weakens both. Our post on the most common passwords shows what "weak" looks like in practice.

Fourth, tree connect attaches the session to one share. Fifth, the file operations start: open, read, write, lock, close. SMB 2 and later also hand out leases, which let the client cache a file locally and get told when someone else touches it.

That's the whole protocol as an administrator meets it. Every setting discussed below changes one of those five steps: which port, which dialect, which authentication, which share, and whether the messages on the wire are signed or encrypted.

SMB Versions and What Each One Added

Dialect is the protocol's word for version, and the version decides what the connection can do. Microsoft's table maps the 3.x dialects to the Windows release that introduced them. The earlier rows are general history.

Two things on this table are worth a pause. The first is that every supported Windows release since 2016 speaks SMB 3.1.1, so when a connection lands on a lower dialect, the other end is the reason: a NAS, a printer, a Linux box with an old Samba, or a Windows machine someone pinned on purpose. Microsoft notes that the dialect number stayed at 3.1.1 while features kept arriving; Windows Server 2022 and Windows 11 added AES-256-GCM encryption and AES-128-GMAC signing acceleration without a new dialect.

The second is what 3.1.1 brought. Pre-authentication integrity means the client and server hash every message exchanged before authentication, so an attacker in the middle can't quietly strip features from the negotiation and push the connection down to an older, weaker dialect. Microsoft is specific about the limit, though: it prevents a downgrade from 3.1.1 to 2.x, and it does not prevent a downgrade to SMB1. That single sentence is the strongest argument for the next section.

You can see which dialect each live connection uses with one command on the client:

powershell
Get-SmbConnection | Select-Object ServerName, ShareName, Dialect, Encrypted, Signed

Anything that comes back below 3.0 can't be encrypted. Anything that comes back as 1.x shouldn't exist.

Why SMB1 Has to Go

Microsoft deprecated SMB1 in 2014 and stopped installing it by default with Windows 10 version 1709 in 2017. Windows 11 ships with neither the SMB1 client nor the SMB1 server after a clean install. In Windows 10 Home and Pro, an unused SMB1 client uninstalls itself after 15 days of non-use, once. Reinstall it by hand and Windows won't try again.

The reasons are structural, not cosmetic. Ned Pyle, who owned SMB at Microsoft, laid them out in 2016 in a post titled "Stop using SMB1," and they still hold:

• SMB1 has no pre-authentication integrity, no encryption and only MD5-based signing. The features that make 2.x and 3.x safe don't exist in it.
• Because 3.1.1's downgrade protection stops at 2.x, a client that still speaks SMB1 can be talked down to it by whoever sits between it and the server. Everything you hardened above that line is bypassed.
• It's slow. Larger reads and writes arrived in 2.0.2; SMB1 chats in small packets that hurt on any link with latency.

Then there's the worm. On March 14, 2017, Microsoft published security bulletin MS17-010, fixing remote code execution flaws in how the SMBv1 server handled crafted requests. Two months later WannaCry used exactly that path to spread between unpatched machines. If you want the timeline of how one infected PC becomes a whole network, our post on how ransomware moves walks through it hour by hour. The protocol it rode was SMB1.

Checking is quick. On any Windows machine:

powershell
Get-WindowsOptionalFeature -Online -FeatureName SMB1Protocol | Select-Object State
Get-SmbServerConfiguration | Format-List EnableSMB1Protocol

Removing it is two commands, and the second one is the one that matters on a server:

powershell
Disable-WindowsOptionalFeature -Online -FeatureName SMB1Protocol -NoRestart
Set-SmbServerConfiguration -EnableSMB1Protocol $false

Something will break, and Windows tells you what. When a client without SMB1 hits a server that only speaks it, you get "You can't connect to the file share because it's not secure. This share requires the obsolete SMB1 protocol," or the older System Error 64, and the client logs event 32000 in the SMBClient Security log naming the server. When the SMB1 client is still installed and gets used, event 32002 fires instead, which is how you build the list of devices to fix before you pull the feature.

Microsoft's own description of those devices: they aren't likely running Windows. They're old Linux builds, old Samba, a copier from a previous decade, a lab instrument or an NVR. Microsoft keeps an SMB1 Product Clearinghouse listing vendors and the firmware versions that moved to SMB2, and it names two workarounds for the stragglers. One is a share-level leasing mode (Set-SmbShare -LeasingMode None) for legacy applications that choke on oplocks. The other is reinstalling SMB1, which Microsoft's page strongly recommends against. Treat the clearinghouse as the first stop and the reinstall as a dated exception with a replacement budget attached.

A thread on r/synology asks how bad it is to switch SMB1 back on for a NAS, which is the question a device owner meets first:

Signing, Encryption and the 24H2 Defaults

SMB signing puts a keyed hash of every message in the SMB header, computed from the session key. Change a byte in transit and the hash no longer matches, so the receiver drops it. The hash also binds the sender's and receiver's identities, which is what breaks relay attacks, where an attacker takes your authentication and replays it against a different server.

For twenty years signing existed but was mostly off. Windows only required it when a client connected to a domain controller or to the SYSVOL and NETLOGON shares. That changed in 2024. Microsoft's Control SMB signing page states the current defaults: Windows 11 24H2 Enterprise, Pro and Education require signing on both outbound and inbound connections; Windows Server 2025 requires it on outbound only; Windows 11 Home requires neither. In Ned Pyle's August 2024 write-up of the change, the point was that an admin now has to opt out of the safer setting rather than know enough to opt in.

Encryption is the other half, and it's a 3.x feature. SMB 3.0 introduced it, SMB 3.1.1 negotiates AES-128-GCM by default, and Windows Server 2022 and Windows 11 added AES-256-GCM and AES-256-CCM, which Group Policy can mandate. You turn it on per share or for the whole server:

powershell
Set-SmbShare -Name Finance -EncryptData $true
Set-SmbServerConfiguration -EncryptData $true

When encryption is on, the server rejects SMB 2.x and SMB1 clients by default, because they can't encrypt. Microsoft's page documents the -RejectUnencryptedAccess $false escape hatch for mixed fleets and then says not to use it; update the clients instead. An encrypted share is also signed, regardless of the signing policy, so you don't configure both.

Both features cost CPU. Microsoft calls it a "notable performance operating cost" for end-to-end encryption and won't put a number on signing because it depends on the cores you have and what else they're doing. On a file server built in the last five years the cost is rarely visible to users. On a budget NAS it can be.

The 24H2 and Server 2025 wave brought more than signing. Each item below is on Microsoft's SMB security hardening list from August 2024, and each one has a page of its own on Microsoft Learn:

The guest-logon change is the one behind the support calls. A consumer NAS or a scanner that shares a folder with no password relies on guest fallback, and 24H2 Pro no longer offers it. Microsoft's guest-logon page notes the knock-on: signing is now required by default, and guest sessions can't sign, so the connection fails even where guest access is re-enabled. The fix is a real account on the device, not a registry key on the client.

The dialect control is the quiet win. Since 24H2 and Server 2025 you can mandate Set-SmbClientConfiguration -Smb2DialectMin SMB300 on the client side, after which nothing below 3.0 negotiates and encryption is available everywhere by construction. Pair it with the audit events for a month first so the printer in accounting shows up in a log before it shows up as a ticket; our guide to log management covers how to collect those events centrally.

An r/sysadmin thread asks how to evaluate SMB signing before enforcing it, with auditing tools or a packet capture. The audit events in the table above are the Windows-side answer:

SMB Over QUIC: The Internet Version

SMB over QUIC swaps the TCP transport for QUIC, the UDP-based protocol behind HTTP/3, and wraps the whole thing in a TLS 1.3 tunnel on UDP port 443. The practical effect is a file share you can reach from a coffee shop without a VPN, and without opening port 445 to the internet, which should never be reachable from the internet.

Microsoft's SMB over QUIC page sets the boundaries. The file server must opt in; a client can't force it. Supported servers are any edition of Windows Server 2025 and Windows Server 2022 Datacenter: Azure Edition. Clients are Windows 11 business editions. A Windows client still tries TCP first and only falls to QUIC when TCP fails, unless you require it with NET USE /TRANSPORT:QUIC or New-SmbMapping -TransportType QUIC. The server needs a certificate with the Server Authentication purpose, issued by a CA the clients trust, and Microsoft says not to put IP addresses in its Subject Alternative Names.

It's the right tool for one job: a small fleet of remote laptops that need a specific file share, where a VPN would be bigger than the problem. It doesn't change the rest of this guide. Signing, encryption and dialect rules apply inside the tunnel exactly as they do on the LAN. If you're deciding how remote staff should reach internal resources more broadly, our playbook on IT support for remote workers sets QUIC beside the alternatives.

SMB vs NFS

NFS is the other file-sharing protocol you'll meet, and the choice between them is about clients, not quality. Sun Microsystems created NFS in 1984 for Unix systems; the IETF took over the standard with NFSv4. Linux, macOS, VMware and most storage appliances speak it natively. Windows speaks it only when you install the role.

The authentication row decides more deployments than the rest of the table combined. NFS with AUTH_SYS trusts the client's numeric user and group IDs, which is fine on a locked-down storage network between two servers and a bad idea on an office LAN where anyone with a laptop can present UID 0. Kerberos fixes that, and Windows Server for NFS supports krb5, krb5i and krb5p, but it has to be set up on both ends and most small shops don't.

Windows Server can share one folder over both protocols at once. Microsoft's NFS overview lists multi-protocol sharing as the first scenario: the same directory reached by Windows users over SMB and by Linux hosts over NFS, with identity mapping between Windows SIDs and Unix UIDs handled in Active Directory, AD LDS or a flat file. The catch is permissions. SMB users get NTFS ACLs; NFS users get mode bits mapped onto them, and anything subtle in the ACL gets lost in translation.

The short rule: Windows clients get SMB, Linux and hypervisor hosts get NFS, a mixed office gets SMB for people and NFS for machines, and a share that holds anything sensitive gets Kerberos on whichever protocol it uses.

Securing SMB on a Small Network: The Checklist

Everything above collapses into ten settings. Each has a Microsoft page behind it and a one-line check.

Step 2 is the one that's easy to skip because nothing visibly breaks. Port 445 has no business being reachable from the internet, and a stateful firewall rule blocking it costs nothing. If a vendor asks you to forward 445 for a remote office, the answer is QUIC or a VPN; our post on port forwarding explains why that one request should always be refused.

Steps 7 and 8 belong together. Set the audit first, wait for the quiet week to pass, read the SMBClient and SMBServer audit logs, fix or replace what shows up, then raise the minimum dialect. Done in that order, the change is a non-event. Done in the other order, it's a Monday.

Across a fleet, the checks in the table are a script. OpenFrame can run Get-SmbServerConfiguration and Get-SmbConnection across a client's devices and collect the output, so the SMB1 holdouts and the sub-3.0 connections land in one list instead of one ticket at a time. If you'd rather build that script yourself, our collection of useful PowerShell commands has the inventory pattern to start from.

SMB, in Short

SMB is the protocol under every Windows file share, every mapped drive and a good share of your tickets. The version that matters is the dialect each connection lands on: 3.1.1 everywhere on supported Windows, something older wherever a device drags it down. SMB1 is the one that must go, because it carries the hole WannaCry used and because it lets an attacker in the middle undo every other protection. The 2024 defaults made signing automatic and gave you dialect control, NTLM blocking and audit events to find the stragglers first. NFS is the right answer for Linux and hypervisor hosts, SMB for people on Windows and Macs, and Kerberos for anything sensitive on either.

Start with the SMB1 check, then the audit events. The rest of the checklist follows from what they find.

Related reading: BitLocker for IT teams for the encryption SMB doesn't do, what WinRM is for the other protocol living on your file servers, and IT infrastructure monitoring for keeping an eye on the servers that host the shares.