Server Message Block

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.[9] Microsoft has made considerable modifications to the most commonly used version. Microsoft merged the SMB protocol with the LAN Manager product which it had started developing for OS/2 with 3Com around 1990, and continued to add features to the protocol in Windows for Workgroups (c. 1992) and in later versions of Windows.

SMB was originally designed to run on top of the NetBIOS/NetBEUI API (typically implemented with NBF, NetBIOS over IPX/SPX, or NBT). Since Windows 2000, SMB runs, by default, with a thin layer, similar to the Session Message packet of NBT's Session Service, on top of TCP, using TCP port 445 rather than TCP port 139—a feature known as "direct host SMB".[10]

Windows Server 2003, and older NAS devices use SMB1/CIFS natively. SMB1/CIFS is an extremely chatty protocol which is not such an issue on a local area network with low latency but becomes very slow on wide area networks as the back and forth handshake of the protocol magnifies the inherent high latency of such network. Later versions of the protocol reduced the high number of handshake exchanges. While Microsoft estimates that SMB1/CIFS comprises less than 10% of network traffic in the average Enterprise network, that is still a significant amount of traffic. One approach to mitigating the inefficiencies in the protocol is to use WAN Acceleration products such as those provided by Riverbed, Silver Peak, or Cisco Systems. A better approach is simply to eliminate SMB1/CIFS by upgrading the server infrastructure that uses it. This includes both NAS devices as well as Windows Server 2003. The most effective method in use currently to identify SMB1/CIFS traffic is to use a network analyzer tool such as Wireshark, etc., to identify SMB1/CIFS "talkers" and then decommission or upgrade them over time. Microsoft also provides an auditing tool in Windows Server 2016, which can be used to track down SMB1/CIFS talkers.[11]

In 1996, when Sun Microsystems announced WebNFS,[12] Microsoft launched an initiative to rename SMB to Common Internet File System (CIFS)[9] and added more features, including support for symbolic links, hard links, larger file sizes, and an initial attempt at supporting direct connections over TCP port 445 without requiring NetBIOS as a transport (a largely experimental effort that required further refinement). Microsoft submitted some partial specifications as Internet-Drafts to the IETF,[13] though these submissions have expired.

Microsoft "added SMB1 to the Windows Server 2012 R2 deprecation list in June 2013."[14] Windows Server 2016 and some versions of Windows 10 Fall Creators Update do not have SMB1 installed by default.[15]

Microsoft introduced a new version of the protocol (SMB 2.0 or SMB2) with Windows Vista in 2006[16] and Server 2008. Although the protocol is proprietary, its specification has been published to allow other systems to interoperate with Microsoft operating systems that use the new protocol.[17]

SMB2 reduces the 'chattiness' of the SMB 1.0 protocol by reducing the number of commands and subcommands from over a hundred to just nineteen.[18] It has mechanisms for pipelining, that is, sending additional requests before the response to a previous request arrives, thereby improving performance over high latency links. It adds the ability to compound multiple actions into a single request, which significantly reduces the number of round-trips the client needs to make to the server, improving performance as a result.[18] SMB1 also has a compounding mechanism—known as AndX—to compound multiple actions, but Microsoft clients rarely use AndX. It also introduces the notion of "durable file handles": these allow a connection to an SMB server to survive brief network outages, as are typical in a wireless network, without having to incur the overhead of re-negotiating a new session.

SMB2 includes support for symbolic links. Other improvements include caching of file properties, improved message signing with HMAC SHA-256 hashing algorithm and better scalability by increasing the number of users, shares and open files per server among others.[18] The SMB1 protocol uses 16-bit data sizes, which amongst other things, limits the maximum block size to 64K. SMB2 uses 32 or 64-bit wide storage fields, and 128 bits in the case of file-handles, thereby removing previous constraints on block sizes, which improves performance with large file transfers over fast networks.[18]

Windows Vista/Server 2008 and later operating systems use SMB2 when communicating with other machines also capable of using SMB2. SMB1 continues in use for connections with older versions of Windows, as well various vendors' NAS solutions. Samba 3.5 also includes experimental support for SMB2.[19] Samba 3.6 fully supports SMB2, except the modification of user quotas using the Windows quota management tools.[20]

When SMB2 was introduced it brought a number of benefits over SMB1 for third party implementers of SMB protocols. SMB1, originally designed by IBM, was reverse engineered, and later became part of a wide variety of non-Windows operating systems such as Xenix, OS/2 and VMS (Pathworks). X/Open standardized it partially; it also had draft IETF standards which lapsed. (See http://ubiqx.org/cifs/Intro.html for historical detail.) SMB2 is also a relatively clean break with the past. Microsoft's SMB1 code has to work with a large variety of SMB clients and servers. SMB1 features many versions of information for commands (selecting what structure to return for a particular request) because features such as Unicode support were retro-fitted at a later date. SMB2 involves significantly reduced compatibility-testing for implementers of the protocol. SMB2 code has considerably less complexity since far less variability exists (for example, non-Unicode code paths become redundant as SMB2 requires Unicode support).

Apple is also migrating to SMB2 (from their own Apple Filing Protocol, now legacy) with OS X 10.9.[21] This transition was fraught with compatibility problems though.[22][23] Non-default support for SMB2 appeared in fact in OS X 10.7, when Apple abandoned Samba in favor of its own SMB implementation called SMBX.[21] Apple switched to its own SMBX implementation after Samba adopted GPLv3.[24][25]

The Linux kernel's CIFS client file system has SMB2 support since version 3.7.[26]

SMB 2.1, introduced with Windows 7 and Server 2008 R2, introduced minor performance enhancements with a new opportunistic locking mechanism.[27]

SMB 3.0 (previously named SMB 2.2)[28] was introduced with Windows 8[28] and Windows Server 2012.[28] It brought several significant changes that are intended to add functionality and improve SMB2 performance,[29] notably in virtualized data centers:

• the SMB Direct Protocol (SMB over remote direct memory access [RDMA])
• SMB Multichannel (multiple connections per SMB session),[30][31]
• SMB Transparent Failover[32][33]

It also introduces several security enhancements, such as end-to-end encryption and a new AES based signing algorithm.[34][35]

SMB 3.0.2 (known as 3.02 at the time) was introduced with Windows 8.1 and Windows Server 2012 R2;[36][37] in those and later releases, the earlier SMB version 1 can be optionally disabled to increase security.[38][39]

SMB 3.1.1 was introduced with Windows 10 and Windows Server 2016.[40] This version supports AES-128 GCM encryption in addition to AES-128 CCM encryption added in SMB3, and implements pre-authentication integrity check using SHA-512 hash. SMB 3.1.1 also makes secure negotiation mandatory when connecting to clients using SMB 2.x and higher.

SMB works through a client-server approach, where a client makes specific requests and the server responds accordingly. One section of the SMB protocol specifically deals with access to filesystems, such that clients may make requests to a file server; but some other sections of the SMB protocol specialize in inter-process communication (IPC). The Inter-Process Communication (IPC) share, or ipc$, is a network share on computers running Microsoft Windows. This virtual share is used to facilitate communication between processes and computers over SMB, often to exchange data between computers that have been authenticated.

Developers have optimized the SMB protocol for local subnet usage, but users have also put SMB to work to access different subnets across the Internet—exploits involving file-sharing or print-sharing in MS Windows environments usually focus on such usage.

SMB servers make their file systems and other resources available to clients on the network. Client computers may want access to the shared file systems and printers on the server, and in this primary functionality SMB has become best-known and most heavily used. However, the SMB file-server aspect would count for little without the NT domains suite of protocols, which provide NT-style domain-based authentication at the very least. Almost all implementations of SMB servers use NT Domain authentication to validate user-access to resources.

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.[18] 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.[41] Solutions to this problem include the updated SMB 2.0 protocol,[42] Offline Files, TCP window scaling and WAN acceleration devices from various network vendors that cache and optimize SMB 1.0[43] and 2.0.[44]

Microsoft added several extensions to its own SMB implementation. For example, it added NTLM, followed by NTLMv2 authentication protocols, in order to address security weakness in the original LAN Manager authentication. 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.[45] Later, Kerberos authentication was also added. The NT 4.0 Domain logon protocols initially used 40-bit encryption outside of the United States, because of export restrictions on stronger 128-bit encryption[46] (subsequently lifted in 1996 when President Bill Clinton signed Executive Order 13026[47]). Opportunistic locking support has changed with each server release.

In 1991 Andrew Tridgell started the development of Samba, a free-software re-implementation (using reverse engineering) of the SMB/CIFS networking protocol for Unix-like systems, initially to implement an SMB server to allow PC clients running the DEC Pathworks client to access files on SunOS machines.[9][48] Because of the importance of the SMB protocol in interacting with the widespread Microsoft Windows platform, Samba became a popular free software implementation of a compatible SMB client and server to allow non-Windows operating systems, such as Unix-like operating systems, to interoperate with Windows.

As of version 3 (2003), Samba provides file and print services for Microsoft Windows clients and can integrate with a Windows NT 4.0 server domain, either as a Primary Domain Controller (PDC) or as a domain member. Samba4 installations can act as an Active Directory domain controller or member server, at Windows 2008 domain and forest functional levels.[49]

Package managers in Linux distributions can search for the cifs-utils package. The package is from the Samba maintainers.

NSMB (Netsmb and SMBFS) is a family of in-kernel SMB client and server implementations in BSD operating systems. It was first contributed to FreeBSD 4.4 by Boris Popov, and is now found in a wide range of other BSD systems including NetBSD and macOS.[50] The implementations have diverged significantly ever since.[51]

The macOS version of NSMB is notable for its now-common scheme of representing symlinks. This "Minshall-French" format shows symlinks as textual files with a .symlink extension and a Xsym\n magic number, always 1067 bytes long. This format is also used for storing symlinks on naive SMB servers or unsupported filesystems. Samba supports this format with an mfsymlink option.[52] Docker on Windows also seems to use it.

NQ is a family of portable SMB client and server implementations developed by Visuality Systems, an Israel-based company established in 1998 by Sam Widerman, formerly the CEO of Siemens Data Communications. The NQ family comprises an embedded SMB stack (written in C), a Pure Java SMB Client, and a storage SMB Server implementation. All solutions support the latest SMB 3.1.1 dialect. NQ for Linux, NQ for WinCE, iOS, Android, VxWorks and other real-time operating systems are all supported by the configurable NQ solution.

MoSMB is a proprietary SMB implementation for Linux and other Unix-like systems, developed by Ryussi Technologies. It supports only SMB 2.x and SMB 3.x.[53]

Tuxera SMB is a proprietary SMB server implementation developed by Tuxera that can be run either in kernel or user space.[54] It supports SMB 3.1.1 and previous versions.

Likewise developed a CIFS/SMB implementation (versions 1.0, 2.0, 2.1 and NFS 3.0) back in 2009 that provided a multiprotocol, identity-aware platform for network access to files used in OEM storage products built on Linux/Unix based devices. The platform could be used for traditional NAS, Cloud Gateway, and Cloud Caching devices for providing secure access to files across a network. Likewise was purchased by EMC Isilon in 2012.

CIFSD is an open source In-kernel CIFS/SMB server implementation for Linux kernel. It has the following advantages over user-space implementations: It provides better performance, and it's easier to implement some features like SMB Direct. It supports SMB 3.1.1 and previous versions.