Editing Server Message Block (section)

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

SMB relies on the [[Transmission Control Protocol|TCP]] and [[Internet Protocol|IP]] protocols for transport. This combination allows file sharing over [[Internetworking|complex, interconnected networks]], including the public Internet. The SMB [[Client–server model|server component]] uses [[Transmission Control Protocol|TCP]] [[Port (computer networking)|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 [[User Datagram Protocol|UDP]] ports: 137 (NETBIOS Name Service), 138 (NETBIOS Datagram Service), and 139 (NETBIOS Session Service).

In Microsoft Windows, two vaguely named [[Windows service]]s implement SMB. The "Server" service (ID: <code>LanmanServer</code>) is in charge of serving [[shared resource]]s. The "Workstation" service (ID: <code>LanmanWorkstation</code>) maintains the computer name and helps access shared resources on other computers.<ref name=":0" /> SMB uses the [[Kerberos (protocol)|Kerberos]] protocol to authenticate users against [[Active Directory]] on [[Windows domain]] networks. On simpler, peer-to-peer networks, SMB uses the [[NTLM]] protocol.

[[Windows NT 4.0|Windows NT 4.0 SP3]] and later can [[Digital signature|digitally sign]] SMB messages to prevent some [[man-in-the-middle attack]]s.<ref>{{cite web|date=24 November 2021|title=Overview of Server Message Block signing|url=https://docs.microsoft.com/en-US/troubleshoot/windows-server/networking/overview-server-message-block-signing|website=Windows Server troubleshooting|publisher=[[Microsoft]]|via=[[Microsoft Docs]]|access-date=29 January 2022|archive-date=29 January 2022|archive-url=https://web.archive.org/web/20220129191652/https://docs.microsoft.com/en-US/troubleshoot/windows-server/networking/overview-server-message-block-signing|url-status=live}}</ref><ref name=":1">{{cite web|author=Johansson|first=Jesper M.|date=20 May 2005|title=How to Shoot Yourself in the Foot with Security, Part 1|url=https://docs.microsoft.com/en-us/previous-versions/tn-archive/cc512612(v=technet.10)|website=Security Guidance|publisher=[[Microsoft]]|via=[[Microsoft Docs]]|quote=This article addresses [...] Server Message Block (SMB) message signing.|access-date=19 October 2018|archive-date=19 October 2018|archive-url=https://web.archive.org/web/20181019041254/https://docs.microsoft.com/en-us/previous-versions/tn-archive/cc512612(v=technet.10)|url-status=live}}</ref><ref>{{cite web|author=Barreto|first=Jose|date=1 December 2010|title=The Basics of SMB Signing (covering both SMB1 and SMB2)|url=https://docs.microsoft.com/en-us/archive/blogs/josebda/the-basics-of-smb-signing-covering-both-smb1-and-smb2|url-status=live|archive-url=https://web.archive.org/web/20121202155239/http://blogs.technet.com/b/josebda/archive/2010/12/01/the-basics-of-smb-signing-covering-both-smb1-and-smb2.aspx|archive-date=2 December 2012|website=Jose Barreto's Blog Archive|publisher=[[Microsoft]]|via=[[Microsoft Docs]]|quote=This security mechanism in the SMB protocol helps avoid issues like tampering of packets and "man in the middle" attacks. [...] SMB signing is available in all currently supported versions of Windows, but it’s only enabled by default on Domain Controllers. This is recommended for Domain Controllers because SMB is the protocol used by clients to download Group Policy information. SMB signing provides a way to ensure that the client is receiving genuine Group Policy.}}</ref> 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 controller]]s running [[Windows Server 2003]] and later is to not allow unsigned incoming connections.<ref>{{cite web | url = http://support.microsoft.com/kb/887429 | title = MSKB887429: Overview of Server Message Block signing | publisher = [[Microsoft]] | date = November 30, 2007 | quote = By default, SMB signing is required for incoming SMB sessions on Windows Server 2003-based domain controllers. | access-date = October 24, 2012 | archive-url = https://web.archive.org/web/20101120173639/http://support.microsoft.com/kb/887429 | archive-date = November 20, 2010 | url-status = live }}</ref> 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.<ref name=":1" />

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 [[cache (computing)|caching]] of network files by the client.<ref>{{cite web|date=May 31, 2018|title=Opportunistic Locks|url=https://docs.microsoft.com/en-us/windows/win32/fileio/opportunistic-locks|access-date=August 19, 2021|publisher=Microsoft|archive-date=August 19, 2021|archive-url=https://web.archive.org/web/20210819174457/https://docs.microsoft.com/en-us/windows/win32/fileio/opportunistic-locks|url-status=live}}</ref> Unlike traditional [[Lock (computer science)|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.<ref name="Sphere2014">{{cite web|year=2014|title=All About Opportunistic Locking|url=https://sphereit.uk/all-about-opportunistic-locks/|access-date=August 19, 2021|website=Sphere IT|archive-date=August 19, 2021|archive-url=https://web.archive.org/web/20210819154425/https://sphereit.uk/all-about-opportunistic-locks/|url-status=live}}</ref>
; 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&nbsp;2 OpLock" from the server. A Level&nbsp;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&nbsp;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&nbsp;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.{{clarify|reason=Does this refer to service location via name resolution or via the browser protocol?|date=March 2013}} 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 planning and design|Network designers]] have found that [[Network latency|latency]] has a significant impact on the performance of the SMB 1.0 protocol, that it performs more poorly than other protocols like [[File Transfer Protocol|FTP]]. Monitoring reveals a high degree of "chattiness" and a disregard of network latency between hosts.<ref name="barreto">{{cite web|author=Jose Barreto|date=December 9, 2008|title=SMB2, a Complete Redesign of the Main Remote File Protocol for Windows|url=http://blogs.technet.com/josebda/archive/2008/12/05/smb2-a-complete-redesign-of-the-main-remote-file-protocol-for-windows.aspx|access-date=November 1, 2009|publisher=[[Microsoft]] Server & Management Blogs|url-status=dead|archive-url=https://web.archive.org/web/20130112180513/http://blogs.technet.com/b/josebda/archive/2008/12/05/smb2-a-complete-redesign-of-the-main-remote-file-protocol-for-windows.aspx|archive-date=January 12, 2013}}</ref> For example, a [[Virtual private network|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 algorithm|streaming]] protocol, that was originally designed for small [[local area network|LANs]]; it has a block size that is limited to 64K, SMB signing creates an additional overhead and the [[TCP tuning|TCP window size]] is not optimized for WAN links.<ref>{{cite web|author=Neil Carpenter|date=October 26, 2004|title=SMB/CIFS Performance Over WAN Links|url=https://docs.microsoft.com/en-us/archive/blogs/neilcar/smbcifs-performance-over-wan-links|url-status=live|archive-url=https://web.archive.org/web/20200213113816/https://docs.microsoft.com/en-us/archive/blogs/neilcar/smbcifs-performance-over-wan-links|archive-date=February 13, 2020|access-date=February 13, 2020|publisher=[[Microsoft]]}}</ref> Solutions to this problem include the updated SMB 2.0 protocol,<ref>{{cite web|title=What's New in SMB in Windows Server|url=https://technet.microsoft.com/en-us/library/hh831474(v=ws.11).aspx|url-status=live|archive-url=https://web.archive.org/web/20170211075409/https://technet.microsoft.com/en-us/library/hh831474(v=ws.11).aspx|archive-date=February 11, 2017|access-date=6 February 2017|website=Microsoft| date=31 August 2016 }}</ref> [[Offline Files]], [[TCP window scale option|TCP window scaling]] and [[WAN optimization]] devices from various network vendors that cache and optimize SMB 1.0<ref>{{cite web|author=Mark Rabinovich, Igor Gokhman|title=CIFS Acceleration Techniques|url=https://www.snia.org/sites/default/orig/sdc_archives/2009_presentations/monday/MarkRabinovich-IgorGokhman-CIFS_Acceleration_Techniques.pdf|access-date=July 6, 2020|publisher=Storage Developer Conference, SNIA, Santa Clara 2009|archive-date=September 30, 2020|archive-url=https://web.archive.org/web/20200930145453/https://www.snia.org/sites/default/orig/sdc_archives/2009_presentations/monday/MarkRabinovich-IgorGokhman-CIFS_Acceleration_Techniques.pdf|url-status=live}}</ref> and 2.0.<ref>{{cite web|author=Mark Rabinovich|title=Accelerating SMB2|url=https://www.snia.org/sites/default/orig/SDC2011/presentations/wednesday/MarkRabinovichAccelerating_SMB2.pdf|access-date=July 6, 2020|publisher=Storage Developer Conference, SNIA, Santa Clara 2011|archive-date=May 31, 2024|archive-url=https://web.archive.org/web/20240531142910/https://www.snia.org/sites/default/orig/SDC2011/presentations/wednesday/MarkRabinovichAccelerating_SMB2.pdf|url-status=live}}</ref>