6 Appendix A: Product Behavior
The information in this specification is applicable to the following Microsoft products or supplemental software. References to product versions include updates to those products.
Windows 2000 operating system
Windows XP operating system
Windows Server 2003 operating system
Windows Server 2003 R2 operating system
Windows Vista operating system
Windows Server 2008 operating system
Windows 7 operating system
Windows Server 2008 R2 operating system
Windows 8 operating system
Windows Server 2012 operating system
Windows 8.1 operating system
Windows Server 2012 R2 operating system
Windows 10 operating system
Windows Server 2016 operating system
Windows Server operating system
Windows Server 2019 operating system
Windows Server 2022 operating system
Windows 11 operating system
Windows Server 2025 operating system
Exceptions, if any, are noted in this section. If an update version, service pack or Knowledge Base (KB) number appears with a product name, the behavior changed in that update. The new behavior also applies to subsequent updates unless otherwise specified. If a product edition appears with the product version, behavior is different in that product edition.
Unless otherwise specified, any statement of optional behavior in this specification that is prescribed using the terms "SHOULD" or "SHOULD NOT" implies product behavior in accordance with the SHOULD or SHOULD NOT prescription. Unless otherwise specified, the term "MAY" implies that the product does not follow the prescription.
<1> Section 1.8: UNIX extensions are not supported by Windows-based SMB clients and servers. The CAP_UNIX capability bit and the Information Level range are reserved to allow third party implementers to collaborate on the definition of these extensions. The development of a common set of extensions has been informally supported by the Storage Networking Industry Association (SNIA). See [SNIA] for SNIA specification on vendor-extension fields.
<2> Section 2.1: The Direct TCP transport can be used by Windows-based SMB clients and servers.
<3> Section 2.1: Windows-based clients and servers use TCP port 445 as the destination TCP port on the SMB server, the well-known port number assigned by IANA to Microsoft-DS.
<4> Section 2.1: Windows 7 and Windows Server 2008 R2 servers without [MS11-048] do not disconnect the connection if the SMB message size exceeds 0x1FFFF bytes.
<5> Section 2.2: When an error occurs, Windows-based SMB servers return an Error Response message unless specifically required to return data, as specified for named pipe read operations and certain I/O control code requests and other exceptions specified in [MS-CIFS]. Windows-based SMB clients expect that an SMB server returns an Error Response, unless otherwise specified. Windows implementations return data along with these error codes:
STATUS_MORE_PROCESSING_REQUIRED on a session setup request
STATUS_BUFFER_OVERFLOW for a read request, IOCTL request, and Query Info request
STATUS_INVALID_PARAMETER or STATUS_INVALID_VIEW_SIZE for CopyChunk IOCTL request return data along with the header
STATUS_STOPPED_ON_SYMLINK includes the symbolic link data
STATUS_BUFFER_TOO_SMALL returns a ULONG containing the required size
<6> Section 2.2.1.1.1: This feature is unavailable in Windows 2000 and Windows XP. When enabled previous versions of files are accessible as read-only.
<7> Section 2.2.1.2.2: This value is not supported in Windows 2000.
<8> Section 2.2.1.2.2: This value is not supported in Windows 2000.
<9> Section 2.2.1.2.2: This value is not supported in Windows 2000.
<10> Section 2.2.1.2.2: This value is not supported in Windows 2000, Windows Server 2003, Windows Server 2003 R2, Windows XP, Windows Vista, or Windows Server 2008.
<11> Section 2.2.1.2.2: This value is not supported in Windows 2000, Windows Server 2003, Windows Server 2003 R2, Windows XP, Windows Vista, or Windows Server 2008.
<12> Section 2.2.1.2.2: This value is not supported in Windows 2000, Windows Server 2003, Windows Server 2003 R2, Windows XP, Windows Vista, or Windows Server 2008.
<13> Section 2.2.1.2.2: This value is not supported in Windows 2000, Windows Server 2003, Windows Server 2003 R2, Windows XP, Windows Vista, or Windows Server 2008.
<14> Section 2.2.1.3.1: Windows guarantees uniqueness of FileIds across a single volume.
<15> Section 2.2.2.1: If a client request contains an invalid command code, then Windows 2000 Server operating system and Windows XP server fail the requests by sending an error response with an NTSTATUS code of STATUS_SMB_BAD_COMMAND (ERRSRV/ERRbadcommand). Windows XP operating system Service Pack 1 (SP1) and later and Windows Server 2003 operating system and later servers do not respond to such a request, and do not process further requests on that connection.
<16> Section 2.2.2.2: Windows-based clients and servers do not support NT_TRANSACT_CREATE2.
<17> Section 2.2.2.3.1: Windows 2000 Server does not support the SMB_FIND_FILE_ID_FULL_DIRECTORY_INFO and SMB_FIND_FILE_ID_BOTH_DIRECTORY_INFO Information Levels.
<18> Section 2.2.2.3.5: On Windows-based servers, pass-through Information level “FileAllInformation” is mapped to SMB_QUERY_FILE_ALL_INFO, as specified in [MS-CIFS] section 2.2.8.3.10. All other pass-through Information Levels map directly to native Windows NT operating system Information Classes, as specified in [MS-FSCC] sections 2.4 and 2.5. Windows-based servers do not support setting the following NT Information Levels via the pass-through Information Level mechanism.
|
Information level |
Error code |
|---|---|
|
FileLinkInformation |
STATUS_NOT_SUPPORTED |
|
FileMoveClusterInformation |
STATUS_NOT_SUPPORTED |
|
FileTrackingInformation |
STATUS_NOT_SUPPORTED |
|
FileCompletionInformation |
STATUS_NOT_SUPPORTED |
|
FileMailslotSetInformation |
STATUS_NOT_SUPPORTED |
All other Information Levels are passed through to the underlying object store or file system. Refer to [MS-FSCC] sections 2.4 and 2.5 for a further list of Information Levels that are not supported by Windows file systems and the error codes that can be returned.
<19> Section 2.2.2.3.6: These extensions, known as UNIX extensions, are not supported by Windows-based SMB clients and servers. The CAP_UNIX capability bit and the Information Level range specified are reserved to allow third party implementers to collaborate on the definition of these extensions. The development of a common set of extensions has been informally supported by the Storage Networking Industry Association (SNIA).
<20> Section 2.2.2.4: For a detailed listing of possible status codes available on Windows implementations, see [MS-ERREF]. For a list of error codes used by the SMB Version 1.0 Protocol and CIFS Protocol, see [MS-CIFS] section 2.2.2.4.
<21> Section 2.2.3.1: Windows-based servers set the bits in the Flags2 field with the same value(s) that were sent by the client in the request. Windows-based clients ignore this field when they receive the response.
<22> Section 2.2.3.1: Windows clients set this flag in all SMB requests if the client's configuration requires signing. This flag is not applicable to Windows 2000.
<23> Section 2.2.3.1: Windows-based SMB servers always ignore the SMB_FLAGS2_IS_LONG_NAME flag.
<24> Section 2.2.4.1.2: Windows-based servers support the notion of a guest account and set this field based on the defined guest account rights on the server.
<25> Section 2.2.4.1.2: Windows-based SMB servers set this field to an arbitrary value that is ignored on receipt. The servers do not send any data in this message.
<26> Section 2.2.4.2.1: Windows clients always set this field to 0xFFFFFFFF when reading from a Named Pipe or I/O device.
<27> Section 2.2.4.2.1: Windows-based servers support MaxCountHigh, but ignore it if set to 0xFFFF.
<28> Section 2.2.4.5.2.1: Windows defaults to a MaxBufferSize value of 16,644 bytes on server versions of Windows. Windows defaults to a MaxBufferSize value of 4,356 bytes on client versions of Windows.
<29> Section 2.2.4.5.2.1: Windows Server 2008 operating system and later do not support SMB_COM_READ_RAW or SMB_COM_WRITE_RAW and disconnect the client by closing the underlying transport connection if either command is received from the client.
<30> Section 2.2.4.5.2.1: Windows Server 2008 operating system and later do not support SMB_COM_READ_MPX or SMB_COM_WRITE_MPX and disconnect the client by closing the underlying transport connection if either command is received from the client.
<31> Section 2.2.4.5.2.1: Windows-based clients assume that CAP_NT_FIND is set if CAP_NT_SMBS is set.
<32> Section 2.2.4.5.2.1: Windows-based clients and servers take advantage of CAP_INFOLEVEL_PASSTHRU, when available, to prevent the need to map from native file and directory information structures to comparable SMB structures.
<33> Section 2.2.4.5.2.1: With CAP_LARGE_READX enabled, Windows-based servers provide a statically configured maximum read length, which defaults to 64 kilobytes. Windows-based clients and servers support CAP_LARGE_READX, which permits file transfers larger than the negotiated MaxBufferSize.
<34> Section 2.2.4.5.2.1: Windows-based clients and servers support CAP_LARGE_WRITEX, which permits file transfers larger than the negotiated MaxBufferSize.
<35> Section 2.2.4.5.2.1: Windows 2000 and Windows XP clients and servers support CAP_LWIO.
<36> Section 2.2.4.5.2.1: Windows-based clients and servers do not support CAP_UNIX; therefore, this capability is never set.
<37> Section 2.2.4.5.2.1: Windows-based clients and servers do not support CAP_COMPRESSED_DATA, and this capability is never set.
<38> Section 2.2.4.5.2.1: Windows-based servers do not set the CAP_DYNAMIC_REAUTH flag, even if dynamic re-authentication is supported. On Windows XP operating system and later and Windows Server 2003 operating system and later, all clients and servers support dynamic re-authentication.
<39> Section 2.2.4.5.2.1: Windows-based clients and servers do not support CAP_PERSISTENT_HANDLES.
<40> Section 2.2.4.5.2.1: Windows-based clients use the ServerGUID field.
<41> Section 2.2.4.5.2.2: Windows-based servers default to a MaxBufferSize value of 16,644 bytes. Windows-based clients default to a MaxBufferSize value of 4,356 bytes.
<42> Section 2.2.4.5.2.2: Windows-based clients expect 8-byte cryptographic challenges. Windows-based servers provide 8-bit cryptographic challenges.
<43> Section 2.2.4.6.1: Windows-based servers only check for and store a small number of client capabilities:
CAP_UNICODE
CAP_LARGE_FILES
CAP_NT_SMBS
CAP_NT_FIND
CAP_NT_STATUS
CAP_EXTENDED_SECURITY
CAP_LEVEL_II_OPLOCKS
Windows Server 2003 operating system and later also check for CAP_DYNAMIC_REAUTH.
<44> Section 2.2.4.6.1: Windows-based SMB clients set this field based upon the version and service pack level of the Windows operating system. A list of possible values for this field includes the following.
|
Windows OS version |
Native OS string |
|---|---|
|
Windows 2000 |
Windows 5.0 |
|
Windows XP operating system Service Pack 2 (SP2) |
Windows 2002 Service Pack 2 |
|
Windows Server 2003 operating system with Service Pack 2 (SP2) |
Windows Server 2003 3790 Service Pack 2 |
Windows Vista operating system and later and Windows Server 2008 operating system and later set this field to an empty string.
<45> Section 2.2.4.6.1: Windows-based SMB clients set this field based upon the version of the Windows operating system. A list of possible values for this field includes the following:
|
Windows OS version |
NativeLanMan string |
|---|---|
|
Windows 2000 |
Windows 2000 LAN Manager |
|
Windows XP SP2 |
Windows 2002 5.1 |
|
Windows Server 2003 |
Windows Server 2003 5.2 |
Windows Vista operating system and later and Windows Server 2008 operating system and later set this field to an empty string.
<46> Section 2.2.4.6.2: Windows-based servers terminate the NativeLanMan string with a single null byte if the Pad field in the response is not empty.
<47> Section 2.2.4.7.2: SMB clients on Windows XP operating system and later cache directory information if this bit is set on a share. SMB clients on all server versions of Windows do not cache directory information by default even if this bit is set on a share. Caching directory information by SMB clients on Windows Server 2003 operating system and later can be enabled via a Windows registry setting. Windows 2000 operating system does not support directory caching.
<48> Section 2.2.4.7.2: Windows-based clients and servers support the notion of a guest account and set this field to the access allowed for the guest account.
<49> Section 2.2.4.9.1: Windows 7 operating system and later and Windows Server 2008 R2 operating system and later also support two new CreateOptions flags:
FILE_OPEN_REQUIRING_OPLOCK (0x00010000). Windows Vista operating system and later and Windows Server 2008 operating system and later ignore this bit if set in the request. All other Windows-based SMB servers fail requests with the FILE_OPEN_REQUIRING_OPLOCK option set, and return STATUS_INVALID_PARAMETER in the Status field of the SMB header in the server response.
FILE_DISALLOW_EXCLUSIVE (0x00020000). Windows Vista operating system and later and Windows Server 2008 operating system and later ignore this bit if it is set in the request. All other Windows–based SMB servers fail requests with this option set, and return STATUS_INVALID_PARAMETER in the Status field of the SMB header in the server response.
<50> Section 2.2.4.9.2: Windows-based SMB servers send 50 (0x32) words in the extended response although they set the WordCount field to 0x2A.
<51> Section 2.2.4.9.2: Windows–based servers set the VolumeGUID field to zero; otherwise, this field is uninitialized. The VolumeGUID field is ignored by Windows-based SMB clients.
<52> Section 2.2.4.9.2: Windows–based servers set the FileId field to zero. The FileId field is ignored by Windows-based SMB clients.
<53> Section 2.2.4.9.2: Windows-based servers and clients support the notion of a guest account.
<54> Section 2.2.4.9.2: Windows Server 2003 operating system and later set this field to zero; otherwise, this field can be sent uninitialized.
<55> Section 2.2.5.1: Windows-based clients never send this request. Windows-based servers fail this request with STATUS_INVALID_PARAMETER.
<56> Section 2.2.5.2: Windows-based clients never send this request.
<57> Section 2.2.6.1.1: Windows-based clients do not issue TRANS2_FIND_FIRST2 requests with the special @GMT-* pattern in the FileName field natively. Applications that run on Windows-based clients, however, are allowed to explicitly include the @GMT-* pattern in the pathname that they supply.
<58> Section 2.2.6.1.1: Windows-based clients allow the @GMT-* wildcard to be sent using Information Levels other than SMB_COM_FIND_FILE_BOTH_DIRECTORY_INFO.
<59> Section 2.2.6.4: Support for this subcommand was introduced in Windows 2000.
<60> Section 2.2.7.1.2: Windows–based servers set the VolumeGUID field to zero; otherwise, this field is uninitialized. The VolumeGUID field is ignored by Windows-based SMB clients.
<61> Section 2.2.7.1.2: Windows–based servers set the FileId field to zero. The FileId field is ignored by Windows-based SMB clients.
<62> Section 2.2.7.1.2: Windows-based servers and clients support guest accounts.
<63> Section 2.2.7.2.1: Only Windows Server 2003 operating system with Service Pack 1 (SP1), Windows Server 2003 R2 operating system and later support these new FSCTLs. All other Windows-based servers fail requests that contain these FSCTL codes with STATUS_NOT_SUPPORTED.
<64> Section 2.2.7.2.1: A definitive list of Windows FSCTL and IOCTL control codes and their structures (if any) is specified in [MS-FSCC] section 2.3.
<65> Section 2.2.7.2.1: Only Windows Server 2003 with SP1, Windows Server 2003 R2 operating system and later support this FSCTL. All other Windows-based servers fail the request with STATUS_NOT_SUPPORTED.
<66> Section 2.2.7.2.1: Only Windows Server 2003 with SP1, Windows Server 2003 R2 operating system and later servers support this FSCTL. All other Windows-based servers fail the request with STATUS_NOT_SUPPORTED.
<67> Section 2.2.7.2.1.1: Windows-based clients do not initialize the Reserved field to zero.
<68> Section 2.2.7.2.2.2: Windows-based servers set this field to an arbitrary number of uninitialized bytes.
<69> Section 2.2.8.1.1: Windows-based SMB servers set the FileIndex field to a nonzero value if the underlying object store supports indicating the position of a file within the parent directory.
<70> Section 2.2.8.1.2: The SMB_FIND_FILE_ID_FULL_DIRECTORY_INFO Information Level is not present in Windows 2000 Server and Windows XP.
<71> Section 2.2.8.1.2: Windows-based SMB servers set the FileIndex field to a nonzero value if the underlying object store supports indicating the position of a file within the parent directory.
<72> Section 2.2.8.1.2: Windows-based servers set this field to an arbitrary value.
<73> Section 2.2.8.1.3: The SMB_FIND_FILE_ID_BOTH_DIRECTORY_INFO Information Level is not present in Windows 2000 Server and Windows XP.
<74> Section 2.2.8.1.3: Windows-based SMB servers set the FileIndex field to a nonzero value if the underlying object store supports indicating the position of a file within the parent directory.
<75> Section 2.2.8.2.1: The following attribute flags are removed by the Windows Server 2008 R2 operating system and later SMB server before sending the attribute data block to the client:
FILE_SUPPORTS_TRANSACTIONS
FILE_SUPPORTS_OPEN_BY_FILE_ID
<76> Section 3.2.1.1: Windows 2000 Server supports the Disabled state.
<77> Section 3.2.3: Client.SupportsExtendedSecurity is TRUE for Windows-based clients.
<78> Section 3.2.3: Windows-based SMB clients on Windows 2000, Windows XP, and Windows Vista support 32-bit process IDs and use this field when sending the following SMB messages: SMB_COM_NT_CREATE_ANDX and SMB_COM_OPEN_PRINT_FILE. Windows-based SMB clients on Windows 2000, Windows XP, and Windows Vista also support and use this field when sending SMB_COM_TRANSACTION, SMB_COM_TRANSACTION2, and SMB_COM_TRANSACT messages when the server supports the CAP_NT_SMBS bit. The CAP_NT_SMBS bit is set in the Capabilities field in the SMB_COM_NEGOTIATE response ([MS-CIFS] section 2.2.4.52.2). Windows 7 and later SMB clients do not support 32-bit process IDs and set this field to zero when sending SMB messages. Windows-based SMB servers support 32-bit process IDs when receiving SMB messages.
<79> Section 3.2.4.1.1: Windows XP operating system and later and Windows Server 2003 operating system and later clients scan pathnames for previous version tokens and set the SMB_FLAGS2_REPARSE_PATH flag if a token is found.
<80> Section 3.2.4.2.4: Windows-based SMB clients use the same connection to a server for all authentications other than terminal services. Connections configured for terminal services use one connection per user.
<81> Section 3.2.4.2.4: In an SMB_COM_SESSION_SETUP_ANDX request (section 2.2.4.6.1), Windows-based SMB clients initialize the SMB_Header.SecurityFeatures field to ‘BSRSPYL‘ (0x42 0x53 0x52 0x53 0x50 0x59 0x4C). Windows-based SMB servers ignore this value.
<82> Section 3.2.4.2.4: Windows-based clients implement this option.
Windows-based clients support extended security.
Windows systems implement the first option that is previously described.
<84> Section 3.2.4.2.4.1: Windows-based SMB clients are configured by default to not send plain text passwords. Sending plain text passwords can be configured via a registry setting.
<85> Section 3.2.4.2.5: Windows 2000 client does not request Client.Session.SessionKey protection.
<86> Section 3.2.4.3: Windows-based clients issue an SMB_COM_NT_CREATE_ANDX request for the NT LM 0.12 dialect for which all of the extensions here are described.
<87> Section 3.2.4.3.2: Windows-based clients do not use this flag.
<88> Section 3.2.4.4: Windows-based clients set the Timeout field to 0xFFFFFFFF on pipe reads.
<89> Section 3.2.4.4.1: Windows-based clients issue large reads if the server supports them.
<90> Section 3.2.4.6: Windows-based clients send these requests to the server regardless of the Information Level provided in the request.
<91> Section 3.2.4.11.1: Windows XP and later clients use this FSCTL. Windows 2000-based clients can use this FSCTL if the previous versions down-level application is installed on them.
<92> Section 3.2.4.12: Windows XP operating system Service Pack 3 (SP3), Windows Server 2003 with SP1, Windows Server 2003 R2 operating system and later and Windows Vista operating system and later clients support DFS.
<93> Section 3.2.5.2: Windows-based SMB servers support Extended Security. They all are configured to use SPNEGO, as specified in [RFC4178], as their GSS authentication protocol. Windows operating systems that use extended security send a GSS token (or fragment) if their SPNEGO implementation supports it. See [RFC4178] for details on Windows behavior.
<94> Section 3.2.5.2: When the server completes negotiation and returns the CAP_EXTENDED_SECURITY flag as not set, Windows-based SMB clients query the Key Distribution Center (KDC) to verify whether a service ticket is registered for the given security principal name (SPN). If the query indicates that the SPN is registered with the KDC, then the SMB client terminates the connection and returns an implementation-specific security downgrade error to the caller.
<95> Section 3.2.5.3: The Windows GSS implementation supports raw Kerberos / NTLM messages in the SecurityBlob as described in [MS-AUTHSOD] section 2.1.2.2.
<96> Section 3.2.5.3: Windows Vista operating system with Service Pack 1 (SP1), Windows Server 2008 operating system and later and Windows 7 operating system and later servers fail a non-extended security session setup request with STATUS_INVALID_PARAMETER if the registry key is either missing or set to zero.
<97> Section 3.3.2.1: Windows-based servers implement this timer with a default value of 300 seconds.
<98> Section 3.3.3: SupportsExtendedSecurity is TRUE for Windows-based clients.
<99> Section 3.3.3: Windows Server 2003 with SP1, Windows Server 2003 R2 operating system and later set this value to 256.
<100> Section 3.3.3: Windows Server 2003 with SP1, Windows Server 2003 R2 operating system and later set this value to 1 megabyte.
<101> Section 3.3.3: Windows Server 2003 with SP1, Windows Server 2003 R2 operating system and later set this value to 16 megabytes.
<102> Section 3.3.3: Windows Server 2003 with SP1, Windows Server 2003 R2 operating system and later set this value to 25 seconds.
<103> Section 3.3.4.1.1: Windows-based servers do not respond with an OS/2 error on the wire even if SMB_FLAGS2_NT_STATUS is set in the client request (see [MS-CIFS] section 2.2.3.1). If the negotiated dialect is DOS LANMAN 2.0, DOS LANMAN 2.1, or prior to LANMAN 1.0, an ERROR_GEN_FAILURE error is returned. Otherwise, the following table lists the corresponding DOS error (see [MS-CIFS] section 2.2.2.4 SMB Error Classes and Codes) that is returned:
|
OS/2 Error |
DOS Error |
|---|---|
|
STATUS_OS2_INVALID_LEVEL |
ERRunknownlevel |
|
STATUS_OS2_EA_LIST_INCONSISTENT |
ERRbadealist |
|
STATUS_OS2_NEGATIVE_SEEK |
ERRinvalidseek |
|
STATUS_OS2_NO_MORE_SIDS |
ERROR_NO_MORE_SEARCH_HANDLES |
|
STATUS_OS2_EAS_DIDNT_FIT |
ERROR_EAS_DIDNT_FIT |
|
STATUS_OS2_EA_ACCESS_DENIED |
ERROR_EA_ACCESS_DENIED |
|
STATUS_OS2_CANCEL_VIOLATION |
ERROR_CANCEL_VIOLATION |
|
STATUS_OS2_ATOMIC_LOCKS_NOT_SUPPORTED |
ERROR_ATOMIC_LOCKS_NOT_SUPPORTED |
|
STATUS_OS2_CANNOT_COPY |
ERROR_CANNOT_COPY |
<104> Section 3.3.5.1: Windows XP, Windows 2000, Windows Server 2003, Windows Server 2003 R2, Windows Vista, Windows Server 2008, Windows 7, and Windows Server 2008 R2 fail a TREE_CONNECT_ANDX request to a share that does not allow anonymous access with STATUS_ACCESS_DENIED. All other requests, which require an access check (such as opening a file), are failed with STATUS_INVALID_HANDLE.
<105> Section 3.3.5.1: Windows XP, Windows 2000, Windows Server 2003, Windows Server 2003 R2, Windows Vista, Windows Server 2008, Windows 7, and Windows Server 2008 R2 will fail the request with STATUS_ACCESS_DENIED.
<106> Section 3.3.5.1: Windows XP, Windows 2000, Windows Server 2003, Windows Server 2003 R2, Windows Vista, Windows Server 2008, Windows 7, and Windows Server 2008 R2 will fail the request with STATUS_ACCESS_DENIED.
<107> Section 3.3.5.1.1: SMB servers on Windows Server 2003, Windows Server 2003 R2, Windows Server 2008, Windows Server 2008 R2, and Windows Server 2012 support the SMB_FLAGS2_REPARSE_PATH flag and previous version access. An SMB server on Windows Server 2003 operating system and later parses paths when the flag is not set but only when configured to do so. This flag is used to expose the previous version logic to applications that run on clients whose SMB client does not understand the SMB_FLAGS2_REPARSE_PATH flag and does not set it.
<108> Section 3.3.5.1.2: Windows-based servers grant level II oplocks, even if the client does not request an oplock.
<109> Section 3.3.5.2: Windows-based SMB servers support Extended Security, and are configured to use SPNEGO (as specified in [RFC4178]) as their GSS authentication protocol. Windows operating systems that use extended security send a GSS token (or fragment) if their SPNEGO implementation supports it. For details on Windows behavior, see [RFC4178].
<110> Section 3.3.5.3: Windows 8, Windows Server 2012, Windows 8.1, Windows Server 2012 R2 operating system and later fail the SMB_COM_SESSION_SETUP_ANDX request with STATUS_ACCESS_DENIED if both the EncryptData and RejectUnencryptedAccess registry keys are set to nonzero values.
<111> Section 3.3.5.3: The Windows GSS implementation supports raw Kerberos / NTLM messages in the SecurityBlob as described in [MS-AUTHSOD] section 2.1.2.2. If the client sends a zero length SecurityBlob in the request, the server-initiated SPNEGO exchange will be used.
<112> Section 3.3.5.3: NTLM authentication has no expiration time, so authentications done with NTLM do not expire. For the Windows implementation of Kerberos expiration time, see [MS-KILE] section 3.3.1.
<113> Section 3.3.5.4: Windows 8 operating system and later and Windows Server 2012 operating system and later fail the SMB_COM_TREE_CONNECT_ANDX request with STATUS_ACCESS_DENIED, if Share.ShareFlags contains SHI1005_FLAGS_ENCRYPT_DATA and the RejectUnencryptedAccess registry key is set to a nonzero value.
<114> Section 3.3.5.4: Windows 2000 never sets the SMB_UNIQUE_FILE_NAME bit in the OptionalSupport field.
Windows XP sets the SMB_UNIQUE_FILE_NAME bit in the OptionalSupport field only if short file name generation is disabled by setting the NtfsDisable8dot3NameCreation registry key to 1; see [MSKB-121007].
Windows Server 2003 operating system and later and Windows Vista operating system and later also set the SMB_UNIQUE_FILE_NAME bit in the OptionalSupport field if the NoAliasingOnFilesystem registry key is set to 1 (enabled).
<115> Section 3.3.5.4: Windows 2000, Windows Server 2003, and Windows Server 2003 R2 set GuestMaximalAccessRights to access rights granted for null session. Windows Vista operating system and later and Windows Server 2008 operating system and later set GuestMaximalAccessRights to zero.
<116> Section 3.3.5.5: Windows-based servers open or create files in the object store as described in [MS-FSA] section 2.1.5.1 Server Requests an Open of a File, with the following mapping of input elements:
RootOpen is provided in one of two ways:
If the SMB_Parameters.Words.RootDirectoryFID field is zero, RootOpen is provided by using the SMB_Header.TID field to find the matching Server.TreeConnect in the Server.Connection.TreeConnectTable. The server then acquires an Open on the Server.TreeConnect.Share.LocalPath, which is passed as RootOpen.
If the SMB_Parameters.Words.RootDirectoryFID field is non-zero, RootOpen is provided by looking up the RootDirectoryFID field in the Server.Connection.FileOpenTable.
PathName is the SMB_Data.Bytes.FileName field of the request.
SecurityContext is found by using the SMB_Header.UID field to look up the matching Session entry in the Server.Connection.SessionTable. The Server.Session.UserSecurityContext is passed as SecurityContext.
UserCertificate is the certificate returned by the User-Certificate binding obtained during request processing.
DesiredAccess is the SMB_Parameters.Words.DesiredAccess field of the request. The FILE_READ_ATTRIBUTES option is added (using a bitwise OR) to the set provided by the client. If the FILE_NO_INTERMEDIATE_BUFFERING flag is set, it is cleared, and FILE_WRITE_THROUGH is set.
ShareAccess is the SMB_Parameters.Words.ShareAccess field of the request.
CreateOptions is the SMB_Parameters.Words.CreateOptions field of the request. The FILE_COMPLETE_IF_OPLOCKED option is added (using a bitwise OR) to the set provided by the client. If the FILE_NO_INTERMEDIATE_BUFFERING flag is set, it is cleared, and FILE_WRITE_THROUGH is set.
CreateDisposition is the SMB_Parameters.Words.CreateDisposition field of the request.
DesiredFileAttributes is the SMB_Parameters.Words.ExtFileAttributes field of the request.
IsCaseSensitive is set to FALSE if the SMB_FLAGS_CASE_INSENSITIVE bit is set in the SMB_Header.Flags field of the request. Otherwise, IsCaseSensitive is set depending upon system defaults.
OpLockKey is empty.
The returned Status is copied into the SMB_Header.Status field of the response. If the operation fails, the Status is returned in an Error Response, and processing is complete.
If the operation is successful, processing continues as follows:
If either the NT_CREATE_REQUEST_OPLOCK or the NT_CREATE_REQUEST_OPBATCH flag is set in the SMB_Parameters.Words.Flags field of the request, an OpLock is requested. Windows-based servers obtain OpLocks as described in [MS-FSA], section 2.1.5.18 Server Requests an Oplock, with the following mapping of input elements:
Open is the Open passed through from the preceding operation.
Type is LEVEL_BATCH if the NT_CREATE_REQUEST_OPBATCH flag is set, or LEVEL_ONE if the NT_CREATE_REQUEST_OPLOCK flag is set.
If an OpLock is granted, the SMB_Parameters.Words.OpLockLevel field of the response is set.
Windows-based servers obtain the extended file attribute and timestamp response information by querying file information from the object store as described in [MS-FSA], section 2.1.5.12 Server Requests a Query of File Information, with the following mapping of input elements:
Open is the Open passed through from the preceding operations.
FileInformationClass is FileBasicInformation ([MS-FSCC] section 2.4.7).
If the query fails, the Status is returned in an Error Response, and processing is complete. Otherwise:
SMB_Parameters.Words.ExtFileAttributes is set to OutputBuffer.FileAttributes.
SMB_Parameters.Words.CreateTime is set to OutputBuffer.CreateTime.
SMB_Parameters.Words.LastAccessTime is set to OutputBuffer.LastAccessTime.
SMB_Parameters.Words.LastWriteTime is set to OutputBuffer.LastWriteTime.
SMB_Parameters.Words.LastChangeTime is set to OutputBuffer.ChangeTime.
Windows-based servers obtain the file size response field values by querying file information from the object store as described in [MS-FSA], section 2.1.5.12 Server Requests a Query of File Information, with the following mapping of input elements:
Open is the Open passed through from the preceding operations.
FileInformationClass is FileStandardInformation ([MS-FSCC] section 2.4.41).
If the query fails, the Status is returned in an Error Response, and processing is complete. Otherwise:
SMB_Parameters.Words.AllocationSize is set to OutputBuffer.AllocationSize.
SMB_Parameters.Words.EndOfFile is set to OutputBuffer.EndOfFile.
If the query fails, the Status is returned in an Error Response, and processing is complete.
Open.File.FileType is used to set the SMB_Parameters.Words.ResourceType and SMB_Parameters.Words.Directory fields of the response.
A new FID is generated for the Open returned. All of the other results of the Open operation are ignored. The FID is copied into the SMB_Parameters.Words.FID field of the response.
<117> Section 3.3.5.5: Windows 2000, Windows XP, Windows Server 2003, Windows Server 2003 R2, Windows Vista, Windows Server 2008, Windows 7, Windows Server 2008 R2, Windows 8, and Windows Server 2012 do not perform this verification.
<118> Section 3.3.5.5: When the client sends a batched request that begins with an SMB_COM_NT_CREATE_ANDX request with the NT_CREATE_REQUEST_EXTENDED_RESPONSE bit set in the Flags field, Windows-based servers return the DOS error code ERRSRV/ERRerror and return an extended response only for the SMB_COM_NT_CREATE_ANDX request.
<119> Section 3.3.5.5: Windows-based servers set the FileStatusFlags using the following mapping of output elements specified in [MS-FSA] section 2.1.5.1:
NO_EAS is set if the returned Open.File.ExtendedAttributesLength is zero, otherwise it is not set.
NO_SUBSTREAMS is set if the returned Open.File.StreamList is less than or equal to one, otherwise it is not set.
NO_REPARSETAG is set if the returned Open.File.ReparseTag is empty, otherwise it is not set.
<120> Section 3.3.5.5: NTFS supports streams. FAT and FAT32 file systems do not support streams.
<121> Section 3.3.5.5: SMB servers on Windows 2000 Server operating system and later return zero for the VolumeGUID and FileId. All other Windows-based servers set the VolumeGUID and FileId fields using the following mapping of output elements, specified in [MS-FSA] section 2.1.5.1:
VolumeGUID is set to the returned Open.File.Volume.VolumeId.
FileId is set to the returned Open.File.FileId.
<122> Section 3.3.5.5: Windows-based servers set the MaximalAccessRights and GuestMaximalAccessRights fields using the following mapping of output elements, specified in [MS-FSA] section 2.1.5.1:
MaximalAccessRights is set to the returned Open.GrantedAcess.
Windows 2000, Windows Server 2003, and Windows Server 2003 R2 set GuestMaximalAccessRights to access rights granted for null session.
Windows Vista operating system and later and Windows Server 2008 operating system and later set GuestMaximalAccessRights to zero.
<123> Section 3.3.5.6: Windows-based servers open existing files in the object store as described in [MS-FSA] section 2.1.5.1 Server Requests an Open of a File, with the following mapping of input elements:
RootOpen is provided by using the SMB_Header.TID to find the matching Server.TreeConnect in the Server.Connection.TreeConnectTable. The server then acquires an Open on Server.TreeConnect.Share.LocalPath, which is passed as RootOpen.
PathName is the SMB_Data.Bytes.FileName field from the request.
SecurityContext is found by using the SMB_Header.UID to look up the matching Session entry in the Server.Connection.SessionTable. The Server.Session.UserSecurityContext is passed as SecurityContext.
UserCertificate is the certificate returned by the User-Certificate binding obtained during request processing.
DesiredAccess is set as follows:
The AccessMode subfield of the AccessMode field in the request is used to set the value of DesiredAccess. The AccessMode subfield represents the lowest-order four bits of the AccessMode field (0x0007), as shown in the table in [MS-CIFS] section 2.2.4.3.1. The mapping of values is as follows:
AccessMode.AccessMode
DesiredAccess
0
GENERIC_READ 0x80000000
1
GENERIC_WRITE | FILE_READ_ATTRIBUTES 0x40000000 | 0x00000080
2
GENERIC_READ | GENERIC_WRITE 0x80000000 | 0x40000000
3
GENERIC_READ | GENERIC_EXECUTE 0x80000000 | 0x20000000
For any other value of AccessMode.AccessMode, this algorithm returns STATUS_OS2_INVALID_ACCESS (ERRDOS/ERRbadaccess).
ShareAccess is set as follows:
The SharingMode subfield of the AccessMode field in the request is used to set the value of ShareAccess. The SharingMode subfield is a 4-bit subfield of the AccessMode field (0x0070), as shown in the table in [MS-CIFS] section 2.2.4.3.1. The mapping of values is as follows:
AccessMode.SharingMode
ShareAccess
0
Compatibility mode (see below)
1
0x0L (don't share, exclusive use)
2
FILE_SHARE_READ
3
FILE_SHARE_WRITE
4
FILE_SHARE_READ | FILE_SHARE_WRITE
0xFF
FCB mode (see below)
For Compatibility mode, special filename suffixes (after the '.' in the filename) are mapped to SharingMode 4. The special filename suffix set is: "EXE", "DLL", "SYM", and "COM". All other file names are mapped to SharingMode 3.
For FCB mode, if the file is already open on the server, the current sharing mode of the existing Open is preserved, and a FID for the file is returned. If the file is not already open on the server, the server attempts to open the file using SharingMode 1.
For any other value of AccessMode.SharingMode, this algorithm returns STATUS_OS2_INVALID_ACCESS (ERRDOS/ERRbadaccess).
CreateOptions bits are set as follows:
CreateOptions value
SMB_COM_OPEN_ANDX equivalent
FILE_WRITE_THROUGH
AccessMode.WritethroughMode == 1
FILE_SEQUENTIAL_ONLY
AccessMode.ReferenceLocality == 1
FILE_RANDOM_ACCESS
AccessMode.ReferenceLocality == 2 or AccessMode.ReferenceLocality == 3
FILE_NO_INTERMEDIATE_BUFFERING
AccessMode.CacheMode == 1
FILE_NON_DIRECTORY_FILE
Is set
FILE_COMPLETE_IF_OPLOCKED
Is set
FILE_NO_EA_KNOWLEDGE
SMB_Header.Flags2.SMB_FLAGS2_KNOWS_EAS == 0
All other bits are unused.
CreateDisposition is set as follows:
CreateDisposition value
SMB_Parameters.Word.OpenMode equivalent
Invalid combination; return STATUS_OS2_INVALID_ACCESS (ERRDOS/ERRbadaccess)
FileExistsOpts = 0 & CreateFile = 0
FILE_CREATE
FileExistsOpts = 0 & CreateFile = 1
FILE_OPEN
FileExistsOpts = 1 & CreateFile = 0
FILE_OPEN_IF
FileExistsOpts = 1 & CreateFile = 1
FILE_OVERWRITE
FileExistsOpts = 2 & CreateFile = 0
FILE_OVERWRITE_IF
FileExistsOpts = 2 & CreateFile = 1
<124> Section 3.3.5.6: Windows-based servers set the MaximalAccessRights and GuestMaximalAccessRights fields using the following mapping of output elements specified in [MS-FSA] section 2.1.5.1:
MaximalAccessRights is set to the returned Open.GrantedAcess.
Windows 2000, Windows Server 2003, and Windows Server 2003 R2 set GuestMaximalAccessRights to access rights granted for null session.
Windows Vista operating system and later and Windows Server 2008 operating system and later set GuestMaximalAccessRights to zero.
<125> Section 3.3.5.7: Windows Vista operating system and later and Windows Server 2008 operating system and later SMB servers fail the SMB_COM_READ_ANDX request with STATUS_INVALID_SMB if it is compounded with an SMB_COM_CLOSE request.
<126> Section 3.3.5.7: If the read operation is on a file and the count of bytes to read is greater than or equal to 0x00010000 (64K), Windows SMB servers set DataLength and DataLengthHigh fields to 0 and do not return any data but return STATUS_SUCCESS.
<127> Section 3.3.5.8: Windows-based servers ignore the ByteCount field, and calculate the number of bytes to be written as DataLength | DataLengthHigh <<16.
<128> Section 3.3.5.9: Windows 2000 Server and Windows Server 2003 return STATUS_NO_MORE_FILES if the FileName field of the SMB_COM_SEARCH request is an empty string.
<129> Section 3.3.5.10.1: Windows behavior for each Information Class is specified in each Information Class' corresponding subsection of either [MS-FSA] section 2.1.5.12 or 2.1.5.13.
<130> Section 3.3.5.10.1: If CAP_INFOLEVEL_PASSTHRU capability is set in Server.Capabilities, and client requested “FileAllInformation” pass-through Information Level, Windows-based servers respond with the structure specified in [MS-CIFS] section 2.2.8.3.10.
<131> Section 3.3.5.10.2: Windows-based servers support these new Information Levels for directory queries.
<132> Section 3.3.5.10.2: Windows Server 2003 operating system and later support previous versions but do not support this method of enumerating them, by default. This feature can be configured to be active by the administrator. The purpose is to allow an application (on a client that does not support the IOCTL command) to have a method of enumerating the previous versions.
<133> Section 3.3.5.10.6: If the requested Information Class is FileRenameInformation, then the following validation is performed:
If RootDirectory is not NULL, then the request fails with STATUS_INVALID_PARAMETER.
If the file name pointed to by the FileName parameter of the FILE_RENAME_INFORMATION structure contains a separator character, then the request fails with STATUS_NOT_SUPPORTED.
If the server file system does not support this Information Level, then it fails the request with STATUS_OS2_INVALID_LEVEL. Otherwise, it attempts to apply the attributes to the target file and return the success or failure code in the response.
<134> Section 3.3.5.10.7: Windows 2000 Server, Windows Server 2003, Windows Server 2003 R2, and Windows Server 2008 do not break a batch oplock when processing a TRANS2_SET_PATH_INFORMATION request. Windows Server 2008 R2 operating system and later break a batch oplock when processing the request.
<135> Section 3.3.5.11.1: Windows 2000, Windows XP operating system and later and Windows Server 2003 operating system and later SMB servers pass IOCTL requests through to the underlying object store.
<136> Section 3.3.5.11.1: The server blocks certain FSCTL requests by not passing them through to the underlying file system for processing. The following FSCTLs are explicitly blocked by the server and are failed with STATUS_NOT_SUPPORTED.
|
Name |
Value |
|---|---|
|
FSCTL_REQUEST_OPLOCK_LEVEL_1 |
0x00090000 |
|
FSCTL_REQUEST_OPLOCK_LEVEL_2 |
0x00090004 |
|
FSCTL_REQUEST_BATCH_OPLOCK |
0x00090008 |
|
FSCTL_OPLOCK_BREAK_ACKNOWLEDGE |
0x0009000C |
|
FSCTL_OPBATCH_ACK_CLOSE_PENDING |
0x00090010 |
|
FSCTL_OPLOCK_BREAK_NOTIFY |
0x00090014 |
|
FSCTL_MOVE_FILE |
0x00090074 |
|
FSCTL_MARK_HANDLE |
0x000900FC |
|
FSCTL_QUERY_RETRIEVAL_POINTERS |
0x0009003B |
|
FSCTL_PIPE_ASSIGN_EVENT |
0x00110000 |
|
FSCTL_GET_VOLUME_BITMAP |
0x0009006F |
|
FSCTL_GET_NTFS_FILE_RECORD |
0x00090068 |
|
FSCTL_INVALIDATE_VOLUMES |
0x00090054 |
Windows does not support USN journal calls because they require a volume handle. The following USN journal calls are also failed with STATUS_NOT_SUPPORTED.
|
Name |
Value |
|---|---|
|
FSCTL_READ_USN_JOURNAL |
0x000900BB |
|
FSCTL_CREATE_USN_JOURNAL |
0x000900E7 |
|
FSCTL_QUERY_USN_JOURNAL |
0x000900F4 |
|
FSCTL_DELETE_USN_JOURNAL |
0x000900F8 |
|
FSCTL_ENUM_USN_DATA |
0x000900B3 |
The following FSCTLs are explicitly blocked by Windows Server 2008 R2, Windows Server 2012, and Windows Server 2012 R2 and are not passed through to the object store. They are failed with STATUS_NOT_SUPPORTED.
|
Name |
Value |
|---|---|
|
FSCTL_REQUEST_OPLOCK_LEVEL_1 |
0x00090000 |
|
FSCTL_REQUEST_OPLOCK_LEVEL_2 |
0x00090004 |
|
FSCTL_REQUEST_BATCH_OPLOCK |
0x00090008 |
|
FSCTL_REQUEST_FILTER_OPLOCK |
0x0009005C |
|
FSCTL_OPLOCK_BREAK_ACKNOWLEDGE |
0x0009000C |
|
FSCTL_OPBATCH_ACK_CLOSE_PENDING |
0x00090010 |
|
FSCTL_OPLOCK_BREAK_NOTIFY |
0x00090014 |
|
FSCTL_MOVE_FILE |
0x00090074 |
|
FSCTL_MARK_HANDLE |
0x000900FC |
|
FSCTL_QUERY_RETRIEVAL_POINTERS |
0x0009003B |
|
FSCTL_PIPE_ASSIGN_EVENT |
0x00110000 |
|
FSCTL_GET_VOLUME_BITMAP |
0x0009006F |
|
FSCTL_GET_NTFS_FILE_RECORD |
0x00090068 |
|
FSCTL_INVALIDATE_VOLUMES |
0x00090054 |
|
FSCTL_READ_USN_JOURNAL |
0x000900BB |
|
FSCTL_CREATE_USN_JOURNAL |
0x000900E7 |
|
FSCTL_QUERY_USN_JOURNAL |
0x000900F4 |
|
FSCTL_DELETE_USN_JOURNAL |
0x000900F8 |
|
FSCTL_ENUM_USN_DATA |
0x000900B3 |
|
FSCTL_QUERY_DEPENDENT_VOLUME |
0x000901F0 |
|
FSCTL_SD_GLOBAL_CHANGE |
0x000901F4 |
|
FSCTL_GET_BOOT_AREA_INFO |
0x00090230 |
|
FSCTL_GET_RETRIEVAL_POINTER_BASE |
0x00090234 |
|
FSCTL_SET_PERSISTENT_VOLUME_STATE |
0x00090238 |
|
FSCTL_QUERY_PERSISTENT_VOLUME_STATE |
0x0009023C |
|
FSCTL_REQUEST_OPLOCK |
0x00090240 |
|
FSCTL_TXFS_MODIFY_RM |
0x00098144 |
|
FSCTL_TXFS_QUERY_RM_INFORMATION |
0x00094148 |
|
FSCTL_TXFS_ROLLFORW ARD_REDO |
0x00098150 |
|
FSCTL_TXFS_ROLLFORWARD_UNDO |
0x00098154 |
|
FSCTL_TXFS_START_RM |
0x00098158 |
|
FSCTL_TXFS_SHUTDOWN_RM |
0x0009815C |
|
FSCTL_TXFS_READ_BACKUP_INFORMATION |
0x00094160 |
|
FSCTL_TXFS_WRITE_BACKUP_INFORMATION |
0x00098164 |
|
FSCTL_TXFS_CREATE_SECONDARY_RM |
0x00098168 |
|
FSCTL_TXFS_GET_METADATA_INFO |
0x0009416C |
|
FSCTL_TXFS_GET_TRANSACTED_VERSION |
0x00094170 |
|
FSCTL_TXFS_SAVEPOINT_INFORMATION |
0x00098178 |
|
FSCTL_TXFS_CREATE_MINIVERSION |
0x0009817C |
|
FSCTL_TXFS_TRANSACTION_ACTIVE |
0x0009418C |
|
FSCTL_TXFS_LIST_TRANSACTIONS |
0x000941E4 |
|
FSCTL_TXFS_READ_BACKUP_INFORMATION2 |
0x000901F8 |
|
FSCTL_TXFS_WRITE_BACKUP_INFORMATION2 |
0x00090200 |
The following FSCTL is explicitly blocked by Windows 8 and Windows Server 2012 and is failed with STATUS_NOT_SUPPORTED.
|
Name |
Value |
|---|---|
|
FSCTL_GET_RETRIEVAL_POINTERS |
0x00090073 |
<137> Section 3.3.5.11.1.1: If MaxDataCount is not 0x10, Windows-based servers do not refresh the Server.Share.SnapshotList.
<138> Section 3.3.5.11.1.1: Windows-based SMB servers place two extra bytes set to zero in SnapShotMultiSZ array and set SnapShotArraySize to 2, if NumberOfSnapShots is zero.
<139> Section 3.3.5.11.1.1: When the NumberOfSnapShotsReturned field is zero, Windows-based SMB servers incorrectly append 2 zeroed bytes after NT_Trans_Data in the NT_TRANSACT_IOCTL response buffer of the FSCTL_SRV_ENUMERATE_SNAPSHOTS response.
<140> Section 3.3.5.11.2: Windows-based servers request quota information from the object store, as specified in [MS-FSA] section 2.1.5.12.24 if Server.Open is a file. If Server.Open is on a directory, then the processing follows with the following mapping of input elements:
Open is an Open of Server.Open.TreeConnect.Share.LocalPath for the Server.Open indicated by the SMB_Parameters.Words.FID field of the request.
OutputBufferSize is the SMB_Parameters.Words.MaxDataCount field of the request.
ReturnSingle is the NT_Trans_Parameters.ReturnSingleEntry field of the request.
RestartScan is the NT_Trans_Parameters.RestartScan field of the request.
SidList is the NT_Trans_Data.SidList field of the request.
The returned Status is copied into the SMB_Header.Status field of the response. If the operation is successful, then the following additional mapping of output elements applies:
OutputBuffer is copied into the NT_Trans_Data field of the response.
ByteCount is copied into the SMB_Parameters.TotalDataCount field of the response.
If quotas are disabled then the object store returns the ChangeTime, QuotaUsed, QuotaThreshold, and QuotaLimit fields set to zero in the FILE_QUOTA_INFORMATION.
Windows-based servers enumerate and return quota information for all SIDs on the file instead of the SIDs specified in the SidList field, if any of the following conditions are TRUE:
SidListLength is zero.
StartSidOffset is less than SidListLength.
StartSidOffset or SidListLength is greater than SMB_Parameters.Words.DataCount.
<141> Section 3.3.5.11.3: Windows-based servers set the quota information on the object store, as specified in [MS-FSA] section 2.1.5.15.10, if Server.Open is on a file. If Server.Open is on a directory, then processing follows, as specified in [MS-FSA] section 2.1.5.22, with the following mapping of input elements:
Open is an Open of Server.Open.TreeConnect.Share.LocalPath for the Server.Open indicated by the NT_Trans_Parameters.FID field of the request.
InputBuffer is the NT_Trans_Data.QuotaInformation field of the request.
InputBuffer is set to the size, in bytes, of the InputBuffer field.
<142> Section 3.3.5.11.4: Windows 2000, Windows Server 2003, Windows Server 2003 R2, Windows XP, Windows Vista, and Windows Server 2008 servers fail the request but respond with arbitrary values in the NT_TRANSACT_CREATE Response. Windows 7 operating system and later and Windows Server 2008 R2 operating system and later send an error response message without the parameter block or the data block.