The protocol supports the usual set of file operations: open, close, read, write, and seek.

The protocol supports file and record locking, as well as unlocked access to files. Applications that lock files cannot be improperly interfered with by applications that do not; once a file or record is locked, non-locking applications are denied access to the file.

The protocol supports caching, read-ahead, and write-behind, even for unlocked files, as long as they are safe. All these optimizations are safe as long as only one client is accessing a file; readcaching and read-ahead are safe with many clients accessing a file as long as all are just reading. If many clients are writing a file simultaneously, then none are safe, and all file operations have to go to the server. The protocol notifies all clients accessing a file of changes in the number and access mode of clients accessing the file, so that they can use the most optimized safe access method.

Applications can register with a server to be notified if and when file or directory contents are modified. They can use this to (for example) know when a display needs to be refreshed, without having to constantly poll the server.

There are several different versions and sub-versions of this protocol; a particular version is referred to as a dialect. When two machines first come into network contact they negotiate the dialect to be used. Different dialects can include both new messages as well as changes to the fields and semantics of existing messages in other dialects.

In addition to many built-in file attributes, such as creation and modification times, non-file system attributes can be added by applications, such as the author’s name, content description, etc.

The protocol supports file system subtrees which look like to clients as if they are on a single volume and server, but which actually span multiple volumes and servers. The files and directories of such a subtree can be physically moved to different servers, and their names do not have to change, isolating clients from changes in the server configuration. These subtrees can also be transparently replicated for load sharing and fault tolerance. When a client requests a file, the protocol uses referrals to transparently direct a client to the server that stores it.

The protocol allows clients to resolve server names using any name resolution mechanism. In particular, it allows using the DNS, permitting access to the file systems of other organizations over the Internet, or hierarchical organization of servers’ names within an organization. Earlier versions of the protocol only supported a flat server name space.

The protocol supports the batching of multiple requests into a single message, in order to minimize round trip latencies, even when a later request depends on the results of an earlier one.

Throughout this document, references are made to obsolescent elements of the CIFS protocol. Note that these obsolescent elements are still observed in implementations. The “obsolescent” label only describes that these elements may be removed from implementations, in the future.

Once a connection is established, the rules for reliable transport connection dissolution are:

There are three types of oplocks:

Versions of the CIFS file sharing protocol including and newer than the “LANMAN1.0” dialect support oplocks. Level II oplocks were introduced in NTLM 0.12.

The CIFS protocol has three mechanisms to enable a client to control how other clients access a file.

Of the three, the server may revoke only opportunistic locks. Byte range and sharing locks are held for as long as the client desires.

Historically on client systems, byte range and sharing locks are exposed to the application. This allows the application to have explicit control over the obtaining and releasing of these types of locks.

Typically however oplocks are not exposed to the application. They are implemented inside the client operating system. The client operating system decides when it is appropriate to obtain and release oplocks. It also handles all of the issues related to revoking of oplocks by the server.

This section summarizes the SMB commands that affect oplocks.

Since a close being sent to the server and break oplock notification from the server could cross on the wire, if the client gets an oplock notification on a file that it does not have open, that notification should be ignored. The client is guaranteed that an oplock break notification will not be issued before the server has sent the response to the file open.

Due to timing, the client could get an “oplock broken” notification in a user’s data buffer as a result of this notification crossing on the wire with an SMB_COM_READ_RAW request. The client must detect this (use length of message, “FFSMB,” MID of -1 and Command of SMB_COM_LOCKING_ANDX) and honor the “oplock broken” notification as usual. The server must also note on receipt of an SMB_COM_READ_RAW request that there is an outstanding (unanswered) “oplock broken” notification to the client; it must then return a zero length response denoting failure of the read raw request. The client should (after responding to the “oplock broken” notification) use a non-raw read request to redo the read. This allows a file to actually contain data matching an “oplock broken” notification and still be read correctly.

When an exclusive or batch oplock is being revoked, more than one client open request may be paused until the oplock is released. Once the oplock is released, the order that the paused open requests are processed is not defined.

The protocol allows a client to obtain an oplock and then issue an operation that causes the oplock to be revoked. An example of this is a client obtaining an exclusive oplock on a file and then opening the file a second time.

The protocol allows a client to have a file open multiple times, and each open could have a level II oplock associated with it. A server may choose not to support this situation by simply not handing out more than one level II oplock for a particular file to a particular client.

The protocol allows a server to grant on a single file a level II oplock for some opens and no oplock for other opens. A server may have heuristics that indicate some file opens would not benefit from a level II oplock.

A server that supports access to files via mechanisms other than this protocol must revoke oplocks as necessary to preserve the semantics expected by the clients owning the oplocks.

A client that has an exclusive or batch oplock on a file may cache file metadata. This includes the following information: create time, modify time, access time, change time, file size, file attributes, and extended attributes size. However a server is not required to break an oplock when a second client examines file metadata. Clients should be aware of this behavior when examining file metadata without having the file open.

When a server revokes an exclusive or batch oplock it may grant a level II oplock in its place. The client should consider the level II oplock in effect after the client has released the exclusive or batch oplock. The server may decide to revoke the level II oplock before the client has released the exclusive or batch oplock. In this situation the client should behave as if the revoke of the level II oplock arrived just after the exclusive or batch oplock was released.

User authentication is based on the shared knowledge of the user’s password. There are two styles of user authentication. The first involves the client sending passwords in plain text to the server. The second involves a challenge/response protocol.

Plain text password authentication exposes the user’s password to programs that have access to the CIFS protocol data on the network. For this reason plain text password authentication is discouraged and by default should be disabled in CIFS protocol implementations.

With the challenge/response protocol the server sends a “challenge” to the client, which the client responds to in a way that proves it knows the user’s password. A “response” is created from the challenge by encrypting it with a 168 bit “session key” computed from the user’s password. The response is then returned to the server, which can validate the response by performing the same computation.

The user authentication protocol is described as if the CIFS server keeps a client’s password. However an implementation might actually store the passwords on a key distribution server and have servers use a protocol outside the scope of this document to enable them to perform the steps required by this protocol.

Messages may be authenticated by computing a message authentication code (MAC) for each message and attaching it to the message. The MAC used is a keyed MD5 construction similar to that used in IPSec [RFC 1828], using a “MAC key” computed from the session key, and the response to the server’s challenge. The MAC is over both the message text and an implicit sequence number, to prevent replay attacks.

Following are definitions of algorithms used by the authentication algorithms.

E(K, D)

Ex(K,D)

concat(A, B, ..., Z)

head(S, N)

swab(S)

zeros(N)

ones(N)

xor(A, B)

and(A, B)

substr(S, A, B)

Following are definitions of the authentication algorithms.

Once a user logon has been authenticated, each message can be authenticated as well. This will prevent man in the middle attacks, replay attacks, and active message modification attacks.

To use message authentication, the client sets SMB_FLAGS2_SMB_SECURITY_SIGNATURE in SMB_COM_SESSION_SETUP_ANDX request to the server, and includes a MAC. If the resulting logon is non-null and non-guest, then the SMB_COM_SESSION_SETUP_ANDX response and all subsequent SMB requests and responses must include a MAC. The first non-null, non-guest logon determines the key to be used for the MAC for all subsequent sessions.

Message authentication may only be requested when the “NTLM 0.12” dialect has been negotiated. If message authentication is used, raw mode MUST not be used (because some raw mode messages have no headers in which to carry the MAC).

Let

The SN is logically contained in each message and participates in the computation of the MAC.

For each message sent in the session, the following procedure is followed:

In each message that contains a MAC, the following bit is set in the flags2 field:

#define SMB_FLAGS2_SMB_SECURITY_SIGNATURES 0x0004

The sender of a message inserts the sequence number SSN into the message by putting it into the first 4 bytes of the SecuritySignature field and zeroing the last 4 bytes, computes the MAC over the entire message, then puts the MAC in the field. The receiver of a message validates the MAC by extracting the value of the SecuritySignature field, putting its ESN into the first 4 bytes of the SecuritySignature field and zeroing the last 4 bytes, computing the MAC, and comparing it to the extracted value.

Oplock break messages from the server to the client may not use message authentication, even if it has been negotiated.

The SMB_COM_NEGPROT response from a server has the following bits in its SecurityMode field:

#define NEGOTIATE_SECURITY_USER_LEVEL          0x01
#define NEGOTIATE_SECURITY_CHALLENGE_RESPONSE  0x02
#define NEGOTIATE_SECURITY_SIGNATURES_ENABLED  0x04
#define NEGOTIATE_SECURITY_SIGNATURES_REQUIRED 0x08

If NEGOTIATE_SECURITY_USER_LEVEL is set, then “user level” security is in effect for all the shares on the server. This means that the client must establish a logon (with SMB_COM_SESSION_SETUP_ANDX) to authenticate the user before connecting to a share, and the password to use in the authentication protocol described above is the user’s password. If NEGOTIATE_SECURITY_USER_LEVEL is clear, then “share level” security is in effect for all the shares in the server. In this case the authentication protocol is a password for the share.

If NEGOTIATE_SECURITY_CHALLENGE_RESPONSE is clear, then the server is requesting plaintext passwords.

If NEGOTIATE_SECURITY_CHALLENGE_RESPONSE is set, then the server supports the challenge/response session authentication protocol described above, and clients should use it. Servers may refuse connections that do not use it.

If the dialect is earlier than “NTLM 0.12” then the client computes the response using the “LM session key”. If the dialect is “NTLM 0.12” then the client may compute the response either using the “LM session key”, or the “NT session key”, or both. The server may choose to refuse responses computed using the “LM session key”.

If NEGOTIATE_SECURITY_SIGNATURES_ENABLED is set, then the server supports the message authentication protocol described above, and the client may use it. This bit may only be set if NEGOTIATE_SECURITY_CHALLENGE_RESPONSE is set.

If NEGOTIATE_SECURITY_SIGNATURES_REQUIRED is set, then the server requires the use of the message authentication protocol described above, and the client must use it. This bit may only be set if NEGOTIATE_SECURITY_SIGNATURES_ENABLED is set. This bit must not be set if NEGOTIATE_SECURITY_USER_LEVEL is clear (i.e., for servers using “share level” security).

The Command is the operation code that this SMB is requesting or responding to. See section 5.1 below for number values, and section 4 for a description of each operation.

This field contains 8 individual flags, numbered from least significant bit to most significant bit, which are defined below. Flags that are not defined MUST be set to zero by clients and MUST be ignored by servers.

This field contains nine individual flags, numbered from least significant bit to most significant bit, which are defined below. Flags that are not defined MUST be set to zero by clients and MUST be ignored by servers.

Tid represents an instance of an authenticated connection to a server resource. The server returns Tid to the client when the client successfully connects to a resource, and the client uses Tid in subsequent requests referring to the resource.

In most SMB requests, Tid must contain a valid value. Exceptions are those used prior to getting a Tid established, including SMB_COM_NEGOTIATE, SMB_COM_TREE_CONNECT_ANDX, SMB_COM_ECHO, and SMB_COM_SESSION_SETUP_ANDX. 0xFFFF should be used for Tid for these situations. The server is always responsible for enforcing use of a valid Tid where appropriate.

On SMB_COM_TREE_DISCONNECT over a given transport connection, with a given Tid, the server will close any files opened with that Tid over that connection.

Pid is the caller’s process id, and is generated by the client to uniquely identify a process within the client computer. Concurrency control is associated with Pid (and PidHigh)—sharing modes, and locks are arbitrated using the Pid. For example, if a file is successfully opened for exclusive access, subsequent opens from other clients or from the same client with a different Pid will be refused.

Clients inform servers of the creation of a new process by simply introducing a new Pid value into the dialogue for new processes. The client operating system must ensure that the appropriate close and cleanup SMBs will be sent when the last process referencing a file closes it. From the server’s point of view, there is no concept of Fids “belonging to” processes. A Fid returned by the server to one process may be used by any other process using the same transport connection and Tid.

It is up to the client operating system to ensure that only authorized client processes gain access to Fids (and Tids). On SMB_COM_TREE_DISCONNECT (or when the client and server session is terminated) with a given Tid, the server will invalidate any files opened by any process on that client.tid Field

Uid is a reference number assigned by the server after a user authenticates to it, and that it will associate with that user until the client requests the association be broken. After authentication to the server, the client SHOULD make sure that the Uid is not used for a different user that the one that authenticated. (It is permitted for a single user to have more than one Uid.) Requests that do authorization, such as open requests, will perform access checks using the identity associated with the Uid.

The multiplex ID (Mid) is used along with the Pid to allow multiplexing the single client and server connection among the client’s multiple processes, threads, and requests per thread. Clients may have many outstanding requests (up to the negotiated number, MaxMpxCount) at one time. Servers MAY respond to requests in any order, but a response message MUST always contain the same Mid and Pid values as the corresponding request message. The client MUST NOT have multiple outstanding requests to a server with the same Mid and Pid.

An SMB returns error information to the client in the Status field. Protocol dialects prior to NT LM 0.12 return status to the client using the combination of Status.DosError.ErrorClass and Status.DosError.Error. Beginning with NT LM 0.12 CIFS servers can return 32 bit error information to clients using Status.Status if the incoming client SMB has bit 14 set in the Flags2 field of the SMB header. The contents of response parameters are not guaranteed in the case of an error return, and must be ignored. For write-behind activity, a subsequent write or close of the file may return the fact that a previous write failed. Normally write-behind failures are limited to hard disk errors and device out of space.

In general, SMBs are not expected to block at the server; they should return “immediately”. There are however a series of operations which may block for a significant time. The most obvious of these is named-pipe operations, which may be dependent on another application completing a write before they can fully complete their read. (Most named-pipe operations are never expired unless cancelled). Similarly, with byte-range locking, the Timeout period is specified by the client, so the server is not responsible for blocking on this operation as long as the client has specified it may. A SMB server should put forth its best effort to handle operations as they arrive in an efficient manner, such that clients do not timeout operations believing the server to be unresponsive falsely. A client may timeout a pending operation by terminating the session. If a server implementation can not support timeouts, then an error can be returned just as if a timeout had occurred if the resource is not available immediately upon request.

The data portion of SMBs typically contains the data to be read or written, file paths, or directory paths. The format of the data portion depends on the message. All fields in the data portion have the same format. In every case it consists of an identifier byte followed by the data.

When the identifier indicates a data block or variable block then the format is a word indicating the length followed by the data.

In all dialects prior to NT LM 0.12, all strings are encoded in ASCII. If the agreed dialect is NT LM 0.12 or later, Unicode strings may be exchanged. Unicode strings include file names, resource names, and user names. This applies to null-terminated strings, length specified strings and the type-prefixed strings. In all cases where a string is passed in Unicode format, the Unicode string must be word-aligned with respect to the beginning of the SMB. Should the string not naturally fall on a two-byte boundary, a null byte of padding will be inserted, and the Unicode string will begin at the next address. In the description of the SMBs, items that may be encoded in Unicode or ASCII are labeled as STRING. If the encoding is ASCII, even if the negotiated string is Unicode, the quantity is labeled as UCHAR.

For type-prefixed Unicode strings, the padding byte is found after the type byte. The type byte is 4 (indicating SMB_FORMAT_ASCII) independent of whether the string is ASCII or Unicode. For strings whose start addresses are found using offsets within the fixed part of the SMB (as opposed to simply being found at the byte following the preceding field,) it is guaranteed that the offset will be properly aligned.

Strings that are never passed in Unicode are:

When Unicode is negotiated, the SMB_FLAGS2_UNICODE bit should be set in the Flags2 field of every SMB header.

Despite the flexible encoding scheme, no field of a data portion may be omitted or included out of order. In addition, neither a WordCount nor ByteCount of value 0 at the end of a message may be omitted.

The following list describes the format of the TRANSACTION2 client request:

Primary Client Request            Description
=======================           ============
 Command                           SMB_COM_TRANSACTION2
 UCHAR WordCount;                  Count of parameter words; value =
                                             (14 + SetupCount)
 USHORT TotalParameterCount;       Total parameter bytes being sent
 USHORT TotalDataCount;            Total data bytes being sent
 USHORT MaxParameterCount;         Max parameter bytes to return
 USHORT MaxDataCount;              Max data bytes to return
 UCHAR MaxSetupCount;              Max setup words to return
 UCHAR Reserved;
 USHORT Flags;                     Additional information:
                                      bit 0 - Disconnect TID
 ULONG Timeout;
 USHORT Reserved2;
 USHORT ParameterCount;            Parameter bytes sent this buffer
 USHORT ParameterOffset;           Offset (from header start) to
                                             Parameters
 USHORT DataCount;                 Data bytes sent this buffer
 USHORT DataOffset;                Offset (from header start) to data
 UCHAR SetupCount;                 Count of setup words
 UCHAR Reserved3;                  Reserved (pad above to word boundary)
 USHORT Setup[SetupCount];         Setup words (# = SetupWordCount)
 USHORT ByteCount;                 Count of data bytes
 STRING Name[];                    Must be NULL
 UCHAR Pad[];                      Pad to SHORT or LONG
 UCHAR Parameters[                 Parameter bytes (# = ParameterCount)
    ParameterCount];
 UCHAR Pad1[];                     Pad to SHORT or LONG
 UCHAR Data[DataCount];            Data bytes (# = DataCount)

The interim server response will consist of two fields:

UCHAR WordCount;                \ Count of parameter words = 0
USHORT ByteCount;               \ Count of data bytes = 0

The following list describes the format of the TRANSACTION2 secondary client request:

Secondary Client Request           Description
=========================          ============
 Command                            SMB_COM_TRANSACTION_SECONDARY
 UCHAR WordCount;                   Count of parameter words = 8
 USHORT TotalParameterCount;        Total parameter bytes being sent
 USHORT TotalDataCount;             Total data bytes being sent
 USHORT ParameterCount;             Parameter bytes sent this buffer
 USHORT ParameterOffset;            Offset (from header start) to Parameters
 USHORT ParameterDisplacement;      Displacement of these Parameter bytes
 USHORT DataCount;                  Data bytes sent this buffer
 USHORT DataOffset;                 Offset (from header start) to data
 USHORT DataDisplacement;           Displacement of these data bytes
 USHORT Fid;                            FID for handle based requests, else
                                        0xFFFF. This field is present only
                                        if this is an SMB_COM_TRANSACTION2
                                        request.
 USHORT ByteCount;                  Count of data bytes
 UCHAR Pad[];                       Pad to SHORT or LONG
 UCHAR Parameters[                  Parameter bytes (# = ParameterCount)
     ParameterCount];
 UCHAR Pad1[];                      Pad to SHORT or LONG
 UCHAR Data[DataCount];             Data bytes (# = DataCount)

And, the fields of the server response are described in the following list:

Server Response                   Description
================                  ============
 UCHAR WordCount;                  Count of data bytes; value = 10 +
                                      SetupCount
 USHORT TotalParameterCount;       Total parameter bytes being sent
 USHORT TotalDataCount;            Total data bytes being sent
 USHORT Reserved;
 USHORT ParameterCount;            Parameter bytes sent this buffer
 USHORT ParameterOffset;           Offset (from header start) to Parameters
 USHORT ParameterDisplacement;     Displacement of these Parameter
                                            bytes
 USHORT DataCount;                 Data bytes sent this buffer
 USHORT DataOffset;                Offset (from header start) to data
 USHORT DataDisplacement;          Displacement of these data bytes
 UCHAR SetupCount;                 Count of setup words
 UCHAR Reserved2;                  Reserved (pad above to word boundary)
 USHORT Setup[SetupWordCount];     Setup words (# = SetupWordCount)
 USHORT ByteCount;                 Count of data bytes
 UCHAR Pad[];                      Pad to SHORT or LONG
 UCHAR Parameters[                 Parameter bytes (# = ParameterCount)
    ParameterCount];
 UCHAR Pad1[];                     Pad to SHORT or LONG
 UCHAR Data[DataCount];            Data bytes (# = DataCount)

The following list describes the format of the TRANSACTION primary client request:

Primary Client Request           Description
=======================          ============
 UCHAR WordCount;                Count of parameter words; value =
                                          (19 + SetupCount)
 UCHAR MaxSetupCount;            Max setup words to return
 USHORT Reserved;
 ULONG TotalParameterCount;      Total parameter bytes being sent
 ULONG TotalDataCount;          Total data bytes being sent
 ULONG MaxParameterCount;        Max parameter bytes to return
 ULONG MaxDataCount;             Max data bytes to return
 ULONG ParameterCount;           Parameter bytes sent this buffer
 ULONG ParameterOffset;          Offset (from header start) to Parameters
 ULONG DataCount;                Data bytes sent this buffer
 ULONG DataOffset;               Offset (from header start) to data
 UCHAR SetupCount;               Count of setup words
 USHORT Function;                The transaction function code
 UCHAR Buffer[1];
 USHORT Setup[SetupWordCount];   Setup words
 USHORT ByteCount;               Count of data bytes
 UCHAR Pad1[];                   Pad to LONG
 UCHAR Parameters[               Parameter bytes
    ParameterCount];
 UCHAR Pad2[];                   Pad to LONG
 UCHAR Data[DataCount];          Data bytes

The interim server response will consist of two fields:

UCHAR WordCount;   \ Count of parameter words = 0
USHORT ByteCount;  \ Count of data bytes = 0

The following list describes the format of the TRANSACTION secondary client request:

Secondary Client Request           Description
=========================          ============
 UCHAR WordCount;                   Count of parameter words = 18
 UCHAR Reserved[3];                 MUST BE ZERO
 ULONG TotalParameterCount;         Total parameter bytes being sent
 ULONG TotalDataCount;              Total data bytes being sent
 ULONG ParameterCount;              Parameter bytes sent this buffer
 ULONG ParameterOffset;             Offset (from header start) to
                                     Parameters
 ULONG ParameterDisplacement;       Specifies the offset from the start
                                     of the overall parameter block to
                                     the parameter bytes that are
                                     contained in this message
 ULONG DataCount;                   Data bytes sent this buffer
 ULONG DataOffset;                  Offset (from header start) to data
 ULONG DataDisplacement;            Specifies the offset from the start
                                     of the overall data block to the
                                     data bytes that are contained in
                                     this message
 UCHAR Reserved1;
 USHORT ByteCount;                  Count of data bytes
 UCHAR Pad1[];                      Pad to LONG
 UCHAR Parameters[                  Parameter bytes
    ParameterCount];
 UCHAR Pad2[];                      Pad to LONG
 UCHAR Data[DataCount];             Data bytes

And, the fields of the server response are described in the following list:

Server Response                Description
================               ============
 UCHAR WordCount;               Count of data bytes; value = 18 +
                                 SetupCount
 UCHAR Reserved[3];
 ULONG TotalParameterCount;     Total parameter bytes being sent
 ULONG TotalDataCount;          Total data bytes being sent
 ULONG ParameterCount;          Parameter bytes sent this buffer
 ULONG ParameterOffset;         Offset (from header start) to
                                 Parameters
 ULONG ParameterDisplacement;   Specifies the offset from the start
                                 of the overall parameter block to
                                 the parameter bytes that are
                                 contained in this message
 ULONG DataCount;               Data bytes sent this buffer
 ULONG DataOffset;              Offset (from header start) to data
 ULONG DataDisplacement;        Specifies the offset from the start
                                 of the overall data block to the
                                 data bytes that are contained in
                                 this message
 UCHAR SetupCount;              Count of setup words
 USHORT Setup[SetupWordCount];  Setup words
 USHORT ByteCount;              Count of data bytes
 UCHAR Pad1[];                  Pad to LONG
 UCHAR Parameters[              Parameter bytes
    ParameterCount];
 UCHAR Pad2[];                  Pad to SHORT or LONG
 UCHAR Data[DataCount];         Data bytes

The transaction Setup information and/or Parameters define functions specific to a particular resource on a particular server. Therefore the functions supported are not defined by the transaction sub-protocol. The transaction protocol simply provides a means of delivering them and retrieving the results.

The number of bytes needed in order to perform the transaction request may be more than will fit in a single buffer.

At the time of the request, the client knows the number of parameter and data bytes expected to be sent and passes this information to the server via the primary request (TotalParameterCount and TotalDataCount). This may be reduced by lowering the total number of bytes expected (TotalParameterCount and TotalDataCount) in each (if any) secondary request.

When the amount of parameter bytes received (total of each ParameterCount) equals the total amount of parameter bytes expected (smallest TotalParameterCount) received, then the server has received all the parameter bytes.

Likewise, when the amount of data bytes received (total of each DataCount) equals the total amount of data bytes expected (smallest TotalDataCount) received, then the server has received all the data bytes.

The parameter bytes should normally be sent first followed by the data bytes. However, the server knows where each begins and ends in each buffer by the offset fields (ParameterOffset and DataOffset) and the length fields (ParameterCount and DataCount). The displacement of the bytes (relative to start of each) is also known (ParameterDisplacement and DataDisplacement). Thus the server is able to reassemble the parameter and data bytes should the individual requests be received out of sequence.

If all parameter bytes and data bytes fit into a single buffer, then no interim response is expected and no secondary request is sent.

The client knows the maximum amount of data bytes and parameter bytes which may be returned by the server (from MaxParameterCount and MaxDataCount of the request). Thus the client initializes its bytes expected variables to these values. The server then informs the client of the actual amounts being returned via each message of the server response (TotalParameterCount and TotalDataCount). The server may reduce the expected bytes by lowering the total number of bytes expected (TotalParameterCount and/or TotalDataCount) in each (any) response.

When the amount of parameter bytes received (total of each ParameterCount) equals the total amount of parameter bytes expected (smallest TotalParameterCount) received, then the client has received all the parameter bytes.

Likewise, when the amount of data bytes received (total of each DataCount) equals the total amount of data bytes expected (smallest TotalDataCount) received, then the client has received all the data bytes.

The parameter bytes should normally be returned first followed by the data bytes. However, the client knows where each begins and ends in each buffer by the offset fields (ParameterOffset and DataOffset) and the length fields (ParameterCount and DataCount). The displacement of the bytes (relative to start of each) is also known (ParameterDisplacement and DataDisplacement). The client is able to reassemble the parameter and data bytes should the server responses be received out of sequence.

The flow for these transactions over a connection oriented transport is:

The flow for the transaction protocol when the request parameters and data do not all fit in a single buffer is:

The flow for the transaction protocol when the request parameters and data do all fit in a single buffer is:

The primary transaction request through the final response make up the complete transaction exchange, thus the Tid, Pid, Uid and Mid must remain constant and can be used as appropriate by both the server and the client. Of course, other SMB requests may intervene as well.

There are (at least) three ways that actual server responses have been observed to differ from what might be expected. First, some servers will send Pad bytes to move the DataOffset to a 2-or 4-byte boundary even if there are no data bytes; the point here is that the ByteCount must be used instead of ParameterOffset plus ParameterCount to infer the actual message length. Second, some servers always return MaxParameterCount bytes even if the particular Transact2 has no parameter response. Finally, in case of an error, some servers send the “traditional WordCount==0/ByteCount==0” response while others generate a Transact response format.

DCE/RPC documents were defined by the Open Group (TOG) used to be called the X/open group. CIFS uses DCE/RPC to process Server and User management information, like logon information, Local Security, Account management, Server/Workstation services and CIFS networking management functions (like browsing and domain controller management). DCE/RPC are implemented on top of SMB. SMB protocol is used as a transport for the DCE/RPC protocol. DCE/RPC uses Protocol Data Unit (PDU) fragments to communicate. The PDUs are totally independent of the SMB transmission size. So PDU can span over multiple SMB transmission boundaries and multiple PDUs can be transmitted in a single SMB transmission. Name Pipe are used as the transmission vehicle. Once and Named Pipe is opened all the DCE/RPC calls related to that Name Pipe will be written and read through SMB_COM_TRANSCATION operation. SMB_COM_TRANSACTION will communicate to the Name Pipe with as much PDU fragments it can contains, the rest of the fragments will follow with either SMBReadX or SMBWriteX. Some of the RPC calls are defined at Appendix E.

The “smb com transaction” style subprotocols are used mostly as MS RPC commands for managing the server and the client. Mail Slots are used for broadcasting and informing the other nodes on the networks. Named Pipes are mostly used for RPC. The details of the use of these RPCs are outside of the scope of this document. The following section describes the data format, but not the content of the content of the RPC. After the client or the server has open a Name Pipe the RPC are communicated using that pipe.

Pipe Handle State Bits
       5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0
       B E * * T T R R |--- Icount --|
where:
    B - Blocking
        0 => reads/writes block if no data available
        1 => reads/writes return immediately if no data
    E - Endpoint
    0 => client end of pipe
        1 => server end of pipe
    TT - Type of pipe
        00 => pipe is a byte stream pipe
        01 => pipe is a message pipe
    RR - Read Mode
        00 => Read pipe as a byte stream
        01 => Read messages from pipe
    Icount - 8-bit count to control pipe instancing

Pipe Handle State Bits
       5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0
       B * * * * * R R 0 0 0 0 0 0 0 0
where:
    B - Blocking
        0 => reads/writes block if no data available
        1 => reads/writes return immediately if no data
    RR - Read Mode
        00 => Read pipe as a byte stream
        01 => Read messages from pipe

The following list describes the format of the NEGOTIATE client request:

Client Request          Description
===============         ============
 UCHAR WordCount;        Count of parameter words = 0
 USHORT ByteCount;       Count of data bytes; min = 2
 struct {
   UCHAR BufferFormat;   0x02 -- Dialect
   UCHAR DialectName[];  ASCII null-terminated string
 } Dialects[];

The Client sends a list of dialects with which it can communicate. The response is a selection of one of those dialects (numbered 0 through n) or -1 (hex FFFF) indicating that none of the dialects were acceptable. The negotiate message is binding on the virtual circuit and must be sent. One and only one negotiate message may be sent, subsequent negotiate requests will be rejected with an error response and no action will be taken.

The protocol does not impose any particular structure to the dialect strings. Implementers of particular protocols may choose to include, for example, version numbers in the string.

If the server does not understand any of the dialect strings, or if PC NETWORK PROGRAM 1.0 is the chosen dialect, the response format is:

Server Response           Description
================          ============
 UCHAR WordCount;          Count of parameter words = 1
 USHORT DialectIndex;      Index of selected dialect
 USHORT ByteCount;         Count of data bytes = 0

If the chosen dialect is greater than core up to and including LANMAN2.1, the protocol response format is:

Server Response                Description
================               ============
 UCHAR WordCount;               Count of parameter words = 13
 USHORT DialectIndex;           Index of selected dialect
 USHORT SecurityMode;           Security mode:
                                 bit 0: 0 = share, 1 = user
                                 bit 1: 1 = use challenge/response
                                 authentication
 USHORT MaxBufferSize;          Max transmit buffer size (>= 1024)
 USHORT MaxMpxCount;            Max pending multiplexed requests
 USHORT MaxNumberVcs;           Max VCs between client and server
 USHORT RawMode;                Raw modes supported:
                                 bit 0: 1 = Read Raw supported
                                 bit 1: 1 = Write Raw supported
 ULONG SessionKey;              Unique token identifying this session
 SMB_TIME ServerTime;           Current time at server
 SMB_DATE ServerDate;           Current date at server
 USHORT ServerTimeZone;         Current time zone at server
 USHORT EncryptionKeyLength;    MUST BE ZERO if not LM2.1
                                 dialect
 USHORT Reserved;               MUST BE ZERO
 USHORT ByteCount;              Count of data bytes
 UCHAR EncryptionKey[];         The challenge encryption key
 STRING PrimaryDomain[];        The server's primary domain

MaxBufferSize is the size of the largest message which the client can legitimately send to the server.

If bit0 of the Flags field is set in the negotiate response, this indicates the server supports the obsolescent SMB_COM_LOCK_AND_READ and SMB_COM_WRITE_AND_UNLOCK client requests.

If the SecurityMode field indicates the server is running in user mode, the client must send appropriate SMB_COM_SESSION_SETUP_ANDX requests before the server will allow the client to access resources. If the SecurityMode field indicates the client should use challenge/response authentication, the client should use the authentication mechanism specified in the Section 2.8.

Clients using the “MICROSOFT NETWORKS 1.03” dialect use a different form of raw reads than documented here, and servers are better off setting RawMode in this response to 0 for such sessions.

If the negotiated dialect is “DOS LANMAN2.1” or “LANMAN2.1”, then PrimaryDomain string should be included in this response.

If the negotiated dialect is NT LM 0.12, the response format is:

Server Response                Description
================               ============
 UCHAR WordCount;               Count of parameter words = 17
 USHORT DialectIndex;           Index of selected dialect
 UCHAR SecurityMode;            Security mode:
                                 bit 0: 0 = share, 1 = user
                                 bit 1: 1 = encrypt passwords
                                 bit 2: 1 = Security Signatures
                                  (SMB sequence numbers) enabled
                                 bit 3: 1 = Security Signatures
                                  (SMB sequence numbers) required
 USHORT MaxMpxCount;             Max pending outstanding requests
 USHORT MaxNumberVcs;            Max VCs between client and server
 ULONG MaxBufferSize;            Max transmit buffer size
 ULONG MaxRawSize;               Maximum raw buffer size
 ULONG SessionKey;               Unique token identifying this session
 ULONG Capabilities;             Server capabilities
 ULONG SystemTimeLow;            System (UTC) time of the server (low)
 ULONG SystemTimeHigh;           System (UTC) time of the server (high)
 USHORT ServerTimeZone;          Time zone of server (minutes from UTC)
 CHAR EncryptionKeyLength;       Length of encryption key
 USHORT ByteCount;               Count of data bytes
 UCHAR EncryptionKey[];          The challenge encryption key;
                                 Present only for Non Extended Security i.e.,
                                 CAP_EXTENDED_SECURITY is off in the Capabilities
                                  field
 UCHAR OemDomainName[];          The name of the domain (in OEM chars);
                                 Present Only for Non Extended Security i.e.,
                                  CAP_EXTENDED_SECURITY is off in the Capabilities
                                  field
 UCHAR GUID[16];                 A globally unique identifier assigned to the
                                  server; Present only when
                                  CAP_EXTENDED_SECURITY is on in Capabilities field
 UCHAR SecurityBlob[];           Opaque Security Blob associated with the
                                  security package if CAP_EXTENDED_SECURITY
                                   is on in the Capabilities field; else challenge
                                  for CIFS challenge/response authentication

In addition to the definitions above, MaxBufferSize is the size of the largest message which the client can legitimately send to the server. If the client is using a connectionless protocol, MaxBufferSize must be set to the smaller of the server’s internal buffer size and the amount of data which can be placed in a response packet.

MaxRawSize specifies the maximum message size the server can send or receive for the obsolescent SMB_COM_WRITE_RAW or SMB_COM_READ_RAW requests.

Connectionless clients must set Sid to 0 in the SMB request header.

The Capabilities field allows the server to tell the client what it supports. The client must not ignore any capabilities specified by the server. The bit definitions are:

Undefined bit MUST be set to zero by servers, and MUST be ignored by clients.

Extended security exchanges provide a means of supporting arbitrary authentication protocols within CIFS. Security blobs are opaque to the CIFS protocol; they are messages in some authentication protocol that has been agreed upon by client and server by some out of band mechanism, for which CIFS merely functions as a transport. When CAP_EXTENDED_SECURITY is negotiated, the server includes a first security blob in its response; subsequent security blobs are exchanged in SMB_COM_SESSION_SETUP_ANDX requests and responses until the authentication protocol terminates.

If the negotiated dialect is NT LM 0.12, then the capabilities field of the Negotiate protocol response indicates whether the server supports Unicode. The server is not required to support Unicode. Unicode is supported in Win9x and NT clients. If Unicode is not supported by the server then some localized of these clients may experience unexpected behavior with filenames, resource names and user names.

ASCII defines the values of 128 characters (0x00 through 0x7F). The remaining 128 values (0x80 through 0xFF) are mapped into different DOS Code Pages (aka the OEM character set). Different localized clients may use different code pages. (For example, Code Page 437 is the default in English based systems). Clients can create file and folder names in their default code page that follows the file naming rules and may contain both ASCII and non-ASCII characters.

SUCCESS/SUCCESS
ERRSRV/ERRerror

This SMB is used to further “Set up” the session normally just established via the negotiate protocol.

One primary function is to perform a “user logon” in the case where the server is in user level security mode. The Uid in the SMB header is set by the client to be the userid desired for the AccountName and validated by the AccountPassword.

Client Request                Description
===============               ============
 UCHAR WordCount;              Count of parameter words = 10
 UCHAR AndXCommand;            Secondary (X) command; 0xFF = none
 UCHAR AndXReserved;           Reserved (must be 0)
 USHORT AndXOffset;            Offset to next command WordCount
 USHORT MaxBufferSize;         Client maximum buffer size
 USHORT MaxMpxCount;           Actual maximum multiplexed pending requests
 USHORT VcNumber;              0 = first (only), nonzero=additional
                                          VC number
 ULONG SessionKey;             Session key (valid iff VcNumber != 0)
 USHORT PasswordLength;        Account password size
 ULONG Reserved;               Must be 0
 USHORT ByteCount;             Count of data bytes; min = 0
 UCHAR AccountPassword[];      Account Password
 STRING AccountName[];         Account Name
 STRING PrimaryDomain[];       Client's primary domain
 STRING NativeOS[];            Client's native operating system
 STRING NativeLanMan[];        Client's native LAN Manager type

Server Response               Description
================              ============
 UCHAR WordCount;              Count of parameter words = 3
 UCHAR AndXCommand;            Secondary (X) command; 0xFF =
                                 none
 UCHAR AndXReserved;           Reserved (must be 0)
 USHORT AndXOffset;            Offset to next command WordCount
 USHORT Action;                Request mode:
                                bit0 = logged in as GUEST
 USHORT ByteCount;             Count of data bytes
 STRING NativeOS[];            Server's native operating system
 STRING NativeLanMan[];        Server's native LAN Manager type
 STRING PrimaryDomain[];       Server's primary domain

Client Request                Description
===============               ============
 UCHAR WordCount;              Count of parameter words = 12
 UCHAR AndXCommand;            Secondary (X) command; 0xFF = none
 UCHAR AndXReserved;           Reserved (must be 0)
 USHORT AndXOffset;            Offset to next command WordCount
 USHORT MaxBufferSize;         Client's maximum buffer size
 USHORT MaxMpxCount;           Actual maximum multiplexed pending
                                requests
 USHORT VcNumber;              0 = first (only), nonzero=additional
                                VC number
 ULONG SessionKey;             Session key (valid iff VcNumber != 0)
 USHORT SecurityBlobLength;    Length of opaque security blob
 ULONG Reserved;               Must be 0
 ULONG Capabilities;           Client capabilities
 USHORT ByteCount;             Count of data bytes; min = 0
 UCHAR SecurityBlob[];         The opaque security blob
 STRING NativeOS[];            Client's native operating system,
                                Unicode
 STRING NativeLanMan[];        Client's native LAN Manager type,
                                Unicode

Server Response               Description
================              ============
 UCHAR WordCount;              Count of parameter words = 4
 UCHAR AndXCommand;            Secondary (X) command; 0xFF =
                                none
 UCHAR AndXReserved;           Reserved (must be 0)
 USHORT AndXOffset;            Offset to next command WordCount
 USHORT Action;                Request mode:
                                bit0 = logged in as GUEST
 USHORT SecurityBlobLength;    Length of Security Blob that
                                follows in a later field
 USHORT ByteCount;             Count of data bytes
 UCHAR SecurityBlob[];         SecurityBlob of length specified
                                by the field, SecurityBlobLength
 STRING NativeOS[];            Server's native operating system
 STRING NativeLanMan[];        Server's native LAN Manager type
 STRING PrimaryDomain[];       Server's primary domain

Client Request                Description
===============               ============
 UCHAR WordCount;              Count of parameter words = 13
 UCHAR AndXCommand;            Secondary (X) command; 0xFF = none
 UCHAR AndXReserved;           Reserved (must be 0)
 USHORT AndXOffset;            Offset to next command WordCount
 USHORT MaxBufferSize;         Client's maximum buffer size
 USHORT MaxMpxCount;           Actual maximum multiplexed pending
                                requests
 USHORT VcNumber;              0 = first (only), nonzero=additional
                                VC number
 ULONG SessionKey;             Session key (valid iff VcNumber != 0)
 USHORT                        Account password size, ANSI
    CaseInsensitivePasswordLength;
 USHORT                        Account password size, Unicode
    CaseSensitivePasswordLength;
 ULONG Reserved;               Must be 0
 ULONG Capabilities;           Client capabilities
 USHORT ByteCount;             Count of data bytes; min = 0
 UCHAR                         Account Password, ANSI
    CaseInsensitivePassword[];
 UCHAR                         Account Password, Unicode
    CaseSensitivePassword[];
 UCHAR Reserved2               Present if Unicode negotiated to even byte
                               boundary
 STRING AccountName[];         Account Name, Unicode
  STRING PrimaryDomain[];      Client's primary domain, Unicode
  STRING NativeOS[];           Client's native operating system,
                                Unicode
  STRING NativeLanMan[];       Client's native LAN Manager type,
                                Unicode

SMB_COM_TREE_CONNECT_ANDX                SMB_COM_OPEN
SMB_COM_OPEN_ANDX                        SMB_COM_CREATE
SMB_COM_CREATE_NEW                       SMB_COM_CREATE_DIRECTORY
SMB_COM_DELETE                           SMB_COM_DELETE_DIRECTORY
SMB_COM_FIND                             SMB_COM_FIND_UNIQUE
SMB_COM_COPY                             SMB_COM_RENAME
SMB_COM_NT_RENAME                        SMB_COM_CHECK_DIRECTORY
SMB_COM_QUERY_INFORMATION                SMB_COM_SET_INFORMATION
SMB_COM_NO_ANDX_COMMAND                  SMB_COM_OPEN_PRINT_FILE
SMB_COM_GET_PRINT_QUEUE                  SMB_COM_TRANSACTION

ERRSRV/ERRerror - No NEG_PROT issued
ERRSRV/ERRbadpw - Password not correct for given username
ERRSRV/ERRtoomanyuids - Maximum number of users per session exceeded
ERRSRV/ERRnosupport - Chaining of this request to the previous is not
supported

This SMB is the inverse of SMB_COM_SESSION_SETUP_ANDX.

Client Request                Description
===============               ============
 UCHAR WordCount;              Count of parameter words = 2
 UCHAR AndXCommand;            Secondary (X) command; 0xFF =
                                none
 UCHAR AndXReserved;           Reserved (must be 0)
 USHORT AndXOffset;            Offset to next command WordCount
 USHORT ByteCount;             Count of data bytes = 0

The server response is:

Server Response               Description
================              ============
 UCHAR WordCount;              Count of parameter words = 2
 UCHAR AndXCommand;            Secondary (X) command; 0xFF =
                                none
 UCHAR AndXReserved;           Reserved (must be 0)
 USHORT AndXOffset;            Offset to next command WordCount
 USHORT ByteCount;             Count of data bytes = 0

The user represented by Uid in the SMB header is logged off. The server closes all files currently open by this user, and invalidates any outstanding requests with this Uid.

SMB_COM_SESSION_SETUP_ANDX is the only valid AndXCommand for this SMB.

ERRSRV/invnid - TID was invalid
ERRSRV/baduid - UID was invalid

The TREE_CONNECT_ANDX client request is defined below:

Client Request               Description
===============              ============
 UCHAR WordCount;             Count of parameter words = 4
 UCHAR AndXCommand;           Secondary (X) command; 0xFF = none
 UCHAR AndXReserved;          Reserved (must be 0)
 USHORT AndXOffset;           Offset to next command WordCount
 USHORT Flags;                Additional information
                               bit 0 set = Disconnect Tid
 USHORT PasswordLength;       Length of Password[]
 USHORT ByteCount;            Count of data bytes; min = 3
 UCHAR Password[];            Password
 STRING Path[];               Server name and share name
 STRING Service[];            Service name

The serving machine verifies the combination and returns an error code or an identifier. The full name is included in this request message and the identifier identifying the connection is returned in the Tid field of the SMB header. The Tid field in the client request is ignored. The meaning of this identifier (Tid) is server specific; the client must not associate any standard meaning to it.

If the negotiated dialect is LANMAN1.0 or later, then it is a protocol violation for the client to send this message prior to a successful SMB_COM_SESSION_SETUP_ANDX, and the server ignores Password.

If the negotiated dialect is prior to LANMAN1.0 and the client has not sent a successful SMB_COM_SESSION_SETUP_ANDX request when the tree connect arrives, a user level security mode server must nevertheless validate the client’s credentials as discussed earlier in this document.

Path follows UNC style syntax, that is to say it is encoded as \servershare and it indicates the name of the resource to which the client wishes to connect.

Because Password may be an authentication response, it is a variable length field with the length specified by PasswordLength. If authentication is not being used, Password should be a null terminated ASCII string with PasswordLength set to the string size including the terminating null.

The server can enforce whatever policy it desires to govern share access. Typically, if the server is paused, administrative privilege is required to connect to any share; if the server is not paused, administrative privilege is required only for administrative shares (C$, etc.). Other such policies may include valid times of day, software usage license limits, number of simultaneous server users or share users, etc.

The Service component indicates the type of resource the client intends to access. Valid values are:

If bit0 of Flags is set, the tree connection to Tid in the SMB header should be disconnected. If this tree disconnect fails, the error should be ignored.

If the negotiated dialect is earlier than DOS LANMAN2.1, the response to this SMB is:

Server Response               Description
================              ============
 UCHAR WordCount;              Count of parameter words = 2
 UCHAR AndXCommand;            Secondary (X) command; 0xFF = none
 UCHAR AndXReserved;           Reserved (must be 0)
 USHORT AndXOffset;            Offset to next command WordCount
 USHORT ByteCount;             Count of data bytes; min = 3

If the negotiated is DOS LANMAN2.1 or later, the response to this SMB is:

Server Response               Description
================              ============
 UCHAR WordCount;              Count of parameter words = 3
 UCHAR AndXCommand;            Secondary (X) command; 0xFF = none
 UCHAR AndXReserved;           Reserved (must be 0)
 USHORT AndXOffset;            Offset to next command WordCount
 USHORT OptionalSupport;       Optional support bits
                                SMB_SUPPORT_SEARCH_BITS = 0x0001
                               Exclusive search bits
                                ("MUST HAVE BITS") supported
                                SMB_SHARE_IS_IN_DFS = 0x0002
 USHORT ByteCount;             Count of data bytes; min = 3
 UCHAR Service[];              Service type connected (Always ANSII)
 STRING NativeFileSystem[];    Native file system for this tree

NativeFileSystem is the name of the filesystem. Expected values include FAT, NTFS, etc.

Some servers negotiate “DOS LANMAN2.1” dialect or later and still send the “downlevel” (i.e. wordcount==2) response. Valid AndX following commands are:

SMB_COM_OPEN               SMB_COM_OPEN_ANDX        SMB_COM_CREATE
SMB_COM_CREATE_NEW        SMB_COM_CREATE_DIRECTORY  SMB_COM_DELETE
SMB_COM_DELETE_DIRECTORY  SMB_COM_FIND              SMB_COM_COPY
SMB_COM_FIND_UNIQUE        SMB_COM_RENAME
SMB_COM_CHECK_DIRECTORY    SMB_COM_QUERY_INFORMATION
SMB_COM_GET_PRINT_QUEUE    SMB_COM_OPEN_PRINT_FILE
SMB_COM_TRANSACTION        SMB_COM_NO_ANDX_CMD
SMB_COM_SET_INFORMATION    SMB_COM_NT_RENAME

ERRDOS/ERRnomem
ERRDOS/ERRbadpath
ERRDOS/ERRinvdevice
ERRSRV/ERRaccess
ERRSRV/ERRbadpw
ERRSRV/ERRinvnetname

This message informs the server that the client no longer wishes to access the resource connected via a prior SMB_COM_TREE_CONNECT or SMB_COM_TREE_CONNECT_ANDX.

Client Request               Description
===============              ============
 UCHAR WordCount;             Count of parameter words = 0
 USHORT ByteCount;            Count of data bytes = 0

The resource sharing connection identified by Tid in the SMB header is logically disconnected from the server. Tid is invalidated; it will not be recognized if used by the client for subsequent requests. All locks, open files, etc. created on behalf of Tid are released.

Server Response              Description
================             ============
 UCHAR WordCount;             Count of parameter words = 0
 USHORT ByteCount;            Count of data bytes = 0

ERRSRV/ERRinvnid
ERRSRV/ERRbaduid

This transaction requests information about a filesystem on the server. Its format is:

Client Request            Value
================          ======
WordCount                 15
TotalParameterCount       2 or 4
MaxSetupCount             0
SetupCount                1 or 2
Setup[0]                  TRANS2_QUERY_FS_INFORMATION

The request’s parameter block encodes InformationLevel (a USHORT), describing the level of filesystem info that should be returned. Values for InformationLevel are specified in the table below.

The filesystem is identified by Tid in the SMB header.

MaxDataCount in the transaction request must be large enough to accommodate the response.

The encoding of the response parameter block depends on the InformationLevel requested. Information levels whose values are greater than 0x102 are mapped to corresponding operating system calls (NtQueryVolumeInformationFile calls) by the server. The two levels below 0x102 are described below. The requested information is placed in the Data portion of the transaction response.

The following sections describe the InformationLevel dependent encoding of the data part of the transaction response.

InformationLevel
Data Block Encoding    Description
====================   ============
ULONG idFileSystem;     File system identifier (NT server always returns 0)
ULONG cSectorUnit;      Number of sectors per allocation unit
ULONG cUnit;            Total number of allocation units
ULONG cUnitAvail;       Total number of available allocation units
USHORT cbSector;        Number of bytes per sector

InformationLevel
Data Block Encoding    Description
====================   ============
ULONG ulVsn;            Volume serial number
UCHAR cch;              Number of characters in Label
STRING Label;           The volume label

InformationLevel
Data Block Encoding    Description
====================   ============
SMB_TIME                Volume Creation Time
ULONG                   Volume Serial Number
ULONG Length of         Volume Label in bytes
BYTE                    Reserved
BYTE                    Reserved
STRING Label;           The volume label

InformationLevel
Data Block Encoding    Description
====================   ============
LARGE_INTEGER           Total Number of Allocation units on the Volume
LARGE_INTEGER           Number of free Allocation units on the Volume
ULONG                   Number of sectors in each Allocation unit
ULONG                   Number of bytes in each sector

InformationLevel
Data Block Encoding    Description
====================   ======
ULONG DeviceType;       Values as specified below
ULONG                   Characteristics of the device; Values as specified below

FILE_DEVICE_BEEP                0x00000001
FILE_DEVICE_CD_ROM              0x00000002
FILE_DEVICE_CD_ROM_FILE_SYSTEM  0x00000003
FILE_DEVICE_CONTROLLER          0x00000004
FILE_DEVICE_DATALINK            0x00000005
FILE_DEVICE_DFS                 0x00000006
FILE_DEVICE_DISK                0x00000007
FILE_DEVICE_DISK_FILE_SYSTEM    0x00000008
FILE_DEVICE_FILE_SYSTEM         0x00000009
FILE_DEVICE_INPORT_PORT         0x0000000a
FILE_DEVICE_KEYBOARD            0x0000000b
FILE_DEVICE_MAILSLOT            0x0000000c
FILE_DEVICE_MIDI_IN             0x0000000d
FILE_DEVICE_MIDI_OUT            0x0000000e
FILE_DEVICE_MOUSE               0x0000000f
FILE_DEVICE_MULTI_UNC_PROVIDER  0x00000010
FILE_DEVICE_NAMED_PIPE          0x00000011
FILE_DEVICE_NETWORK             0x00000012
FILE_DEVICE_NETWORK_BROWSER     0x00000013
FILE_DEVICE_NETWORK_FILE_SYSTEM 0x00000014
FILE_DEVICE_NULL                0x00000015
FILE_DEVICE_PARALLEL_PORT       0x00000016
FILE_DEVICE_PHYSICAL_NETCARD    0x00000017
FILE_DEVICE_PRINTER             0x00000018
FILE_DEVICE_SCANNER             0x00000019
FILE_DEVICE_SERIAL_MOUSE_PORT   0x0000001a
FILE_DEVICE_SERIAL_PORT         0x0000001b
FILE_DEVICE_SCREEN              0x0000001c
FILE_DEVICE_SOUND               0x0000001d
FILE_DEVICE_STREAMS             0x0000001e
FILE_DEVICE_TAPE                0x0000001f
FILE_DEVICE_TAPE_FILE_SYSTEM    0x00000020
FILE_DEVICE_TRANSPORT           0x00000021
FILE_DEVICE_UNKNOWN             0x00000022
FILE_DEVICE_VIDEO               0x00000023
FILE_DEVICE_VIRTUAL_DISK        0x00000024
FILE_DEVICE_WAVE_IN             0x00000025
FILE_DEVICE_WAVE_OUT            0x00000026
FILE_DEVICE_8042_PORT           0x00000027
FILE_DEVICE_NETWORK_REDIRECTOR  0x00000028
FILE_DEVICE_BATTERY             0x00000029
FILE_DEVICE_BUS_EXTENDER        0x0000002a
FILE_DEVICE_MODEM               0x0000002b
FILE_DEVICE_VDM                 0x0000002c

FILE_REMOVABLE_MEDIA            0x00000001
FILE_READ_ONLY_DEVICE           0x00000002
FILE_FLOPPY_DISKETTE            0x00000004
FILE_WRITE_ONE_MEDIA            0x00000008
FILE_REMOTE_DEVICE              0x00000010
FILE_DEVICE_IS_MOUNTED          0x00000020
FILE_VIRTUAL_VOLUME             0x00000040

InformationLevel
Data Block Encoding               Description
====================              ============
ULONG                             File System Attributes;
                                   possible values described below
LONG                              Maximum length of each file name component
                                   in number of bytes
ULONG                             Length, in bytes, of the name of the file system
STRING                            Name of the file system

FILE_CASE_SENSITIVE_SEARCH      0x00000001
FILE_CASE_PRESERVED_NAMES       0x00000002
FILE_PERSISTENT_ACLS            0x00000004
FILE_FILE_COMPRESSION           0x00000008
FILE_VOLUME_QUOTAS              0x00000010
FILE_DEVICE_IS_MOUNTED          0x00000020
FILE_VOLUME_IS_COMPRESSED       0x00008000

InformationLevel
Data Block Encoding               Description
====================              ============
UNIT16 MajorVersionNumber;        Major version of CIFS UNIX supported by
                                   server
UNIT16 MinorVersionNumber;        Minor version of CIFS UNIX supported by
                                   server
LARGE_INTEGER Capability;         Capabilities of CIFS UNIX support by
                                   Server

Where Capability is the sum of the following:

InformationLevel
Data Block Encoding               Description
====================              ============
LARGE_INTEGER                     CreationTime; Volume creation time - NT TIME.
LARGE_INTEGER                     ModifyTime; Volume Modify time - NT TIME.
LARGE_INTEGER                     BackUpTime; Volume was last Backup time - NT TIME.
                                  Defaults to Create Time.
ULONG                             NmAlBlks; The number of allocation blocks in the
                                  volume
ULONG                             AlBlkSiz; The allocation block size (in bytes) Must
                                  be in multiple of 512 bytes
ULONG                             FreeBks; The number of unused allocations blocks on
                                  the volume
UCHAR [32];                       FndrInfo[32]; Information used by the finder that is
                                  always in Big Endian.
                                      Bytes 0-3 File Type
                                          If a file default to 'TEXT' otherwise
                                  default to zero
                                      Bytes 4-7 File Creator
                                          If a file default to 'dosa' otherwise
                                  default to zero
                                      Bytes 8-9 a UWORD flags field
                                          If hidden item set this UWORD to 0x4000
                                  else defaults to zero
                                      All other bytes should default to zero and are
                                  only changeable by the Macintosh
LONG                              NmFls; The number of files in the root directory;
                                  Zero if not known
LONG                              NmRtDirs; The number of directories in the root
                                  directory; Zero if not known
LONG                              FilCnt; The number of files on the volume; Zero if
                                  not known
LONG                              DirCnt; The number of directories on the volume;
                                  Zero if not known
LONG                              MacSupportFlags; Must be zero unless you support the
                                  other Macintosh options

ERRSRV/invnid - TID was invalid
ERRSRV/baduid - UID was invalid
ERRHRD/ERRnotready - The file system has been removed
ERRHRD/ERRdata - Disk I/O error
ERRSRV/ERRaccess - User does not have rights to perform this operation
ERRSRV/ERRinvdevice - Resource identified by TID is not a file system

This request is used to test the connection to the server, and to see if the server is still responding. The client request is defined as:

Client Request               Description
===============              ============
 UCHAR WordCount;             Count of parameter words = 1
 USHORT EchoCount;            Number of times to echo data back
 USHORT ByteCount;            Count of data bytes; min = 1
 UCHAR Buffer[1];             Data to echo

And, the server response is:

Server Response              Description
================             ============
 UCHAR WordCount;             Count of parameter words = 1
 USHORT SequenceNumber;       Sequence number of this echo
 USHORT ByteCount;            Count of data bytes; min = 4
 UCHAR Buffer[1];             Echoed data

Each response echoes the data sent, though ByteCount may indicate “no data”. If EchoCount is zero, no response is sent.

Tid in the SMB header is ignored, so this request may be sent to the server even if there are no valid tree connections to the server.

The flow for the ECHO protocol is:

ERRSRV/ERRbaduid    - UID was invalid
ERRSRV/ERRnoaccess  - session has not been established
ERRSRV/ERRnosupport - ECHO function is not supported

This SMB allows a client to cancel a request currently pending at the server. The client request is defined as:

Client Request               Description
===============              ============
 UCHAR WordCount;             No words are sent (== 0)
 USHORT ByteCount;            No bytes (==0)

The Sid, Uid, Pid, Tid, and Mid fields of the SMB are used to locate an pending server request from this session. If a pending request is found, it is “hurried along” which may result in success or failure of the original request. No other response is generated for this SMB.

This command is used to create or open a file or a directory. The client request is defined as:

Client Request                 Description
===============                ============
UCHAR WordCount;               Count of parameter words = 24
UCHAR AndXCommand;             Secondary command; 0xFF = None
UCHAR AndXReserved;            Reserved (must be 0)
USHORT AndXOffset;             Offset to next command WordCount
UCHAR Reserved;                Reserved (must be 0)
USHORT NameLength;             Length of Name[] in bytes
ULONG Flags;                   Create bit set:
                                   0x02 - Request an oplock
                                   0x04 - Request a batch oplock
                                   0x08 - Target of open must be directory
ULONG RootDirectoryFid;        If non-zero, open is relative to
                                   this directory
ACCESS_MASK DesiredAccess;     Access desired (See Section 3.8 for an
                                   explanation of this field)
LARGE_INTEGER AllocationSize;  Initial allocation size
ULONG ExtFileAttributes;       File attributes
ULONG ShareAccess;             Type of share access
ULONG CreateDisposition;       Action if file does/does not exist
ULONG CreateOptions;           Options to use if creating a file
ULONG ImpersonationLevel;      Security QOS information
UCHAR SecurityFlags;           Security tracking mode flags:
                                   0x1 - SECURITY_CONTEXT_TRACKING
                                   0x2 - SECURITY_EFFECTIVE_ONLY
USHORT ByteCount;              Length of byte parameters
STRING Name[];                 File to open or create

The Name parameter contains the full path from the tree connect point unless the RootDirectoryFid is used. To use the RootDirectoryFid perform a NT_CREATE_ANDX to open the directory and then use the returned Fid for subsequent NT_CREATE_ANDX calls to open/create files within that directory.

The DesiredAccess parameter is specified in section 3.8, Access Mask Encoding. If no value is specified, an application can still query attributes without actually accessing the file.

The ExtFileAttributes parameter specifies the file attributes and flags for the file. The parameter’s value is the sum of allowed attributes and flags defined in section 3.12, Extended File Attribute Encoding.

The ShareAccess field specifies how the file can be shared. This parameter must be some combination of the following values:

The CreateDisposition parameter can contain one of the following values:

The ImpersonationLevel parameter can contain one or more of the following values:

The SecurityFlags parameter can have either of the following two flags set:

The server response to the NT_CREATE_ANDX request is as follows:

Server Response                Description
================               ============
UCHAR WordCount;               Count of parameter words = 26
UCHAR AndXCommand;             0xFF = None
UCHAR AndXReserved;            MUST BE ZERO
USHORT AndXOffset;             Offset to next command WordCount
UCHAR OplockLevel;             The oplock level granted:
                                       0 - No oplock granted
                                       1 - Exclusive oplock granted
                                       2 - Batch oplock granted
                                       3 - Level II oplock granted
USHORT Fid;                    The file ID
ULONG CreateAction;            The action taken
TIME CreationTime;             The time the file was created
TIME LastAccessTime;           The time the file was accessed
TIME LastWriteTime;            The time the file was last written
TIME ChangeTime;               The time the file was last changed
ULONG ExtFileAttributes;       The file attributes
LARGE_INTEGER AllocationSize;  The number of byes allocated
LARGE_INTEGER EndOfFile;       The end of file offset
USHORT FileType;
USHORT DeviceState;            State of IPC device (e.g. pipe)
BOOLEAN Directory;             TRUE if this is a directory
USHORT ByteCount;              = 0
The following SMBs may follow SMB_COM_NT_CREATE_ANDX:
SMB_COM_READ    SMB_COM_READ_ANDX
SMB_COM_IOCTL

ERRDOS codes
------------
ERRbadfile
ERRbadpath
ERRnofids
ERRnoaccess
ERRnomem
ERRbadaccess
ERRbadshare
ERRfileexists
ERRquota

ERRSRV codes
------------
ERRaccess
ERRinvdevice
ERRinvtid
ERRbaduid

This command is used to create or open a file or a directory, when EAs or an SD must be applied to the file. The parameter and data blocks for the client’s CREATE request include the following data:

Request Parameter Block Encoding                Description
=================================               ============
 ULONG Flags;                                    Creation flags (see below)
 ULONG RootDirectoryFid;                         Optional directory for relative
                                                  open
 ACCESS_MASK DesiredAccess;                      Access desired (See Section 3.8 for
                                                    an explanation of this field)
 LARGE_INTEGER AllocationSize;                   The initial allocation size in
                                                  bytes, if file created
 ULONG ExtFileAttributes;                        The extended file attributes
 ULONG ShareAccess;                              The share access
 ULONG CreateDisposition;                        Action if file does/does not exist
 ULONG CreateOptions;                            Options for creating a new file
 ULONG SecurityDescriptorLength;                 Length of SD in bytes
 ULONG EaLength;                                 Length of EA in bytes
 ULONG NameLength;                               Length of name in characters
 ULONG ImpersonationLevel;                       Security QOS information
 UCHAR SecurityFlags;                            Security QOS information
 STRING Name[NameLength];                        The name of the file (not NULL
                                                  terminated)

Request Data Block Encoding                     Description
============================                    ============
 UCHAR SecurityDescriptor[
    SecurityDescriptorLength];
 UCHAR ExtendedAttributes[EaLength];

The Flags parameter can contain one of the following values:

The parameter block of the server response is defined as:

Response Parameter Block Encoding        Description
==================================       ============
 UCHAR OplockLevel;                       The oplock level granted
 UCHAR Reserved;
 USHORT Fid;                              The file ID
 ULONG CreateAction;                      The action taken
 ULONG EaErrorOffset;                     Offset of the EA error
 TIME CreationTime;                       The time the file was created
 TIME LastAccessTime;                     The time the file was accessed
 TIME LastWriteTime;                      The time the file was last written
 TIME ChangeTime;                         The time the file was last changed
 ULONG ExtFileAttributes;                 The file attributes
 LARGE_INTEGER AllocationSize;            The number of byes allocated
 LARGE_INTEGER EndOfFile;                 The end of file offset
 USHORT FileType;
 USHORT DeviceState;                      State of IPC device (e.g. pipe)
 BOOLEAN Directory;                       TRUE if this is a directory

See the description of NT_CREATE_ANDX (section 4.2.1) for further definition of the CREATE request/response parameters.

ERRDOS codes
------------
ERRbadfile
ERRbadpath
ERRnofids
ERRnoaccess
ERRnomem
ERRbadaccess
ERRbadshare
ERRfileexists
ERRquota

ERRSRV codes
------------
ERRaccess
ERRinvdevice
ERRinvtid
ERRbaduid

The server creates a data file in the specified Directory, relative to Tid in the SMB header, and assigns a unique name to it. The client request and server response for the command are:

Client Request                    Description
===============                   ============
 UCHAR WordCount;                  Count of parameter words = 3
 USHORT reserved;                  Ignored by the server
 UTIME CreationTime;               New file's creation time stamp
 USHORT ByteCount;                 Count of data bytes; min = 2
 UCHAR BufferFormat;               0x04
 STRING DirectoryName[];           Directory name

Server Response                   Description
================                  ============
 UCHAR WordCount;                  Count of parameter words = 1
 USHORT Fid;                       File handle
 USHORT ByteCount;                 Count of data bytes; min = 2
 UCHAR BufferFormat;               0x04
 STRING Filename[];                File name

Fid is the returned handle for future file access. Filename is the name of the file that was created within the requested Directory. It is opened in compatibility mode with read/write access for the client.

Support of CreationTime by the server is optional.

ERRDOS codes
------------
ERRbadfile
ERRbadpath
ERRnofids
ERRnoaccess
ERRnomem
ERRbadaccess
ERRbadshare
ERRfileexists
ERRquota

ERRSRV codes
------------
ERRaccess
ERRinvdevice
ERRinvtid
ERRbaduid

Client requests a file read, using the SMB fields specified below:

Client Request                    Description
===============                 ============
 UCHAR WordCount;                Count of parameter words = 10 or 12
 UCHAR AndXCommand;              Secondary (X) command; 0xFF = none
 UCHAR AndXReserved;             Reserved (must be 0)
 USHORT AndXOffset;              Offset to next command WordCount
 USHORT Fid;                     File handle
 ULONG Offset;                   Offset in file to begin read
 USHORT MaxCount;                Max number of bytes to return
 USHORT MinCount;                Reserved for obsolescent requests
 ULONG MaxCountHigh;             High 16 bits of MaxCount if
                                  CAP_LARGE_READX; else MUST BE ZERO
 USHORT Remaining;               Reserved for obsolescent requests
 ULONG OffsetHigh;               Upper 32 bits of offset (only if
                                  WordCount is 12)
 USHORT ByteCount;               Count of data bytes = 0

And, the server response is:

Server Response                  Description
================                 ============
 UCHAR WordCount;                 Count of parameter words = 12
 UCHAR AndXCommand;               Secondary (X) command; 0xFF = none
 UCHAR AndXReserved;              Reserved (must be 0)
 USHORT AndXOffset;               Offset to next command WordCount
 USHORT Remaining;                Reserved -- must be -1
 USHORT DataCompactionMode;
 USHORT Reserved;                 Reserved (must be 0)
 USHORT DataLength;               Number of data bytes (min = 0)
 USHORT DataOffset;               Offset (from header start) to data
 USHORT DataLengthHigh;           High 16 bits of number of data bytes if
                                   CAP_LARGE_READX; else MUST BE ZERO
 USHORT Reserved[4];              Reserved (must be 0)
 USHORT ByteCount;                Count of data bytes; ignored if
                                   CAP_LARGE_READX
 UCHAR Pad[];
 UCHAR Data[DataLength];           Data from resource

If the file specified by Fid has any portion of the range specified by Offset and MaxCount locked for exclusive use by a client with a different connection or Pid, the request will fail with ERRlock.

If the negotiated dialect is NT LM 0.12 or later, the client may use the 12 parameter word version of the request. This version allows specification of 64 bit file offsets.

If CAP_LARGE_READX was indicated by the server in the negotiate protocol response, the request’s MaxCount field may exceed the negotiated buffer size if Fid refers to a disk file. The server may arbitrarily elect to return fewer than MaxCount bytes in response.

The SMB server MAY use the MinCount on named-pipe calls to determine if this is a blocking read or a non-blocking read. (Non blocking is determined by MinCount = 0). Note that for blocking reads, the length required to succeed is actually the ReadLength and not the MinCount. (So in some sense, MinCount has become more of an indicator of blocking vs. non-blocking rather than a true length)

The following SMBs may follow SMB_COM_READ_ANDX:

SMB_COM_CLOSE

ERRDOS/ERRnoaccess
ERRDOS/ERRbadfid
ERRDOS/ERRlock
ERRDOS/ERRbadaccess
ERRSRV/ERRinvid
ERRSRV/ERRbaduid

Client requests a file write, using the SMB fields specified below:

Client Request                  Description
===============                 ============
UCHAR WordCount;                 Count of parameter words = 12 or 14
UCHAR AndXCommand;               Secondary (X) command; 0xFF = none
UCHAR AndXReserved;              Reserved (must be 0)
USHORT AndXOffset;               Offset to next command WordCount
USHORT Fid;                      File handle
ULONG Offset;                    Offset in file to begin write
ULONG Reserved;                  Must be 0
USHORT WriteMode;                Write mode bits:
                                      0 - write through
USHORT Remaining;                Bytes remaining to satisfy request
USHORT DataLengthHigh;           High 16 bits of data length if
                                      CAP_LARGE_WRITEX; else MUST BE ZERO
USHORT DataLength;               Number of data bytes in buffer (>=0)
USHORT DataOffset;               Offset to data bytes
ULONG OffsetHigh;                Upper 32 bits of offset (only present if
                                      WordCount = 14)
USHORT ByteCount;                Count of data bytes; ignored if
                                      CAP_LARGE_WRITEX
UCHAR Pad[];                     Pad to SHORT or LONG
UCHAR Data[DataLength];          Data to write

And, the server response is:

Server Response                   Description
================                  ============
UCHAR WordCount;                  Count of parameter words = 6
UCHAR AndXCommand;                Secondary (X) command; 0xFF = none
UCHAR AndXReserved;               Reserved (must be 0)
USHORT AndXOffset;                Offset to next command WordCount
USHORT Count;                     Number of bytes written
USHORT Remaining;                 Reserved
ULONG Reserved;
USHORT ByteCount;                 Count of data bytes = 0

If the file specified by Fid has any portion of the range specified by Offset and MaxCount locked for shared or exclusive use by a client with a different connection or Pid, the request will fail with ERRlock.

A ByteCount of 0 does not truncate the file. Rather a zero length write merely transfers zero bytes of information to the file. A request such as SMB_COM_WRITE must be used to truncate the file.

If WriteMode has bit0 set in the request and Fid refers to a disk file, the response is not sent from the server until the data is on stable storage.

If the negotiated dialect is NT LM 0.12 or later, the 14 word format of this SMB may be used to access portions of files requiring offsets expressed as 64 bits. Otherwise, the OffsetHigh field must be omitted from the request.

If CAP_LARGE_WRITEX was indicated by the server in the negotiate protocol response, the request’s DataLength field may exceed the negotiated buffer size if Fid refers to a disk file.

The following are the valid AndXCommand values for this SMB:

SMB_COM_READ              SMB_COM_READ_ANDX
SMB_COM_LOCK_AND_READ     SMB_COM_WRITE_ANDX
SMB_COM_CLOSE

ERRDOS/ERRnoaccess
ERRDOS/ERRbadfid
ERRDOS/ERRlock
ERRDOS/ERRbadaccess
ERRSRV/ERRinvid
ERRSRV/ERRbaduid

SMB_COM_LOCKING_ANDX allows both locking and/or unlocking of file range(s). A description of the fields of the client request, and explanations for several of the fields are provided below.

Client Request                  Description
===============                 ============
 UCHAR WordCount;                Count of parameter words = 8
 UCHAR AndXCommand;              Secondary (X) command; 0xFF = none
 UCHAR AndXReserved;             Reserved (must be 0)
 USHORT AndXOffset;              Offset to next command WordCount
 USHORT Fid;                     File handle
 UCHAR LockType;                 See LockType table below
 UCHAR OplockLevel;              The new oplock level
 ULONG Timeout;                  Milliseconds to wait for unlock
 USHORT NumberOfUnlocks;         Number of unlock range structures that
                                  follow
 USHORT NumberOfLocks;           Number of lock range structures that
                                          follow
 USHORT ByteCount;               Count of data bytes
 LOCKING_ANDX_RANGE Unlocks[];   Unlock ranges
 LOCKING_ANDX_RANGE Locks[];     Lock ranges

The LockType parameter can take on one of the values in the following table:

The format for LOCKING_ANDX_RANGE is:

USHORT Pid;                  PID of process "owning" lock
ULONG Offset;                Offset to bytes to [un]lock
ULONG Length;                Number of bytes to [un]lock

And, for a large file, it is:

USHORT Pid;                  PID of process "owning" lock
USHORT Pad;                  Pad to DWORD align (Must be zero)
ULONG OffsetHigh;            Offset to bytes to [un]lock (high)
ULONG OffsetLow;             Offset to bytes to [un]lock (low)
ULONG LengthHigh;            Number of bytes to [un]lock
                              (high)
ULONG LengthLow;             Number of bytes to [un]lock (low)

The server response is:

Server Response                  Description
================                 ============
 UCHAR WordCount;                 Count of parameter words = 2
 UCHAR AndXCommand;               Secondary (X) command; 0xFF = none
 UCHAR AndXReserved;              Reserved (must be 0)
 USHORT AndXOffset;               Offset to next command WordCount
 USHORT ByteCount;                Count of data bytes = 0

Locking is a simple mechanism for excluding other processes read/write access to regions of a file. The locked regions can be anywhere in the logical file. Locking beyond end-of-file is permitted. Lock conflicts (overlapping lock-requests) should cause the server to refuse the lock to the latter requestor. Any process using the Fid specified in this request's Fid has access to the locked bytes; other processes will be denied the locking of the same bytes.

The proper method for using locks is not to rely on being denied read or write access on any of the read/write protocols but rather to attempt the locking protocol and proceed with the read/write only if the locks succeeded.

Locking a range of bytes will fail if any subranges or overlapping ranges are locked, if the PID/UID of the requestor is not the same, and the locks are not compatible. In other words, if any of the specified bytes are already locked, the lock will fail.

If NumberOfUnlocks is non-zero, the Unlocks vector contains NumberOfUnlocks elements. Each element requests that a lock at Offset of Length be released. If NumberOfLocks is nonzero, the Locks vector contains NumberOfLocks elements. Each element requests the acquisition of a lock at Offset of Length.

Timeout is the maximum amount of time to wait for the byte range(s) specified to become unlocked. A timeout value of 0 indicates that the server should fail immediately if any lock range specified is locked. A timeout value of -1 indicates that the server should wait as long as it takes for each byte range specified to become unlocked so that it may be again locked by this protocol. Any other value of smb_timeout specifies the maximum number of milliseconds to wait for all lock range(s) specified to become available.

If any of the lock ranges timeout because of the area to be locked is already locked (or the lock fails), the other ranges in the protocol request which were successfully locked as a result of this protocol will be unlocked (either all requested ranges will be locked when this protocol returns to the client or none).

If LockType has the LOCKING_ANDX_SHARED_LOCK flag set, the lock is specified as a shared lock. Locks for both read and write (where LOCKING_ANDX_SHARED_LOCK is clear) should be prohibited, but other shared locks should be permitted. If shared locks can not be supported by a server, the server should map the lock to a lock for both read and write. Closing a file with locks still in force causes the locks to be released in no defined order.

If LockType has the LOCKING_ANDX_LARGE_FILES flag set and if the negotiated protocol is NT LM 0.12 or later, then the Locks and Unlocks vectors are in the Large File LOCKING_ANDX_RANGE format. This allows specification of 64 bit offsets for very large files.

If the one and only member of the Locks vector has the LOCKING_ANDX_CANCEL_LOCK flag set in the LockType field, the client is requesting the server to cancel a previously requested, but not yet responded to, lock.

If LockType has the LOCKING_ANDX_CHANGE_LOCKTYPE flag set, the client is requesting that the server atomically change the lock type from a shared lock to an exclusive lock or vice versa. If the server can not do this in an atomic fashion, the server must reject this request.

(Note: Windows NT and Windows 95 servers do not support this capability.)

If the client sends an SMB_LOCKING_ANDX SMB with the LOCKING_ANDX_OPLOCK_RELEASE flag set and NumberOfLocks is zero, the server does not send a response. The entire message sent and received including the optional second protocol must fit in the negotiated maximum transfer size. The following are the only valid SMB commands for AndXCommand for SMB_COM_LOCKING_ANDX:

SMB_COM_READ               SMB_COM_READ_ANDX
SMB_COM_WRITE              SMB_COM_WRITE_ANDX
SMB_COM_FLUSH

ERRDOS/ERRbadfile
ERRDOS/ERRbadfid
ERRDOS/ERRlock
ERRDOS/ERRinvdevice
ERRSRV/ERRinvid
ERRSRV/ERRbaduid

The seek message is sent to set the current file pointer for Fid.

Client Request                   Description
===============                  =================================
UCHAR WordCount;                 Count of parameter words = 4
 USHORT Fid;                      File handle
 USHORT Mode;                      Seek mode:
                                         0 = from start of file
                                         1 = from current position
                                         2 = from end of file
 LONG Offset;                      Relative offset
 USHORT ByteCount;                Count of data bytes = 0

The “current position” reflects the offset plus data length specified in the previous read, write, or seek request; and the pointer set by this command will be replaced by the offset specified in the next read, write, or seek command.

Server Response                  Description
================                 ============
 UCHAR WordCount;                 Count of parameter words = 2
 ULONG Offset;                            Offset from start of file
 USHORT ByteCount;                Count of data bytes = 0

The response returns the new file pointer in Offset, which is expressed as the offset from the start of the file, and may be beyond the current end of file. An attempt to seek to before the start of file sets the current file pointer to start of the file.

This request should generally be issued only by clients wishing to find the size of a file, because all read and write requests include the read or write file position as part of the SMB. This request is inappropriate for very large files, as the offsets specified are only 32 bits. A seek that results in an Offset that cannot be expressed in 32 bits returns the least significant.

ERRDOS/ERRbadfid
ERRDOS/ERRnoaccess
ERRSRV/ERRinvdevice
ERRSRV/ERRinvid
ERRSRV/ERRbaduid

The flush SMB is sent to ensure all data and allocation information for the corresponding file has been written to stable storage. When the Fid has a value -1 (hex FFFF), the server performs a flush for all file handles associated with the client and Pid. The response is not sent until the writes are complete.

Client Request                  Description
===============                 =================================
 UCHAR WordCount;                Count of parameter words = 1
 USHORT Fid;                     File handle
 USHORT ByteCount;               Count of data bytes = 0

This client request is probably expensive to perform at the server, since the server’s operating system is generally scheduling disk writes is a way which is optimal for the system’s read and write activity integrated over the entire population of clients. This message from a client “interferes” with the server’s ability to optimally schedule the disk activity; clients are discouraged from overuse of this SMB request.

Server Response                   Description
================                  ============
 UCHAR WordCount;                  Count of parameter words = 0
 USHORT ByteCount;                 Count of data bytes = 0

ERRDOS/ERRbadfid
ERRSRV/ERRinvid
ERRSRV/ERRbaduid

The close message is sent to invalidate a file handle for the requesting process. All locks or other resources held by the requesting process on the file should be released by the server. The requesting process can no longer use Fid for further file access requests.

Client Request                  Description
===============                 ============
 UCHAR WordCount;                Count of parameter words = 3
 USHORT Fid;                     File handle
 UTIME LastWriteTime;            Time of last write
 USHORT ByteCount;               Count of data bytes = 0

If LastWriteTime is 0, the server should allow its local operating system to set the file’s times. Otherwise, the server should set the time to the values requested. Failure to set the times, even if requested by the client in the request message, should not result in an error response from the server.

If Fid refers to a print spool file, the file should be spooled to the printer at this time.

Server Response                   Description
================                  ============
 UCHAR WordCount;                  Count of parameter words = 0
 USHORT ByteCount;                 Count of data bytes = 0

ERRDOS/ERRbadfid
ERRSRV/ERRinvdevice
ERRSRV/ERRinvid
ERRSRV/ERRbaduid

Close the file and perform a tree disconnect.

The close and tree disconnect message is sent to close a file and perform a tree disconnect. All locks or other resources held by the requesting process on the file should be released by the server. The requesting process can no longer use Fid for further file access requests. The server will perform a TREE_DISCONNECT after completing the close operation. The requesting process can no longer use Tid for further access requests.

Client Request                     Description
===============                    ============
 UCHAR WordCount;                    Count of parameter words = 3
 USHORT Fid;                         File handle
 UTIME LastWriteTime;                Time of last write
 USHORT ByteCount;                   Count of data bytes = 0

If LastWriteTime is 0, the server should allow its local operating system to set the file’s times. Otherwise, the server should set the time to the values requested. Failure to set the times, even if requested by the client in the request message, should not result in an error response from the server.

If Fid refers to a print spool file, the file should be spooled to the printer at this time.

Server Response                   Description
================                  ============
 UCHAR WordCount;                  Count of parameter words = 0
 USHORT ByteCount;                 Count of data bytes = 0

ERRDOS/ERRbadfid
ERRSRV/ERRinvdevice
ERRSRV/ERRinvid
ERRSRV/ERRbaduid

The delete file message is sent to delete a data file. The appropriate Tid and additional pathname are passed. Read only files may not be deleted, the read-only attribute must be reset prior to file deletion.

Client Request                   Description
===============                  ============
UCHAR WordCount;                  Count of parameter words = 1
USHORT SearchAttributes;
USHORT ByteCount;                 Count of data bytes; min = 2
UCHAR BufferFormat;               0x04
STRING FileName[];                File name

Multiple files may be deleted in response to a single request as SMB_COM_DELETE supports wildcards.

SearchAttributes indicates the attributes that the target file(s) must have. If the attribute is zero then only normal files are deleted. If the system file or hidden attributes are specified, then the delete is inclusive - both the specified type(s) of files and normal files are deleted. File attributes are described in the “Attribute Encoding” section (3.11) of this document.

If bit0 of the Flags2 field of the SMB header is set, a pattern is passed in, and the file has a long name, then the passed pattern must match the long file name for the delete to succeed. If bit0 is clear, a pattern is passed in, and the file has a long name, then the passed pattern must match the file’s short name for the deletion to succeed.

Server Response                   Description
================                  ============
UCHAR WordCount;                   Count of parameter words = 0
USHORT ByteCount;                  Count of data bytes = 0

ERRDOS/ERRbadpath
ERRDOS/ERRbadfile
ERRDOS/ERRnoaccess
ERRHRD/ERRnowrite
ERRSRV/ERRaccess
ERRSRV/ERRinvdevice
ERRSRV/ERRinvid
ERRSRV/ERRbaduid

The rename file message is sent to change the name of a file.

Client Request                   Description
===============                  ============
UCHAR WordCount;                  Count of parameter words = 1
USHORT SearchAttributes;          Target file attributes
USHORT ByteCount;                 Count of data bytes; min = 4
UCHAR BufferFormat1;              0x04
STRING OldFileName[];             Old file name
UCHAR BufferFormat2;              0x04
STRING NewFileName[];             New file name

The file, OldFileName, must exist and NewFileName must not. Both pathnames must be relative to the Tid specified in the request. Open files may be renamed.

Multiple files may be renamed in response to a single request as Rename File supports wildcards in the file name (last component of the pathname).

SearchAttributes indicates the attributes that the target file(s) must have. If SearchAttributes is zero then only normal files are renamed. If the system file or hidden attributes are specified then the rename is inclusive - both the specified type(s) of files and normal files are renamed. The encoding of SearchAttributes is described in section 3.11 - File Attribute Encoding.

Server Response                   Description
================                  ============
UCHAR WordCount;                   Count of parameter words = 0
USHORT ByteCount;                  Count of data bytes = 0

ERRDOS/ERRbadpath
ERRDOS/ERRbadfile
ERRDOS/ERRnoaccess
ERRDOS/ERRdiffdevice
ERRHRD/ERRnowrite
ERRSRV/ERRaccess
ERRSRV/ERRinvdevice
ERRSRV/ERRinvid
ERRSRV/ERRbaduid

The rename file message is sent to change the name of a file. This version of RENAME supports NT link tracking info.

Client Request                   Description
===============                  ============
 UCHAR WordCount;                 Count of parameter words = 4
 USHORT SearchAttributes;
 USHORT Information Level;
 ULONG ClusterCount;
 USHORT ByteCount;                Count of data bytes; min = 4
 UCHAR Buffer[1];                  Buffer containing:
                                    UCHAR BufferFormat1 0x04 -- ASCII
                                    UCHAR OldFileName[] Old file name
                                    UCHAR BufferFormat2 0x04 -- ASCII
                                    UCHAR NewFileName[] New file name

Server Response                  Description
================                 ============
 UCHAR WordCount;                 Count of parameter words = 0
 USHORT ByteCount;                Count of data bytes = 0
 UCHAR Buffer[1];                 empty

Non-NT machines can ignore the extra parameters (InfoLevel, SearchAttributes, ClusterCount) and just perform a normal rename.

ERRDOS codes
------------
ERRbadfile
ERRbadpath
ERRnofids
ERRnoaccess
ERRnomem
ERRfileexists

ERRSRV codes
------------
ERRaccess
ERRinvdevice
ERRinvtid
ERRbaduid

The source file is copied to the destination and the source is subsequently deleted.

Client Request                 Description
===============                ============
 UCHAR WordCount;               Count of parameter words = 3
 USHORT Tid2;                   Second (target) file id
 USHORT OpenFunction;           What to do if target file exists
 USHORT Flags;                  Flags to control move operations:
                                 0 - target must be a file
                                 1 - target must be a directory
                                 2 - reserved (must be 0)
                                 3 - reserved (must be 0)
                                 4 - verify all writes
USHORT ByteCount;               Count of data bytes; min = 2
UCHAR Format1;                  0x04
STRING OldFileName[];           Old file name
UCHAR FormatNew;                0x04
STRING NewFileName[];           New file name

OldFileName is copied to NewFileName, then OldFileName is deleted. Both OldFileName and NewFileName must refer to paths on the same server. NewFileName can refer to either a file or a directory. All file components except the last must exist; directories will not be created.

NewFileName can be required to be a file or a directory by the Flags field.

The Tid in the header is associated with the source while Tid2 is associated with the destination. These fields may contain the same or differing valid values. Tid2 can be set to -1 indicating that this is to be the same Tid as in the SMB header. This allows use of the move protocol with SMB_TREE_CONNECT_ANDX.

Server Response                 Description
================                ============
UCHAR WordCount;                 Count of parameter words = 1
USHORT Count;                    Number of files moved
USHORT ByteCount;                Count of data bytes; min = 0
UCHAR ErrorFileFormat;           0x04 (only if error)
STRING ErrorFileName[];          Pathname of file where error
                                  Occurred

The source path must refer to an existing file or files. Wildcards are permitted. Source files specified by wildcards are processed until an error is encountered. If an error is encountered, the expanded name of the file is returned in ErrorFileName. Wildcards are not permitted in NewFileName.

OpenFunction controls what should happen if the destination file exists. If (OpenFunction & 0x30) == 0, the operation should fail if the destination exists. If (OpenFunction & 0x30) == 0x20, the destination file should be overwritten.

ERRDOS/ERRfilexists
ERRDOS/ERRbadfile
ERRDOS/ERRnoaccess
ERRDOS/ERRnofiles
ERRDOS/ERRbadshare
ERRHRD/ERRnowrite
ERRSRV/ERRnoaccess
ERRSRV/ERRinvdevice
ERRSRV/ERRinvid
ERRSRV/ERRbaduid
ERRSRV/ERRnosupport
ERRSRV/ERRaccess

The source file is copied to the target.

Client Request                 Description
===============                ============
 UCHAR WordCount;               Count of parameter words = 3
 USHORT Tid2;                   Second (target) path TID
 USHORT OpenFunction;           What to do if target file exists
 USHORT Flags;                  Flags to control copy operation:
                                 bit 0 - target must be a file
                                 bit 1 - target must be a dir.
                                 bit 2 - copy target mode:
                                  0 = binary, 1 = ASCII
                                 bit 3 - copy source mode:
                                  0 = binary, 1 = ASCII
                                 bit 4 - verify all writes
                                 bit 5 - tree copy
 USHORT ByteCount;              Count of data bytes; min = 2
 UCHAR SourceFileNameFormat;    0x04
 STRING SourceFileName;         Pathname of source file
 UCHAR TargetFileNameFormat;    0x04
 STRING TargetFileName;         Pathname of target file

The file at SourceName is copied to TargetFileName, both of which must refer to paths on the same server.

The Tid in the header is associated with the source while Tid2 is associated with the destination. These fields may contain the same or differing valid values. Tid2 can be set to -1 indicating that this is to be the same Tid as in the SMB header. This allows use of the move protocol with SMB_TREE_CONNECT_ANDX.

Server Response                 Description
================                ============
UCHAR WordCount;                 Count of parameter words = 1
USHORT Count;                    Number of files copied
USHORT ByteCount;                Count of data bytes; min = 0
UCHAR ErrorFileFormat;           0x04 (only if error)
STRING ErrorFileName;

The source path must refer to an existing file or files. Wildcards are permitted. Source files specified by wildcards are processed until an error is encountered. If an error is encountered, the expanded name of the file is returned in ErrorFileName. Wildcards are not permitted in TargetFileName. TargetFileName can refer to either a file or a directory.

The destination can be required to be a file or a directory by the bits in Flags. If neither bit0 nor bit1 are set, the destination may be either a file or a directory. The Flags field also controls the copy mode. In a binary copy for the source, the copy stops the first time an EOF (control-Z) is encountered. In a binary copy for the target, the server must make sure that there is exactly one EOF in the target file and that it is the last character of the file.

If the destination is a file and the source contains wildcards, the destination file will either be truncated or appended to at the start of the operation depending on bits in OpenFunction (see section 3.7). Subsequent files will then be appended to the file.

If the negotiated dialect is LM1.2X002 or later, bit5 of Flags is used to specify a tree copy on the remote server. When this option is selected the destination must not be an existing file and the source mode must be binary. A request with bit5 set and either bit0 or bit3 set is therefore an error. When the tree copy mode is selected, the Count field in the server response is undefined.

ERRDOS/ERRfilexists
ERRDOS/ERRshare
ERRDOS/ERRnofids
ERRDOS/ERRbadfile
ERRDOS/ERRnoaccess
ERRDOS/ERRnofiles
ERRDOS/ERRbadshare
ERRSRV/ERRnoaccess
ERRSRV/ERRinvdevice
ERRSRV/ERRinvid
ERRSRV/ERRbaduid
ERRSRV/ERRaccess

This request is used to get information about a specific file or subdirectory.

Client Request                 Value
===============                ======
 WordCount                      15
 MaxSetupCount                  0
 SetupCount                     1
 Setup[0]                       TRANS2_QUERY_PATH_INFORMATION

The request’s parameter block uses the following format:

Parameter Block Encoding       Description
=========================      ============
 USHORT InformationLevel;       Level of information requested
 ULONG Reserved;                Must be zero
 STRING FileName;               File or directory name

InformationLevels are specified using these values:

The requested information is placed in the Data portion of the transaction response. For the information levels greater than 0x100, the transaction response has 1 parameter word which should be ignored by the client.

The following sections describe the InformationLevel dependent encoding of the data part of the transaction response.

Data Block Encoding            Description
====================           ============
 SMB_DATE CreationDate;         Date when file was created
 SMB_TIME CreationTime;         Time when file was created
 SMB_DATE LastAccessDate;       Date of last file access
 SMB_TIME LastAccessTime;       Time of last file access
 SMB_DATE LastWriteDate;        Date of last write to the file
 SMB_TIME LastWriteTime;        Time of last write to the file
 ULONG DataSize;                File Size
 ULONG AllocationSize;          Size of filesystem allocation unit
 USHORT Attributes;             File Attributes
 ULONG EaSize;                  Size of file's EA information
                                 (SMB_INFO_QUERY_EA_SIZE)

Response Field                 Value
===============                ======
 MaxDataCount                   Length of EAlist found (minimum value is 4)

Parameter Block
Encoding         	       Description
================ 	       ============
 USHORT EaErrorOffset;          Offset into EAList of EA error

Data Block Encoding            Description
====================           ============
 ULONG ListLength;            Length of the remaining data
 UCHAR EaList[];              The extended attributes list

Data Block Encoding            Description
====================           ============
 TIME CreationTime;         Time when file was created
 TIME LastAccessTime;        Time of last file access
 TIME LastWriteTime;         Time of last write to the file
 TIME ChangeTime;            Time when file was last changed
 ULONG Attributes;             File Attributes
 ULONG Pad;                 Undefined

Data Block Encoding            Description
====================           ============
 LARGE_INTEGER AllocationSize;  Allocated size of the file in number
                                 of bytes
 LARGE_INTEGER EndOfFile;       Offset to the first free byte in the
                                 file
 ULONG NumberOfLinks;           Number of hard links to the file
 BOOLEAN DeletePending;         Indicates whether the file is marked
                                 for deletion
 BOOLEAN Directory;             Indicates whether the file is a
                                 Directory

Data Block Encoding            Description
====================           ============
 ULONG EASize;                  Size of the file's extended
                                 attributes in number of bytes

Data Block Encoding            Description
====================           ============
 ULONG FileNameLength;          Length of the file name in number of
                                 bytes
 STRING FileName;               Name of the file

Data Block Encoding                Description
====================               ============
 TIME CreationTime;                Time when file was created
 TIME LastAccessTime;              Time of last file access
 TIME LastWriteTime;               Time of last write to the file
 TIME ChangeTime;                   Time when file was last changed
 USHORT Attributes;                 File Attributes
 LARGE_INTEGER AllocationSize;      Allocated size of the file in number
                                     of bytes
 LARGE_INTEGER EndOfFile;           Offset to the first free byte in the
                                     file
 ULONG NumberOfLinks;               Number of hard links to the file
 BOOLEAN DeletePending;             Indicates whether the file is marked
                                     for deletion
 BOOLEAN Directory;                 Indicates whether the file is a
                                     directory
 LARGE_INTEGER IndexNumber;         A file system unique identifier
 ULONG EASize;                      Size of the file's extended
                                     attributes in number of bytes
 ULONG AccessFlags;                 Access that a caller has to the
                                     file; Possible values and meanings
                                     are specified below
 LARGE_INTEGER IndexNumber1;        A file system unique identifier
 LARGE_INTEGER                     Current byte offset within the file
                                      CurrentByteOffset;
 ULONG Mode;                        Current Open mode of the file handle
                                     to the file; possible values and
                                     meanings are detailed below
 ULONG AlignmentRequirement;        Buffer Alignment required by device;
                                     possible values detailed below
 ULONG FileNameLength;              Length of the file name in number of
                                     bytes
 STRING FileName;                   Name of the file

Data Block Encoding            Description
====================           ============
 ULONG FileNameLength;         Length of the file name in number
                                of bytes
 STRING FileName;              Name of the file

 Data Block Encoding            Description
 ====================           ============
  ULONG NextEntryOffset;         Offset to the next entry (in bytes)
  ULONG StreamNameLength;        Length of the stream name in number
                                  of bytes
  LARGE_INTEGER StreamSize;      Size of the stream in number of
                                  bytes
  LARGE_INTEGER                  Allocated size of the stream in
   StreamAllocationSize;          number of bytes
  STRING FileName;               Name of the stream

NOTE: When more than one data block is returned, the NextEntryOffset is the
offset to the next entry and is 0 for the last entry. STATUS_INVALID_PARAMETER is
returned if file streams are not supported.

Data Block Encoding            Description
====================           ============
 LARGE_INTEGER                  Size of the compressed file in
  CompressedFileSize;            number of bytes
 USHORT CompressionFormat;      A constant signifying the
                                 compression algorithm used. Possible
                                 values are:
                                 0 - There is no compression
                                 2- Compression Format is LZNT
 UCHAR CompressionUnitShift;
 UCHAR ChunkShift;              Stored in log2 format (1 << ChunkShift =
                                 ChunkSizeInBytes)
 UCHAR ClusterShift;            Indicates how much space must be
                                 saved to successfully compress a
                                 compression unit
 UCHAR Reserved[3];

Data Block Encoding            Description  		
==================== 	       ============
 LARGE_INTEGER EndOfFile;      File size
 LARGE_INTEGER NumOfBytes      Number of file system bytes used to store file
 TIME LastStatusChange;        Last time the status of the file was changed.
                                 This is in DCE time.
 TIME LastAccessTime;          Time of last file access. This is DCE time.
 TIME LastModificationTime;    Last modification time. This is DCE time.
 LARGE_INTEGER Uid;            Numeric user id for the owner
 LARGE_INTEGER Gid;            Numeric group id of owner
 ULONG Type;                   Enumeration specifying the file type.
                                0 -- File
                                1 -- Directory
                                2 -- Symbolic Link
                                3 -- Character device
                                4 -- Block device
                                5 -- FIFO
                                6 -- Socket
 LARGE_INTEGER DevMajor;       Major device number if file type is device.
 LARGE_INTEGER DevMinor;       Minor device number if file type is device.
 LARGE_INTEGER UniqueId;       This is a server-assigned unique id for the
                                file. The client will typically map this onto
                                an inode number. The scope of uniqueness is
                                the share.
 LARGE_INTEGER Permissions;    Standard UNIX file permissions
 LARGE_INTEGER Nlinks;         The number of directory entries that map to
                                this entry or number of hard links.

Data Block Encoding            Description
====================           ============
 STRING LinkDest;               Destination for symbolic link

ERRDOS codes
------------
ERRbadfile
ERRbadpath
ERRnoaccess
ERRnomem

ERRSRV codes
------------
ERRaccess
ERRinvdevice
ERRinvtid
ERRbaduid

This request is used to get information about a specific file or subdirectory given a handle to it.

Client Request              Value
===============             ======
 WordCount                   15
 MaxSetupCount               0
 SetupCount                  1
 Setup[0]                    TRANS2_QUERY_FILE_INFORMATION

Parameter Block Encoding    Description
=========================   ============
 USHORT Fid;                 Handle of file for request
 USHORT InformationLevel;    Level of information requested

The available information levels, as well as the format of the response are identical to TRANS2_QUERY_PATH_INFORMATION.

This request is used to set information about a specific file or subdirectory.

Client Request              Value
===============             ======
 WordCount                   15
 MaxSetupCount               0
 SetupCount                  1
 Setup[0]                    TRANS2_SET_PATH_INFORMATION

Parameter Block Encoding    Description
=========================   ============
 USHORT InformationLevel;    Level of information to set
 ULONG Reserved;             Must be zero
 STRING FileName;            File or directory name

The following Information Levels may be set:

The response formats are:

Parameter Block Encoding     Description
=========================    ============
 USHORT Reserved              0

Data Block Encoding          Description
====================         ============
 SMB_DATE CreationDate;       Date when file was created
 SMB_TIME CreationTime;       Time when file was created
 SMB_DATE LastAccessDate;     Date of last file access
 SMB_TIME LastAccessTime;     Time of last file access
 SMB_DATE LastWriteDate;      Date of last write to the file
 SMB_TIME LastWriteTime;      Time of last write to the file
 ULONG DataSize;              File Size
 ULONG AllocationSize;        Size of filesystem allocation
                               unit
 USHORT Attributes;           File Attributes
 ULONG EaSize;                Size of file's EA information
                               (SMB_INFO_QUERY_EA_SIZE)

Response Field               Value
===============              ======
 MaxDataCount                 Length of FEAlist found (minimum value is 4)

Parameter Block		
Encoding                     Description
=========================    ============
 USHORT EaErrorOffset;        Offset into EAList of EA error

Data Block Encoding          Description
====================         ============
 ULONG ListLength;            Length of the remaining data
 UCHAR EaList[];              The extended attributes list

Data Block Encoding          Description
====================         ============
 LARGE_INTEGER EndOfFile;     File size
 LARGE_INTEGER NumOfBytes;     Number of file system bytes used to
                                store file
 TIME LastStatusChange;       Last time the status of the file was
                                changed. This is in DCE time.
 TIME LastAccessTime;         Time of last file access. This is DCE
                                time.
 TIME LastModificationTime;   Last modification time. This is DCE
                                time.
 LARGE_INTEGER Uid;           Numeric user id for the owner
 LARGE_INTEGER Gid;           Numeric group id of owner
 ULONG Type;                  Enumeration specifying the file type.
                                     0 -- File
                                     1 -- Directory
                                     2 -- Symbolic Link
                                     3 -- Character device
                                     4 -- Block device
                                     5 -- FIFO
                                     6 -- Socket
 LARGE_INTEGER DevMajor;      Major device number if file type is
                               device
 LARGE_INTEGER DevMinor;      Minor device number if file type is
                               device
 LARGE_INTEGER UniqueId;      This is a server-assigned unique id
                               for the file. The client will
                               typically map this onto an inode
                               number. The scop of uniqueness is
                               the share
 LARGE_INTEGER Permissions;   Standard UNIX file permissions
 LARGE_INTEGER Nlinks;        The number of directory entries that
                               map to this entry or number of hard
                               links

Data Block Encoding      Description
====================     ============
  STRING LinkDest;         Destination for symbolic link