次の方法で共有

2.2.3.1 The SMB Header

  • [アーティクル]

The SMB_Header structure is a fixed 32-bytes in length.

 SMB_Header
   {
   UCHAR  Protocol[4];
   UCHAR  Command;
   SMB_ERROR Status;
   UCHAR  Flags;
   USHORT Flags2;
   USHORT PIDHigh;
   UCHAR  SecurityFeatures[8];
   USHORT Reserved;
   USHORT TID;
   USHORT PIDLow;
   USHORT UID;
   USHORT MID;
   }


0


1


2


3


4


5


6


7


8


9

1
0


1


2


3


4


5


6


7


8


9

2
0


1


2


3


4


5


6


7


8


9

3
0


1

Protocol

Command

Status

...

Flags

Flags2

PIDHigh

SecurityFeatures

...

...

Reserved

TID

PIDLow

UID

MID

Protocol (4 bytes): This field MUST contain the 4-byte literal string '\xFF', 'S', 'M', 'B', with the letters represented by their respective ASCII values in the order shown. In the earliest available SMB documentation, this field is defined as a one byte message type (0xFF) followed by a three byte server type identifier.

Command (1 byte): A one-byte command code. Defined SMB command codes are listed in section 2.2.2.1.

Status (4 bytes): A 32-bit field used to communicate error messages from the server to the client.

Flags (1 byte): An 8-bit field of 1-bit flags describing various features in effect for the message.

Name and bitmask

Description

Earliest dialect

SMB_FLAGS_LOCK_AND_READ_OK

0x01

This bit is set (1) in the SMB_COM_NEGOTIATE (0x72) Response (section 2.2.4.52.2) if the server supports SMB_COM_LOCK_AND_READ (0x13) (section 2.2.4.20) and SMB_COM_WRITE_AND_UNLOCK (0x14) (section 2.2.4.21) commands.

LANMAN1.0

SMB_FLAGS_BUF_AVAIL

0x02

Obsolete

When set (on an SMB request being sent to the server), the client guarantees that there is a receive buffer posted such that a send without acknowledgment can be used by the server to respond to the client's request.

This behavior is specific to an obsolete transport. This bit MUST be set to zero by the client and MUST be ignored by the server.

LANMAN1.0

Reserved

0x04

This flag MUST be set to zero by the client and MUST be ignored by the server.

LANMAN1.0

SMB_FLAGS_CASE_INSENSITIVE

0x08

Obsolete

If this bit is set then all pathnames in the SMB SHOULD be treated as case-insensitive.<26>

LANMAN1.0

SMB_FLAGS_CANONICALIZED_PATHS

0x10

Obsolescent

When set in session setup, this bit indicates that all paths sent to the server are already in canonical format. That is, all file and directory names are composed of valid file name characters in all upper-case, and that the path segments are separated by backslash characters ('\').

LANMAN1.0

SMB_FLAGS_OPLOCK

0x20

Obsolescent

This bit has meaning only in the deprecated SMB_COM_OPEN (0x02) Request (section 2.2.4.3.1), SMB_COM_CREATE (0x03) Request (section 2.2.4.4.1), and SMB_COM_CREATE_NEW (0x0F) Request (section 2.2.4.16.1) messages, where it is used to indicate that the client is requesting an Exclusive OpLock. It SHOULD be set to zero by the client, and ignored by the server, in all other SMB requests. If the server grants this OpLock request, then this bit SHOULD remain set in the corresponding response SMB to indicate to the client that the OpLock request was granted.

LANMAN1.0

SMB_FLAGS_OPBATCH

0x40

Obsolescent

This bit has meaning only in the deprecated SMB_COM_OPEN (0x02) Request (section 2.2.4.3.1), SMB_COM_CREATE (0x03) Request (section 2.2.4.4.1), and SMB_COM_CREATE_NEW (0x0F) Request (section 2.2.4.16.1) messages, where it is used to indicate that the client is requesting a Batch OpLock. It SHOULD be set to zero by the client, and ignored by the server, in all other SMB requests. If the server grants this OpLock request, then this bit SHOULD remain set in the corresponding response SMB to indicate to the client that the OpLock request was granted.

If the SMB_FLAGS_OPLOCK bit is clear (0), then the SMB_FLAGS_OPBATCH bit is ignored.

LANMAN1.0

SMB_FLAGS_REPLY

0x80

When on, this message is being sent from the server in response to a client request. The Command field usually contains the same value in a protocol request from the client to the server as in the matching response from the server to the client. This bit unambiguously distinguishes the message as a server response.

LANMAN1.0

Flags2 (2 bytes): A 16-bit field of 1-bit flags that represent various features in effect for the message. Unspecified bits are reserved and MUST be zero.

Name and bitmask

Description

Earliest dialect

SMB_FLAGS2_LONG_NAMES

0x0001

If the bit is set, the message MAY contain long file names. If the bit is clear then file names in the message MUST adhere to the 8.3 naming convention.

If set in a client request for directory enumeration, the server MAY return long names (that is, names that are not 8.3 names) in the response to this request. If not set in a client request for directory enumeration, the server MUST return only 8.3 names in the response to this request. This flag indicates that in a direct enumeration request, paths returned by the server are not restricted to 8.3 names format. This bit field SHOULD be set to 1 when the negotiated dialect is LANMAN2.0 or later.

LANMAN2.0

SMB_FLAGS2_EAS

0x0002

If the bit is set, the client is aware of extended attributes (EAs).

The client MUST set this bit if the client is aware of extended attributes. In response to a client request with this flag set, a server MAY include extended attributes in the response. This bit field SHOULD be set to 1 when the negotiated dialect is LANMAN2.0 or later.

LANMAN1.2

SMB_FLAGS2_SMB_SECURITY_SIGNATURE

0x0004

If set by the client, the client is requesting signing (if signing is not yet active) or the message being sent is signed. This bit is used on the SMB header of an SMB_COM_SESSION_SETUP_ANDX (section 2.2.4.53) client request to indicate that the client supports signing and that the server can choose to enforce signing on the connection based on its configuration.

To turn on signing for a connection, the server MUST set this flag and also sign the SMB_COM_SESSION_SETUP_ANDX Response (section 2.2.4.53), after which all of the traffic on the connection (except for OpLock Break notifications) MUST be signed. In the SMB header of other CIFS client requests, the setting of this bit indicates that the packet has been signed. This bit field SHOULD be set to 1 when the negotiated dialect is NT LANMAN or later.

NT LANMAN

SMB_FLAGS2_IS_LONG_NAME

0x0040

Reserved but not implemented.

NT LANMAN

SMB_FLAGS2_DFS

0x1000

If the bit is set, any pathnames in this SMB SHOULD be resolved in the Distributed File System (DFS).

NT LANMAN

SMB_FLAGS2_PAGING_IO

0x2000

This flag is useful only on a read request. If the bit is set, then the client MAY read the file if the client does not have read permission but does have execute permission. This bit field SHOULD be set to 1 when the negotiated dialect is LANMAN2.0 or later. This flag is also known as SMB_FLAGS2_READ_IF_EXECUTE.

NT LANMAN

SMB_FLAGS2_NT_STATUS

0x4000

If this bit is set in a client request, the server MUST return errors as 32-bit NTSTATUS codes in the response. If it is clear, the server SHOULD<27> return errors in SMBSTATUS format.

If this bit is set in the server response, the Status field in the header is formatted as an NTSTATUS code; else, it is in SMBSTATUS format.

NT LANMAN

SMB_FLAGS2_UNICODE

0x8000

If set in a client request or server response, each field that contains a string in this SMB message MUST be encoded as an array of 16-bit Unicode characters, unless otherwise specified.

If this bit is clear, each of these fields MUST be encoded as an array of OEM characters. This bit field SHOULD be set to 1 when the negotiated dialect is NT LANMAN.

NT LANMAN

PIDHigh (2 bytes): If set to a nonzero value, this field represents the high-order bytes of a process identifier (PID). It is combined with the PIDLow field below to form a full PID.

SecurityFeatures (8 bytes): This 8-byte field has three possible interpretations.

In the case that security signatures are negotiated (see SMB_COM_NEGOTIATE (0x72) (section 2.2.4.52), the following format MUST be observed.

 SecurityFeatures
   {
   UCHAR  SecuritySignature[8];
   }


0


1


2


3


4


5


6


7


8


9

1
0


1


2


3


4


5


6


7


8


9

2
0


1


2


3


4


5


6


7


8


9

3
0


1

SecuritySignature

...

SecuritySignature (8 bytes): If SMB signing has been negotiated, this field MUST contain an 8-byte cryptographic message signature that can be used to detect whether the message was modified while in transit. The use of message signing is mutually exclusive with connectionless transport.

In the case that CIFS is being transported over a connectionless transport (see section 2.1.2.1), the following format MUST be observed.

 SecurityFeatures
   {
   ULONG  Key;
   USHORT CID;
   USHORT SequenceNumber;
   }


0


1


2


3


4


5


6


7


8


9

1
0


1


2


3


4


5


6


7


8


9

2
0


1


2


3


4


5


6


7


8


9

3
0


1

Key

CID

SequenceNumber

Key (4 bytes): An encryption key used for validating messages over connectionless transports.

CID (2 bytes): A connection identifier (CID).

SequenceNumber (2 bytes): A number used to identify the sequence of a message over connectionless transports.

Finally, if neither of the above two cases applies, the SecurityFeatures field is treated as a reserved field, which MUST be set to zero by the client and MUST be ignored by the server.

Reserved (2 bytes): This field is reserved and SHOULD be set to 0x0000.

TID (2 bytes): A tree identifier (TID).

PIDLow (2 bytes): The lower 16-bits of the PID.

UID (2 bytes): A user identifier (UID).

MID (2 bytes): A multiplex identifier (MID).