2.2 Message Syntax

  • Article

The SMB 2 Protocol is composed of, and driven by, message exchanges between the client and the server in the following categories:

  • Protocol negotiation (SMB2 NEGOTIATE)

  • User authentication (SMB2 SESSION_SETUP, SMB2 LOGOFF)

  • Share access (SMB2 TREE_CONNECT, SMB2 TREE_DISCONNECT)

  • File access (SMB2 CREATE, SMB2 CLOSE, SMB2 READ, SMB2 WRITE, SMB2 LOCK, SMB2 IOCTL, SMB2 QUERY_INFO, SMB2 SET_INFO, SMB2 FLUSH, SMB2 CANCEL)

  • Directory access (SMB2 QUERY_DIRECTORY, SMB2 CHANGE_NOTIFY)

  • Volume access (SMB2 QUERY_INFO, SMB2 SET_INFO)

  • Cache coherency (SMB2 OPLOCK_BREAK)

  • Simple messaging (SMB2 ECHO)

The SMB 2.1 dialect in the SMB 2 Protocol enhances the following categories of messages in the SMB 2 Protocol:

  • Protocol Negotiation (SMB2 NEGOTIATE)

  • Share Access (SMB2 TREE_CONNECT)

  • File Access (SMB2 CREATE, SMB2 WRITE)

  • Cache Coherency (SMB2 OPLOCK_BREAK)

  • Hash Retrieval (SMB2 IOCTL)

The SMB 3.x dialect family in the SMB 2 Protocol further enhances the following categories of messages in the SMB 2 Protocol:

  • Protocol Negotiation and secure dialect validation (SMB2 NEGOTIATE, SMB2 IOCTL)

  • Share Access (SMB2 TREE_CONNECT)

  • File Access (SMB2 CREATE, SMB2 READ, SMB2 WRITE)

  • Hash Retrieval (SMB2 IOCTL)

  • Encryption (SMB2 TRANSFORM_HEADER)

The SMB 3.1.1 dialect in the SMB 2 Protocol further enhances the following categories of messages in the SMB 2 Protocol:

  • Compression (SMB2 COMPRESSION_TRANSFORM_HEADER)

This document specifies the messages in the preceding lists.

An SMB 2 Protocol message is the payload packet encapsulated in a transport packet.

All SMB 2 Protocol messages begin with a fixed-length SMB2 header that is described in section 2.2.1. The SMB2 header contains a Command field indicating the operation code that is requested by the client or responded to by the server. An SMB 2 Protocol message is of variable length, depending on the Command field in the SMB2 header and on whether the SMB 2 Protocol message is a client request or a server response.

Unless otherwise specified, the SMB 2 Protocol does not support case-sensitivity in handling strings (file names, directory names, path names, share names, stream names, etc.).

Unless otherwise specified, multiple-byte fields (16-bit, 32-bit, and 64-bit fields) in an SMB 2 Protocol message MUST be transmitted in little-endian order (least-significant byte first).

Unless otherwise indicated, numeric fields are integers of the specified byte length.

Unless otherwise specified, all textual strings MUST be in Unicode version 5.0 format, as specified in [UNICODE], using the 16-bit Unicode Transformation Format (UTF-16) form of the encoding. Textual strings with separate fields identifying the length of the string MUST NOT be null-terminated unless otherwise specified.

Unless otherwise noted, fields marked as "unused" MUST be set to 0 when being sent and MUST be ignored when received. These fields are reserved for future protocol expansion and MUST NOT be used for implementation-specific functionality.

When it is necessary to insert unused padding bytes into a buffer for data alignment purposes, such bytes MUST be set to 0 when being sent and MUST be ignored when received.

When an error occurs, a server MUST send back an SMB 2 Protocol error response as specified in section 2.2.2, unless otherwise noted in section 3.3.

All constants in section 2 and 3 that begin with STATUS_ have their values defined in [MS-ERREF] section 2.3.

Operations executed on a printer share are handled on the server by creating a file, and printing the contents of the file when it is closed. Unless otherwise specified, descriptions in this document concerning protocol behavior for files also apply to printers. More information about processing specific to printers is specified in section 2.2.13.