LiveChat 
Support 
Server Message Block (SMB): How the Protocol Works and How to Run It Safely
If you have ever mapped a network drive on Windows, double-clicked a path like `\\server\share`, or printed to a shared office printer, you have used Server Message Block without thinking about it. SMB is one of the quiet workhorses of computer networking: a protocol that lets machines share files, printers, and other resources across a local network as if those resources were sitting on your own disk.
It is also, when handled carelessly, one of the most dangerous protocols you can run. The same design that makes SMB so convenient on a trusted office LAN makes it catastrophic when exposed to the open internet. This guide explains what SMB is, how it works, which versions matter, how it runs on Linux through Samba, and — most importantly — how to keep it from becoming the entry point for a ransomware outbreak.
Key Takeaways
• Server Message Block (SMB) is a client-server network protocol for sharing files, printers, and resources across a network.
• SMB primarily uses TCP port 445 today; older deployments used port 139 over NetBIOS.
• SMB1 is deprecated and insecure and should be disabled; SMB2 and SMB3 are the modern, encrypted versions.
• On Linux and macOS, Samba provides a compatible SMB implementation.
• Never expose port 445 to the public internet. SMB belongs on a LAN or behind a VPN — this rule alone prevents the EternalBlue/WannaCry class of disaster.
What is Server Message Block?
Server Message Block is a network communication protocol that allows applications and users to read, write, and share files, printers, and other resources over a network. It operates on a client-server model: a client (your laptop, for example) sends requests to a server that hosts a *share* — a folder or device made available to the network.
SMB originated at IBM in the 1980s and was adopted and heavily extended by Microsoft, where it became the foundation of Windows file and printer sharing. Microsoft also marketed an enhanced version under the name CIFS (Common Internet File System), which is why you will still occasionally see “SMB/CIFS” used interchangeably. In practice, CIFS refers to an old SMB1-era dialect, and you should treat “SMB” — specifically SMB2 and SMB3 — as the current reality.
Although it grew up in the Windows world, SMB is genuinely cross-platform. Linux and Unix systems speak it through Samba, macOS includes a native SMB client and server, and most network-attached storage (NAS) devices expose their volumes over SMB.
How does the SMB protocol work?
At its core, SMB is a request-response protocol. The client opens a connection to the server, authenticates, and then issues commands — open this file, read these bytes, lock this record, list this directory, send this print job. The server responds to each request. Because SMB tracks open files and locks, multiple users can work against the same share without corrupting each other’s data.
A typical SMB session involves a few distinct stages:
- Connection. The client establishes a TCP connection to the server, almost always on port 445.
- Negotiation. Client and server agree on the highest SMB dialect they both support (for example, SMB 3.1.1).
- Authentication. The client proves its identity, typically with NTLM or Kerberos in a Windows domain.
- Tree connect. The client connects to a specific share (the “tree”), such as `\\fileserver\accounting`.
- File operations. The client opens, reads, writes, locks, and closes files and directories.
The resource path most people recognize is the UNC path: `\\server\share\folder\file.txt`. That backslash notation is SMB’s address format. When you “map a network drive” to `Z:`, you are simply assigning a drive letter to one of these UNC paths.
Understanding how a client reaches the server here is part of a bigger networking picture — the same DNS, routing, and port concepts covered in our complete guide to networking and DNS for hosting apply directly to how SMB shares are located and connected to.
Which ports does SMB use — 445 or 139?
This trips people up constantly, so let’s be precise.
Modern SMB runs directly over TCP on port 445. Since Windows 2000, SMB has been able to operate over TCP/IP without needing the older NetBIOS layer. Port 445 is the one that matters today.
Historically, SMB ran over NetBIOS, which used ports 137, 138, and 139. Port 139 carried SMB traffic encapsulated in NetBIOS over TCP/IP, while 137 and 138 handled NetBIOS name and datagram services. You will still see these ports on legacy networks, but they are remnants of an older era.
| Port | Protocol | Role | Status |
|---|---|---|---|
| 445 | TCP | SMB directly over TCP/IP | Current standard |
| 139 | TCP | SMB over NetBIOS session service | Legacy |
| 137 | UDP | NetBIOS name service | Legacy |
| 138 | UDP | NetBIOS datagram service | Legacy |
The practical takeaway: if you are securing SMB, port 445 is the one you must control, with 139 a close second on older estates. For more on how individual ports map to services, see the sibling explainer on network ports.
What are the different SMB versions?
SMB has evolved through several major dialects, and the differences are not cosmetic — they affect security, performance, and whether you should be running them at all.
- SMB 1.0 (SMBv1 / CIFS): The original. Deprecated and dangerous. It lacks modern encryption, uses weak authentication, and was the vehicle for the EternalBlue exploit. Microsoft now disables it by default on current Windows versions. Disable it everywhere.
- SMB 2.0 / 2.1: Introduced with Windows Vista and Windows 7. A major redesign that reduced chattiness, improved performance over higher-latency links, and added better handling of large file transfers.
- SMB 3.0 / 3.0.2 / 3.1.1: Introduced with Windows 8 and refined through Windows 10/11 and Windows Server. This is the modern standard. SMB3 adds end-to-end encryption, secure dialect negotiation to prevent downgrade attacks, multichannel support for aggregating bandwidth across NICs, and SMB Direct (RDMA) for high-performance workloads.
The rule of thumb: run SMB 3.1.1 where you can, accept SMB2 where you must, and disable SMB1 entirely. SMB 3.1.1 introduced pre-authentication integrity checks that make man-in-the-middle and downgrade attacks far harder to pull off.
What is SMB used for?
SMB is the backbone of everyday resource sharing. Its most common uses include:
- File shares. Centralized folders on a server (`\\fileserver\projects`) that teams read and write to. This is SMB’s bread and butter.
- Network drives. Mapping a share to a drive letter so it behaves like local storage.
- Printer sharing. Sharing a printer connected to one machine so the whole network can print to it.
- NAS access. Most NAS appliances present their storage over SMB so any client on the LAN can mount it.
- Application data. Some line-of-business and database applications store working files on SMB shares, relying on SMB’s file-locking to coordinate concurrent access.
In short, anywhere people need to treat a remote folder or device as if it were local, SMB is usually the protocol doing the work.
How does SMB work on Linux with Samba?
SMB is not a Windows-only protocol. On Linux, BSD, and Unix systems, the open-source Samba suite implements both the SMB server and client side of the protocol. Samba lets a Linux box act as a file and print server that Windows clients can connect to seamlessly — and lets Linux clients mount Windows or NAS shares.
A Samba server is configured primarily through `smb.conf`, where you define shares, access controls, and which SMB dialects are permitted. On the client side, the `mount.cifs` utility (despite the legacy “cifs” name) mounts a remote SMB share into the Linux filesystem, and the `smbclient` tool provides an FTP-like interactive session for browsing shares.
A critical, often-overlooked configuration point: set a minimum protocol version in `smb.conf` so Samba refuses SMB1 connections. Pinning `server min protocol = SMB2` (or higher) closes off the oldest and most dangerous dialect at the server level. For a deeper walkthrough, see the dedicated guide on setting up Samba file sharing on Linux.
SMB vs FTP vs NFS — which should you use?
SMB is one of several file-access protocols, and choosing the right one depends on your platform and use case. Here is how they compare.
| Protocol | Primary use case | Native platform | Authentication | Best for |
|---|---|---|---|---|
| SMB | File and printer sharing on a LAN | Windows (cross-platform via Samba) | NTLM / Kerberos / user accounts | Office file shares, mapped drives, NAS, printers |
| FTP / SFTP | File transfer over a network or internet | Cross-platform | Username/password; SFTP adds SSH keys | Moving files to/from a server, uploads/downloads |
| NFS | File sharing between Unix/Linux systems | Unix/Linux | Host-based / Kerberos | Linux-to-Linux shared storage, server clusters |
The short version: SMB excels at interactive, multi-user file and printer sharing on a trusted LAN, particularly in mixed or Windows-centric environments. NFS is the natural choice for Unix-to-Unix shared storage. SFTP is what you reach for when you need to move files *across the internet* securely — precisely the scenario where SMB should never be used directly. For a focused comparison, the FTP-vs-SMB explainer covers the trade-offs in detail.
Why is SMB security so critical?
This is the section that matters most, because getting SMB security wrong has caused some of the most damaging cyberattacks in history.
Here is the insight that, once internalized, prevents nearly every SMB disaster: SMB is brilliant on a trusted local network and catastrophic on the open internet. The protocol was designed for LAN file sharing — an environment where every machine is assumed to be trusted, where authentication exists but the network perimeter does the heavy lifting. That assumption falls apart completely the moment port 445 faces the public internet. SMB exposed to the world has been behind some of history’s worst worms and ransomware: the EternalBlue exploit and the WannaCry and NotPetya outbreaks spread exactly this way, hopping from one internet-reachable SMB host to the next with no human interaction. The rule that prevents this is absolute: SMB belongs on a LAN or behind a VPN, never directly internet-facing, and SMB1 should be disabled entirely. If you need file access across the internet, tunnel SMB over a VPN or use a protocol built for the open internet, like SFTP. Never open 445 to the world.
Concretely, a defensible SMB posture comes down to a handful of non-negotiables:
- Disable SMB1 everywhere. It is unauthenticated in dangerous ways and exploitable. There is no modern reason to keep it on.
- Never expose port 445 (or 139) to the public internet. Firewall it off at the network edge. If you can reach a machine’s SMB port from outside, so can attackers and automated worms.
- Use SMB3 encryption. On a network you do not fully control, enable SMB encryption so traffic is protected in transit.
- Patch promptly. EternalBlue exploited a vulnerability that already had a patch available. Systems that fall behind on updates are the ones that get hit.
- Apply least-privilege access. Restrict shares to the users and groups that genuinely need them, and avoid wide-open “Everyone: Full Control” permissions.
- Tunnel remote access through a VPN. If remote staff need a file share, give them a VPN into the LAN rather than exposing the share itself.
A firewall is your single most important SMB control, since it decides whether port 445 is reachable at all. The sibling guide on firewall configuration covers how to lock down ports like this.
How DarazHost keeps risky ports like SMB closed
DarazHost servers are configured with secure-by-default firewalls that keep risky ports like SMB’s port 445 closed to the public internet. That default matters: the most common cause of an SMB compromise is simply having the port exposed, and a sensible firewall baseline removes that risk before it can be exploited.
On VPS and dedicated plans with root access, you control exactly which services and ports are exposed — so you can run Samba safely on a private network or over a VPN, with full command over your `smb.conf` and firewall rules. That means you get the convenience of SMB file sharing for your own trusted environment without ever putting port 445 in front of the public internet. Combined with 24/7 support and secure networking, it lets you operate SMB the way it was meant to be used: on a trusted, controlled network.
Frequently asked questions
What is the difference between SMB and CIFS? CIFS (Common Internet File System) is an older, specific dialect of SMB — essentially SMB1. Modern usage has moved on to SMB2 and SMB3, so when people say “SMB” today they almost always mean these newer, more secure versions. Treat CIFS as legacy.
Is it safe to open port 445 to the internet? No. Exposing port 445 to the public internet is one of the most dangerous configurations in networking. It was the attack vector for the WannaCry and NotPetya ransomware. SMB should only be reachable from a trusted LAN or through a VPN.
Should I disable SMB1? Yes, in essentially all cases. SMB1 is deprecated, insecure, and disabled by default on current Windows versions. Unless you have a specific legacy device that cannot be upgraded, disable SMB1 entirely and use SMB2 or SMB3.
Can Linux machines use SMB? Yes. The Samba project provides a full SMB server and client implementation for Linux and Unix systems. Linux can host SMB shares that Windows clients connect to, and Linux clients can mount Windows or NAS shares using `mount.cifs` or `smbclient`.
What is the difference between SMB and FTP? SMB is built for interactive, multi-user file and printer sharing on a local network, presenting remote folders as if they were local. FTP (and its secure successor SFTP) is built for transferring files across a network or the internet. For internet-facing file transfer, use SFTP — never SMB.
