Server Message Block (SMB) is a communication protocol used to share files, printers, serial ports, and miscellaneous communications between nodes on a network. On Windows, the SMB implementation consists of two vaguely named Windows services: "Server" (ID: LanmanServer) and "Workstation" (ID: LanmanWorkstation). It uses NTLM or Kerberos protocols for user authentication. It also provides an authenticated inter-process communication (IPC) mechanism.

SMB was originally developed in 1983 by Barry A. Feigenbaum at IBM to share access to files and printers across a network of systems running IBM PC DOS. In 1987, Microsoft and 3Com implemented SMB in LAN Manager for OS/2, at which time SMB used the NetBIOS service atop the NetBIOS Frames protocol as its underlying transport. Later, Microsoft implemented SMB in Windows NT 3.1 and has been updating it ever since, adapting it to work with newer underlying transports: TCP/IP and NetBT. SMB over QUIC was introduced in Windows Server 2022.

In 1996, Microsoft published a version of SMB 1.0 with minor modifications under the Common Internet File System (CIFS ) moniker. CIFS was compatible with even the earliest incarnation of SMB, including LAN Manager's. It supports symbolic links, hard links, and larger file size, but none of the features of SMB 2.0 and later. Microsoft's proposal, however, remained an Internet Draft and never achieved standard status. Microsoft has since discontinued the CIFS moniker but continues developing SMB and publishing subsequent specifications. Samba is a free software reimplementation of the SMB protocol and the Microsoft extensions to it.

Features Server Message Block (SMB) enables file sharing, printer sharing, network browsing, and inter-process communication (through named pipes) over a computer network. SMB serves as the basis for Microsoft's Distributed File System implementation.

SMB relies on the TCP and IP protocols for transport. This combination allows file sharing over complex, interconnected networks, including the public Internet. The SMB server component uses TCP port 445. SMB originally operated on NetBIOS over IEEE 802.2 - NetBIOS Frames or NBF - and over IPX/SPX, and later on NetBIOS over TCP/IP (NetBT), but Microsoft has since deprecated these protocols. On NetBT, the server component uses three TCP or UDP ports: 137 (NETBIOS Name Service), 138 (NETBIOS Datagram Service), and 139 (NETBIOS Session Service).

In Microsoft Windows, two Windows services implement SMB. The "Server" service (ID: LanmanServer) is in charge of serving shared resources. The "Workstation" service (ID: LanmanWorkstation) maintains the computer name and helps access shared resources on other computers. SMB uses the Kerberos protocol to authenticate users against Active Directory on Windows domain networks. On simpler, peer-to-peer networks, SMB uses the NTLM protocol. Since Windows 11 version 24H2, insecure guest logins (for example shares set to 'Everyone') are no longer allowed for shared folders over SMB. Folder shares must be password-protected with common user account authentication and shared to specific users.

Windows NT 4.0 SP3 and later can digitally sign SMB messages to prevent some man-in-the-middle attacks. SMB signing may be configured individually for incoming SMB connections (by the "LanmanServer" service) and outgoing SMB connections (by the "LanmanWorkstation" service). The default setting for Windows domain controllers running Windows Server 2003 and later is to not allow unsigned incoming connections. As such, earlier versions of Windows that do not support SMB signing from the get-go (including Windows 9x) cannot connect to a Windows Server 2003 domain controller.

SMB supports opportunistic locking (see below) on files in order to improve performance. Opportunistic locking support has changed with each Windows Server release.

Opportunistic locking In the SMB protocol, opportunistic locking is a mechanism designed to improve performance by controlling caching of network files by the client. Unlike traditional locks, opportunistic lock (OpLocks) are not strictly file locking or used to provide mutual exclusion.

There are four types of opportunistic locks.

Batch Locks Batch OpLocks were created originally to support a particular behavior of DOS batch file execution operation in which the file is opened and closed many times in a short period, which is a performance problem. To solve this, a client may ask for an OpLock of type "batch". In this case, the client delays sending the close request and if a subsequent open request is given, the two requests cancel each other. Level-1 OpLocks / Exclusive Locks When an application opens in "shared mode" a file hosted on an SMB server which is not opened by any other process (or other clients) the client receives an exclusive OpLock from the server. This means that the client may now assume that it is the only process with access to this particular file, and the client may now cache all changes to the file before committing it to the server. This is a performance improvement, since fewer round-trips are required in order to read and write to the file. If another client/process tries to open the same file, the server sends a message to the client (called a break or revocation) which invalidates the exclusive lock previously given to the client. The client then flushes all changes to the file. Level-2 OpLocks If an exclusive OpLock is held by a client and a locked file is opened by a third party, the client has to relinquish its exclusive OpLock to allow the other client's write/read access. A client may then receive a "Level 2 OpLock" from the server. A Level 2 OpLock allows the caching of read requests but excludes write caching. Filter OpLocks Added in Windows NT 4.0, Filter Oplocks are similar to Level 2 OpLocks but prevent sharing-mode violations between file open and lock reception. Microsoft advises use of Filter OpLocks only where it is important to allow multiple readers and Level 2 OpLocks in other circumstances. Clients holding an OpLock do not really hold a lock on the file, instead they are notified via a break when another client wants to access the file in a way inconsistent with their lock. The other client's request is held up while the break is being processed. Breaks In contrast with the SMB protocol's "standard" behavior, a break request may be sent from server to client. It informs the client that an OpLock is no longer valid. This happens, for example, when another client wishes to open a file in a way that invalidates the OpLock. The first client is then sent an OpLock break and required to send all its local changes (in case of batch or exclusive OpLocks), if any, and acknowledge the OpLock break. Upon this acknowledgment the server can reply to the second client in a consistent manner.

Performance The use of the SMB protocol has often correlated with a significant increase in broadcast traffic on a network. However the SMB itself does not use broadcasts—the broadcast problems commonly associated with SMB actually originate with the NetBIOS service location protocol. By default, a Microsoft Windows NT 4.0 server used NetBIOS to advertise and locate services. NetBIOS functions by broadcasting services available on a particular host at regular intervals. While this usually makes for an acceptable default in a network with a smaller number of hosts, increased broadcast traffic can cause problems as the number of hosts on the network increases. The implementation of name resolution infrastructure in the form of Windows Internet Naming Service (WINS) or Domain Name System (DNS) resolves this problem. WINS was a proprietary implementation used with Windows NT 4.0 networks, but brought about its own issues and complexities in the design and maintenance of a Microsoft network.

Since the release of Windows 2000, the use of WINS for name resolution has been deprecated by Microsoft, with hierarchical Dynamic DNS now configured as the default name resolution protocol for all Windows operating systems. Resolution of (short) NetBIOS names by DNS requires that a DNS client expand short names, usually by appending a connection-specific DNS suffix to its DNS lookup queries. WINS can still be configured on clients as a secondary name resolution protocol for interoperability with legacy Windows environments and applications. Further, Microsoft DNS servers can forward name resolution requests to legacy WINS servers in order to support name resolution integration with legacy (pre-Windows 2000) environments that do not support DNS.

Network designers have found that latency has a significant impact on the performance of the SMB 1.0 protocol, that it performs more poorly than other protocols like FTP. Monitoring reveals a high degree of "chattiness" and a disregard of network latency between hosts. For example, a VPN connection over the Internet will often introduce network latency. Microsoft has explained that performance issues come about primarily because SMB 1.0 is a block-level rather than a streaming protocol, that was originally designed for small LANs; it has a block size that is limited to 64K, SMB signing creates an additional overhead and the TCP window size is not optimized for WAN links. Solutions to this problem include the updated SMB 2.0 protocol, Offline Files, TCP window scaling and WAN optimization devices from various network vendors that cache and optimize SMB 1.0 and 2.0.

History

SMB 1.0 Barry Feigenbaum originally designed SMB at IBM in early 1983 with the aim of turning DOS INT 21h local file access into a networked file system. Microsoft made considerable modifications to the most commonly used version and included SMB support in the LAN Manager operating system it had started developing for OS/2 with 3Com around 1990. Microsoft continued to add features to the protocol in Windows for Workgroups () and in later versions of Windows. LAN Manager authentication was implemented based on the original legacy SMB specification's requirement to use IBM "LAN Manager" passwords, but implemented DES in a flawed manner that allowed passwords to be cracked. Later, Kerberos authentication was also added. The Windows domain logon protocols initially used 40-bit encryption outside of the United States, because of export restrictions on stronger 128-bit encryption (subsequently lifted in 1996 when President Bill Clinton signed ).

SMB 1.0 (or SMB1) was originally designed to run on NetBIOS Frames (NetBIOS over IEEE 802.2). Since then, it has been adapted to NetBIOS over IPX/SPX (NBX), and NetBIOS over TCP/IP (NetBT). Also, since Windows 2000, SMB runs on TCP using TCP port 445, a feature known as "direct host SMB". There is still a thin layer (similar to the Session Message packet of NetBT's Session Service) between SMB and TCP. Windows Server 2003, and legacy NAS devices use SMB1 natively.

SMB1 is an extremely chatty protocol, which is not such an issue on a local area network (LAN) with low latency. It becomes very slow on wide area networks (WAN) as the back and forth handshake of the protocol magnifies the inherent high latency of such a network. Later versions of the protocol reduced the high number of handshake exchanges. One approach to mitigating the inefficiencies in the protocol is to use WAN optimization products such as those provided by Riverbed, Silver Peak, or Cisco. A better approach is to upgrade to a later version of SMB. This includes upgrading both NAS devices as well as Windows Server 2003. The most effective method to identify SMB1 traffic is with a network analyzer tool, such as Wireshark. Microsoft also provides an auditing tool in Windows Server 2016 to track down devices that use SMB1.

Microsoft marked SMB1 as deprecated in June 2013. Windows Server 2016 and Windows 10 version 1709 do not have SMB1 installed by default.

CIFS