idnits 2.17.1 draft-leach-cifs-v1-spec-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-26) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. ** The document is more than 15 pages and seems to lack a Table of Contents. == The page length should not exceed 58 lines per page, but there was 121 longer pages, the longest (page 57) being 75 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 10 instances of too long lines in the document, the longest one being 5 characters in excess of 72. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 282: '...red by CIFS is that a CIFS client MUST...' RFC 2119 keyword, line 284: '...at a CIFS server MUST register its nam...' RFC 2119 keyword, line 294: '...ation dependent; the default SHOULD be...' RFC 2119 keyword, line 477: '...e granted, then the server MAY grant a...' RFC 2119 keyword, line 522: '... then the server MUST tell client A to...' (18 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 258 has weird spacing: '... server is ou...' == Line 357 has weird spacing: '...rt, and makes...' == Line 816 has weird spacing: '...se used prior...' == Line 1197 has weird spacing: '...present time....' == Line 1841 has weird spacing: '...If bit0 of th...' == (11 more instances...) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (December 19, 1997) is 9625 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: '8' is mentioned on line 691, but not defined -- Looks like a reference, but probably isn't: 'SetupCount' on line 1417 -- Looks like a reference, but probably isn't: 'ParameterCount' on line 1572 -- Looks like a reference, but probably isn't: 'DataCount' on line 1574 -- Looks like a reference, but probably isn't: 'SetupWordCount' on line 1568 == Missing Reference: '16' is mentioned on line 1887, but not defined == Missing Reference: '0' is mentioned on line 4703, but not defined -- Looks like a reference, but probably isn't: 'NameLength' on line 2814 -- Looks like a reference, but probably isn't: 'EaLength' on line 2822 -- Looks like a reference, but probably isn't: 'DataLength' on line 2971 == Missing Reference: '12' is mentioned on line 4212, but not defined -- Looks like a reference, but probably isn't: 'TotalDataCount' on line 4616 == Unused Reference: '5' is defined on line 4981, but no explicit reference was found in the text ** Obsolete normative reference: RFC 1320 (ref. '6') (Obsoleted by RFC 6150) Summary: 13 errors (**), 0 flaws (~~), 12 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Paul J. Leach, Microsoft 3 INTERNET-DRAFT Dilip C. Naik, Microsoft 4 draft-leach-cifs-v1-spec-01.txt 5 Category: Informational 6 Expires June 19, 1998 December 19, 1997 8 A Common Internet File System (CIFS/1.0) Protocol 10 Preliminary Draft 12 Status of this Memo 14 This document is an Internet-Draft. Internet-Drafts are working 15 documents of the Internet Engineering Task Force (IETF), its areas, and 16 its working groups. Note that other groups may also distribute working 17 documents as Internet-Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or made obsolete by other documents at any 21 time. It is inappropriate to use Internet-Drafts as reference material 22 or to cite them other than as "work in progress". 24 To learn the current status of any Internet-Draft, please check the 25 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 26 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 27 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 28 ftp.isi.edu (US West Coast). 30 Distribution of this document is unlimited. Please send comments to the 31 authors at . Discussion of CIFS is on the mailing 32 list ; subscribe by sending a message to 33 with a body of "subscribe CIFS 34 you@your.domain". The mailing list archives are at 35 . 38 Abstract 40 This document describes the CIFS file sharing protocol, version 1.0. 41 Client systems use this protocol to request file access services from 42 server systems over a network. It is based on the Server Message Block 43 protocol widely in use by personal computers and workstations running a 44 wide variety of operating systems. 46 This document omits discussion of obsolescent requests not needed by 47 modern clients. They are defined in a companion document Obsolescent SMB 48 Requests. 50 Table Of Contents 52 1 Introduction 3 54 1.1 Summary of features 4 56 2 Protocol Operation Overview 6 58 2.1 Server Name Determination 6 59 2.2 Server Name Resolution 7 60 2.3 Sample Message Flow 7 61 2.4 CIFS Protocol Dialect Negotiation 8 62 2.5 Message Transport 8 63 2.6 Opportunistic Locks 10 64 2.7 Security Model 13 65 2.8 Authentication 14 66 2.9 Distributed Filesystem (DFS) Support 14 68 3 SMB Message Formats and Data Types 15 70 3.1 Notation 15 71 3.2 SMB header 15 72 3.3 File Names 22 73 3.4 Wildcards 22 74 3.5 DFS Pathnames 23 75 3.6 Time And Date Encoding 24 76 3.7 Access Mode Encoding 25 77 3.8 Access Mask Encoding 25 78 3.9 Open Function Encoding 26 79 3.10 Open Action Encoding 27 80 3.11 File Attribute Encoding 27 81 3.12 Extended File Attribute Encoding 28 82 3.13 Batching Requests ("AndX" Messages) 30 83 3.14 "Transaction" Style Subprotocols 31 84 3.15 Valid SMB Requests by Negotiated Dialect 39 86 4 SMB Requests 40 88 4.1 Session Requests 41 89 4.2 File Requests 62 90 4.3 Directory Requests 94 91 4.4 DFS Operations 104 92 4.5 Miscellaneous Operations 108 93 5 SMB Symbolic Constants 110 95 5.1 SMB Command Codes 110 96 5.2 SMB_COM_TRANSACTION2 Subcommand codes 112 97 5.3 SMB_COM_NT_TRANSACTION Subcommand Codes 113 98 5.4 SMB Protocol Dialect Constants 114 100 6 Error Codes and Classes 115 102 7 Legal Notice 118 104 8 References 119 106 9 Authors' Addresses 119 108 10 Appendix A -- NETBIOS transport over TCP 119 110 10.1 Connection Establishment 120 111 10.2 Server-side Connection Procedures 120 113 11 Appendix B -- TCP transport 120 115 1 Introduction 117 This document describes the file sharing protocol for a proposed Common 118 Internet File System (CIFS). CIFS is intended to provide an open cross- 119 platform mechanism for client systems to request file services from 120 server systems over a network. It is based on the standard Server 121 Message Block (SMB) protocol widely in use by personal computers and 122 workstations running a wide variety of operating systems. An earlier 123 version of this protocol was documented as part of the X/OPEN (now Open 124 Group) CAE series of standards [7]; this document updates the 125 specification to include the latest shipping versions, and is published 126 to allow the creation of implementations that inter-operate with those 127 implementations. 129 The scope of this specification is limited to describing requests and 130 responses for file services. Separate specifications exist for clients 131 requesting services other than file services, e.g. print services. 133 Use of the Internet and the World Wide Web has been characterized by 134 read-only access. Existing protocols such as FTP are good solutions for 135 one-way file transfer. However, new read/write interfaces will become 136 increasingly necessary as the Internet becomes more interactive and 137 collaborative. Adoption of a common file sharing protocol having modern 138 semantics such as shared files, byte-range locking, coherent caching, 139 change notification, replicated storage, etc. would provide important 140 benefits to the Internet community. 142 1.1 Summary of features 144 The protocol supports the following features: 146 o File access 148 o File and record locking 150 o Safe caching, read-ahead, and write-behind 152 o File change notification 154 o Protocol version negotiation 156 o Extended attributes 158 o Distributed replicated virtual volumes 160 o Server name resolution independence 162 o Batched requests 164 o Unicode file names 166 1.1.1 File access 168 The protocol supports the usual set of file operations: open, close, 169 read, write, and seek. 171 1.1.2 File and record locking 173 The protocol supports file and record locking, as well as unlocked 174 access to files. Applications that lock files can not be improperly 175 interfered with by applications that do not; once a file or record is 176 locked, non-locking applications are denied access to the file. 178 1.1.3 Safe caching, read-ahead, and write-behind 180 The protocol supports caching, read-ahead, and write-behind, even for 181 unlocked files, as long as they are safe. All these optimizations are 182 safe as long as only one client is accessing a file; read-caching and 183 read-ahead are safe with many clients accessing a file as long as all 184 are just reading. If many clients are writing a file simultaneously, 185 then none are safe, and all file operations have to go to the server. 186 The protocol notifies all clients accessing a file of changes in the 187 number and access mode of clients accessing the file, so that they can 188 use the most optimized safe access method. 190 1.1.4 File change notification 192 Applications can register with a server to be notified if and when file 193 or directory contents are modified. They can use this to (for example) 194 know when a display needs to be refreshed, without having to constantly 195 poll the server. 197 1.1.5 Protocol version negotiation 199 There are several different versions and sub-versions of this protocol; 200 a particular version is referred to as a dialect. When two machines 201 first come into network contact they negotiate the dialect to be used. 202 Different dialects can include both new messages as well as changes to 203 the fields and semantics of existing messages in other dialects. 205 1.1.6 Extended attributes 207 In addition to many built-in file attributes, such as creation and 208 modification times, non-file system attributes can be added by 209 applications, such as the author's name, content description, etc. 211 1.1.7 Distributed replicated virtual volumes 213 The protocol supports file system subtrees which look like to clients as 214 if they are on a single volume and server, but which actually span 215 multiple volumes and servers. The files and directories of such a 216 subtree can be physically moved to different servers, and their names do 217 not have to change, isolating clients from changes in the server 218 configuration. These subtrees can also be transparently replicated for 219 load sharing and fault tolerance. When a client requests a file, the 220 protocol uses referrals to transparently direct a client to the server 221 that stores it. 223 1.1.8 Server name resolution independence 225 The protocol allows clients to resolve server names using any name 226 resolution mechanism. In particular, it allows using the DNS, permitting 227 access to the file systems of other organizations over the Internet, or 228 hierarchical organization of servers' names within an organization. 229 Earlier versions of the protocol only supported a flat server name 230 space. 232 1.1.9 Batched requests 234 The protocol supports the batching of multiple requests into a single 235 message, in order to minimize round trip latencies, even when a later 236 request depends on the results of an earlier one. 238 2 Protocol Operation Overview 240 In order to access a file on a server, a client has to: 242 o Parse the full file name to determine the server name, and the 243 relative name within that server. 245 o Resolve the server name to a transport address (this may be cached) 247 o Make a connection to the server (if no connection is already 248 available) 250 o Exchange CIFS messages (see below for an example) 252 This process may be repeated as many times as desired. Once the 253 connection has been idle for a while, it may be torn down. 255 2.1 Server Name Determination 257 How the client determines the name of the server and the relative name 258 within the server is outside of the scope of this specification. 259 However, just for expository purposes, here are three examples. 261 In the URL "file://fs.megacorp.com/users/fred/stuff.txt", the client 262 could take the part between the leading double slashes and the next 263 slash as the server name and the remainder as the relative name -- in 264 this example "fs.megacorp.com" and "/users/fred/stuff.txt", 265 respectively. 267 In the path name "\\corpserver\public\policy.doc" the client could take 268 the part between the leading double backslashes and the next slash as 269 the server name, and the remainder as the relative name -- in this 270 example, "corpserver" and "\public\policy.doc" respectively. 272 In the path name "x:\policy.doc" the client could use "x" as an index 273 into a table that contains a server name and a file name prefix. If the 274 contents of such a table for "x" were "corpserver" and "\public", then 275 the server name and relative name would be the same as in the previous 276 example. 278 2.2 Server Name Resolution 280 Like server name determination, how the client resolves the name to the 281 transport address of the server is outside the scope of this 282 specification. All that is required by CIFS is that a CIFS client MUST 283 have some means to resolve the name of a CIFS server to a transport 284 address, and that a CIFS server MUST register its name with a name 285 resolution service known its clients. 287 Some examples of name resolution mechanisms include: using the Domain 288 Name System (DNS) [1,2], and using NETBIOS name resolution (see RFC 1001 289 and RFC 1002 [3,4]). The server name might also be specified as the 290 string form of an IPv4 address in the usual dotted decimal notation, 291 e.g., "157.33.135.101"; in this case, "resolution" consists of 292 converting to the 32 bit IPv4 address. 294 Which method is used is configuration dependent; the default SHOULD be 295 DNS to encourage interoperability over the Internet. 297 Note: The name resolution mechanism used may place constraints on the 298 form of the server name; for example, in the case of NETBIOS, the server 299 name must be 15 characters or less, and be upper case. 301 2.3 Sample Message Flow 303 The following illustrates a typical message exchange sequence for a 304 client connecting to a user level server, opening a file, reading its 305 data, closing the file, and disconnecting from the server. Note: using 306 the CIFS request batching mechanism (called the "AndX" mechanism), the 307 second to sixth messages in this sequence can be combined into one, so 308 there are really only three round trips in the sequence, and the last 309 one can be done asynchronously by the client. 311 Client Command Server Response 312 ========================== ========================================= 314 SMB_COM_NEGOTIATE Must be the first message sent by client 315 to the server. Includes a list of SMB 316 dialects supported by the client. Server 317 response indicates which SMB dialect 318 should be used. 319 SMB_COM_SESSION_SETUP_ANDX Transmits the user's name and credentials 320 to the server for verification. 321 Successful server response has Uid field 322 set in SMB header used for subsequent 323 SMBs on behalf of this user. 324 SMB_COM_TREE_CONNECT_ANDX Transmits the name of the disk share the 325 client wants to access. Successful 326 server response has Tid field set in SMB 327 header used for subsequent SMBs referring 328 to this resource. 329 SMB_COM_OPEN_ANDX Transmits the name of the file, relative 330 to Tid, the client wants to open. 331 Successful server response includes a 332 file id (Fid) the client should supply 333 for subsequent operations on this file. 334 SMB_COM_READ Client supplies Tid, Fid, file offset, 335 and number of bytes to read. Successful 336 server response includes the requested 337 file data. 338 SMB_COM_CLOSE Client closes the file represented by Tid 339 and Fid. Server responds with success 340 code. 341 SMB_COM_TREE_DISCONNECT Client disconnects from resource 342 represented by Tid. 344 2.4 CIFS Protocol Dialect Negotiation 346 The first message sent from an CIFS client to an CIFS server must be one 347 whose Command field is SMB_COM_NEGOTIATE. The format of this client 348 request includes an array of NULL terminated strings indicating the 349 dialects of the CIFS protocol which the client supports. The server 350 compares this list against the list of dialects the server supports and 351 returns the index of the chosen dialect in the response message. 353 2.5 Message Transport 355 CIFS is transport independent. The CIFS protocol assumes: 357 o a reliable connection oriented message-stream transport, and makes 358 no higher level attempts to ensure sequenced delivery of messages 359 between the client and server. 361 o a well known endpoint for the CIFS service 363 o some mechanism to detect failures of either the client or server 364 node, and to deliver such an indication to the client or server 365 software so they can clean up state. When a reliable transport 366 connection from a client terminates, all work in progress by that 367 client is terminated by the server and all resources open by that 368 client on the server are closed. 370 It can run over any transport that meets these requirements. Some 371 transports do not natively meet all the requirements, and a standard 372 encapsulation of CIFS for that transport may need to be defined. 373 Appendix A defines how to run CIFS over NETBIOS over TCP; Appendix B 374 defines how to run CIFS over TCP. 376 2.5.1 Connection Management 378 Once a connection is established, the rules for reliable transport 379 connection dissolution are: 381 o If a server receives a transport establishment request from a client 382 with which it is already conversing, the server may terminate all 383 other transport connections to that client. This is to recover from 384 the situation where the client was suddenly rebooted and was unable 385 to cleanly terminate its resource sharing activities with the server. 387 o A server may drop the transport connection to a client at any time if 388 the client is generating malformed or illogical requests. However, 389 wherever possible the server should first return an error code to the 390 client indicating the cause of the abort. 392 o If a server gets a hard error on the transport (such as a send 393 failure) the transport connection to that client may be aborted. 395 o A server may terminate the transport connection when the client has 396 no open resources on the server, however, we recommend that the 397 termination be performed only after some time has passed or if 398 resources are scarce on the server. This will help performance in 399 that the transport connection will not need to be reestablished if 400 activity soon begins anew. Client software is expected to be able to 401 automatically reconnect to the server if this happens. 403 2.6 Opportunistic Locks 405 Network performance can be increased if a client does not need to inform 406 the server immediately about every change it makes to a file, or have to 407 worry that other clients can make its information about the file out of 408 date. For example, a client does not have to immediately write 409 information into a file on the server if the client knows that no other 410 process is accessing the data. Likewise, the client can buffer read- 411 ahead data from the file if the client knows that no other process is 412 writing the data. 414 The mechanism which allows clients to dynamically alter their buffering 415 strategy in a consistent manner is knows as "opportunistic locks", or 416 oplocks for short. Versions of the CIFS file sharing protocol including 417 and newer than the "LANMAN1.0" dialect support oplocks. (Note, however, 418 that an implementation, even of these later dialects, can implement 419 oplocks trivially by always refusing to grant them.) 421 There are three different types of oplocks: 423 o A Level II oplock, when held, informs a client that there are 424 multiple concurrent clients of a file, and none has yet modified it. 425 It allows the client to perform reads and file attribute fetches 426 using cached or read-ahead local information, but all other requests 427 have to be sent to the server. 429 o An exclusive oplock, when held, informs a client that it is the only 430 one to have a file open. It allows the client to perform all file 431 operations using cached or read-ahead local information until it 432 closes the file, at which time the server has to be updated with any 433 changes made to the state of the file (contents and attributes). 435 o A batch oplock, when held, informs a client that it is the only one 436 to have a file open. It allows the client to perform all file 437 operations on cached or read-ahead local information (including opens 438 and closes). 440 If a client holds no oplocks, all requests other than reads must be sent 441 to the server. Reads may be performed using cached or read-ahead data as 442 long as the byte range has been locked by the client; otherwise they too 443 must be sent to the server. 445 When a client opens a file, it may request that the server grant it an 446 exclusive or batch oplock on the file. The response from the server 447 indicates the type of oplock granted to the client. If cached or read- 448 ahead information was retained after the file was last closed, the 449 client must verify that the last modified time is unchanged when the 450 file is reopened before using the retained information. 452 The SMB_COM_LOCKING_ANDX SMB is used to convey oplock break requests and 453 acknowledgements (as well as lock and unlock requests). 455 2.6.1 Level II Oplocks 457 The Level II oplock protocol is: 459 Client <-> Server 461 A B 462 =========== =========== ==== ==================================== 464 Open("foo") -> 465 <- Open OK. Exclusive oplock granted. 466 Read -> 467 <- data 468 Open("foo") -> 469 <- Break to Level II oplock to A 470 lock(s) -> 471 <- lock(s) response(s) 472 oplock ack -> 473 <- Open OK. Oplock II oplock granted 474 to B 476 When a client opens a file, it may request an exclusive or batch oplock. 477 If the requested oplock cannot be granted, then the server MAY grant a 478 Level II oplock if the file currently has an oplock on it. If there is 479 currently an exclusive or batch oplock on the file, it must be broken 480 and the break acknowledged before the open is processed. If there is 481 currently a Level II oplock on the file, it does not need to be broken, 482 and the open may be processed immediately. 484 If any client sends a request to modify the state of a file that has a 485 Level II oplock, the server must ask all clients holding an oplock on 486 the file to break it, but need not wait for an acknowledgement. 488 2.6.2 Exclusive Oplocks 490 The exclusive oplock protocol is: 492 Client <-> Server 494 A B 495 ============== =========== === ================================ 497 Open ("foo") -> 498 <- Open OK. Exclusive oplock 499 granted. 500 502 read (large) -> 503 <- read data 504 506 Open("foo") -> 507 <- oplock break to A 508 lock(s) -> 509 <- lock(s) response(s) 510 write(s) -> 511 <- write(s) response(s) 512 close or -> 513 oplock ack 514 <- open response to B 516 When client A opens the file, it can request an exclusive oplock. 517 Provided no one else has the file open on the server, then the server 518 MAY grant the oplock to client A. 520 If, at some point in the future, another client, such as client B, 521 requests an open of the same file, or requests a path name based 522 operation on the file, then the server MUST tell client A to relinquish 523 its exclusive oplock. If client B's request will not modify the state of 524 the file, the server MAY tell client A that its exclusive oplock has 525 been replaced by a level II oplock. 527 When a client's exclusive oplock is broken, it must synchronize the 528 server to the local state of the file (contents and attributes) and any 529 locks it holds on the file, and then acknowledge the oplock break 530 request. After the server receives the acknowledgement, if can process 531 B's request. 533 2.6.3 Batch Oplocks 535 The batch oplock protocol is: 537 Client <-> Server 539 A B 540 =========== ============ ==== =============================== 542 Open("foo") -> 543 <- Open OK. Batch oplock granted. 544 Read -> 545 <- read data 546 547 548 549 read -> 550 <- data 551 552 Open("foo") -> 553 <- Oplock break to A 554 Close -> 555 <- Close OK to A 556 <- Open OK to B 558 When client A opens the file, it can request a batch oplock. Provided no 559 one else has the file open on the server, then the server MAY grant the 560 oplock to client A. 562 If, at some point in the future, another client, such as client B, 563 requests any operation on the same file, then the server MUST tell 564 client A to relinquish its batch oplock. If client B's request will not 565 modify the state of the file (or rename it), the server MAY tell client 566 A that its batch oplock has been replaced by a level II oplock. 568 If A has the file open at the time the oplock break request is received, 569 its actions will be the same as if it had an exclusive oplock. If A does 570 not have the file open at the time the oplock break request is received, 571 it sends a close to the server. Once the file is actually closed at the 572 server, client B's open request can be processed. 574 2.7 Security Model 576 Each server makes a set of resources available to clients on the 577 network. A resource being shared may be a directory tree, printer, 578 etc. So far as clients are concerned, the server has no storage or 579 service dependencies on any other servers; a client considers the server 580 to be the sole provider of the file (or other resource) being accessed. 582 The CIFS protocol requires server authentication of users before file 583 accesses are allowed, and each server authenticates its own users. A 584 client system must send authentication information to the server before 585 the server will allow access to its resources. 587 A server requires the client to provide a user name and some proof of 588 identity (often something cryptographically derived from a password) to 589 gain access. The granularity of authorization is up to the server. For 590 example, it may use the account name to check access control lists on 591 individual files, or may have one access control list that applies to 592 all files in the directory tree. 594 When a server validates the account name and password presented by the 595 client, an identifier representing that authenticated instance of the 596 user is returned to the client in the Uid field of the response SMB. 597 This Uid must be included in all further requests made on behalf of the 598 user from that client. 600 2.8 Authentication 602 The information on authentication that was in previous revisions of this 603 document has been moved to a different specification. 605 2.9 Distributed Filesystem (DFS) Support 607 Protocol dialects of NT LM 0.12 and later support distributed filesystem 608 operations. The distributed filesystem gives a way for this protocol to 609 use a single consistent file naming scheme which may span a collection 610 of different servers and shares. The distributed filesystem model 611 employed is a referral - based model. This protocol specifies the manner 612 in which clients receive referrals. 614 The client can set a flag in the request SMB header indicating that the 615 client wants the server to resolve this SMB's paths within the DFS known 616 to the server. The server attempts to resolve the requested name to a 617 file contained within the local directory tree indicated by the TID of 618 the request and proceeds normally. If the request pathname resolves to a 619 file on a different system, the server returns the following error: 621 STATUS_DFS_PATH_NOT_COVERED - the server does not support the part 622 of the DFS namespace needed to resolved the pathname in the request. 624 The client should request a referral from this server for further 625 information. 627 A client asks for a referral with the TRANS2_DFS_GET_REFERRAL request 628 containing the DFS pathname of interest. The response from the server 629 indicates how the client should proceed. 631 The method by which the topological knowledge of the DFS is stored and 632 maintained by the servers is not specified by this protocol. 634 3 SMB Message Formats and Data Types 636 Clients exchange messages with a server to access resources on that 637 server. These messages are called Server Message Blocks (SMBs), and 638 every SMB message has a common format. 640 This section describes the entire set of SMB commands and responses 641 exchanged between CIFS clients and servers. It also details which SMBs 642 are introduced into the protocol as higher dialect levels are 643 negotiated. 645 3.1 Notation 647 This specification makes use of "C"-like notation to describe the 648 formats of messages. Unlike the "C" language, which allows for 649 implementation flexibility in laying out structures, this specification 650 adopts the following rules. Multi-byte values are always transmitted 651 least significant byte first. All fields, except "bit-fields", are 652 aligned on the nearest byte boundary (even if longer than a byte), and 653 there is no implicit padding. Fields using the "bit field" notation are 654 defined to be laid out within the structure with the first-named field 655 occupying the lowest order bits, the next named field the next lowest 656 order bits, and so on. 658 3.2 SMB header 660 While each SMB command has specific encodings, there are some fields in 661 the SMB header which have meaning to all SMBs. These fields and 662 considerations are described in the following sections. 664 typedef unsigned char UCHAR; // 8 unsigned bits 665 typedef unsigned short USHORT; // 16 unsigned bits 666 typedef unsigned long ULONG; // 32 unsigned bits 668 typedef struct { 669 ULONG LowPart; 670 LONG HighPart; 671 } LARGE_INTEGER; // 64 bits of data 673 typedef struct { 674 UCHAR Protocol[4]; // Contains 0xFF,'SMB' 675 UCHAR Command; // Command code 676 union { 677 struct { 678 UCHAR ErrorClass; // Error class 679 UCHAR Reserved; // Reserved for future use 680 USHORT Error; // Error code 681 } DosError; 682 ULONG Status; // 32-bit error code 683 } Status; 684 UCHAR Flags; // Flags 685 USHORT Flags2; // More flags 686 union { 687 USHORT Pad[6]; // Ensure section is 12 bytes long 688 struct { 689 USHORT Reserved; // reserved for obsolescent 690 requests 691 UCHAR SecuritySignature[8]; // reserved for MIC 692 } Extra; 693 }; 694 USHORT Tid; // Tree identifier 695 USHORT Pid; // Opaque for client use 696 USHORT Uid; // User id 697 USHORT Mid; // multiplex id 698 UCHAR WordCount; // Count of parameter words 699 USHORT ParameterWords[ WordCount ]; // The parameter words 700 USHORT ByteCount; // Count of bytes 701 UCHAR Buffer[ ByteCount ]; // The bytes 702 } SMB_HEADER; 704 All SMBs in this specification have identical format up to the 705 ParameterWords fields. (Some obsolescent ones do not.) Different SMBs 706 have a different number and interpretation of ParameterWords and 707 Buffer. All reserved fields in the SMB header must be zero. 709 3.2.1C ommand field 711 The Command is the operation code that this SMB is requesting or 712 responding to. See section 5.1 below for number values, and section 4 713 for a description of each operation. 715 3.2.2 Flags field 717 This field contains 8 individual flags, numbered from least significant 718 bit to most significant bit, which are defined below. Flags that are not 719 defined MUST be set to zero by clients and MUST be ignored by servers. 721 Bit Name: SMB_FLAGS_ Meaning First Used 722 === ==== ======================== ========== 724 0 Reserved for obsolescent LANMAN1.0 725 requests. (LOCK_AND_READ, 726 WRITE_AND_CLOSE) 727 1 Reserved (must be zero). 728 2 Reserved (must be zero). 729 3 CASELESS When on, all pathnames in this LANMAN1.0 730 SMB must be treated as case-less. 731 When off, the pathnames are case 732 sensitive. 733 4 Reserved (clients must send as 734 zero; servers must ignore). 735 5 Reserved for obsolescent LANMAN1.0 736 requests. (SMB_COM_OPEN, 737 SMB_COM_CREATE and 738 SMB_COM_CREATE_NEW) 739 6 Reserved for obsolescent LANMAN1.0 740 requests. (SMB_COM_OPEN, 741 SMB_COM_CREATE and 742 SMB_COM_CREATE_NEW) 743 7 SERVER_RESP When on, this SMB is being sent PC NETWORK 744 from the server in response to a PROGRAM 745 client request. The Command 1.0 746 field usually contains the same 747 value in a protocol request from 748 the client to the server as in 749 the matching response from the 750 server to the client. This bit 751 unambiguously distinguishes the 752 command request from the command 753 response. 755 3.2.3 Flags2 Field 757 This field contains six individual flags, numbered from least 758 significant bit to most significant bit, which are defined below. Flags 759 that are not defined MUST be set to zero by clients and MUST be ignored 760 by servers. 762 Value Name: SMB_FLAGS2_ Meaning First Used 763 ===== ===== ============================ ========= 765 0x0001 KNOWS_LONG_NAMES If set in a request, the LM1.2X002 766 server may return long 767 components in path names in 768 the response. 769 0x0002 KNOWS_EAS If set, the client is aware 770 of extended attributes 771 (EAs). 772 0x0004 SECURITY_SIGNATURE If set, the SMB is integrity 773 checked 774 0x0008 RESERVED1 Reserved for future use 775 0x0040 IS_LONG_NAME If set, any path name in the 776 request is a long name 777 0x0800 EXT_SEC If set, the client is aware NT LM 0.12 778 of Extended Security 779 negotiation 780 0x1000 DFS If set, any request NT LM 0.12 781 pathnames in this SMB should 782 be resolved in the 783 Distributed File System. 784 0x2000 PAGING_IO If set, indicates that a 785 read will be permitted if 786 the client does not have 787 read permission but does 788 have execute permission. 789 This flag is only useful on 790 a read request. 791 0x4000 ERR_STATUS If set, specifies that the NT LM 0.12 792 returned error code is a 32 793 bit error code in 794 Status.Status. Otherwise the 795 Status.DosError.ErrorClass 796 and Status.DosError.Error 797 fields contain the DOS-style 798 error information. When 799 passing NT status codes is 800 negotiated, this flag should 801 be set for every SMB. 802 0x8000 UNICODE If set, any fields of NT LM 0.12 803 datatype STRING in this SMB 804 message are encoded as 805 UNICODE. Otherwise, they 806 are in ASCII. 808 3.2.4 Tid Field 810 Tid represents an instance of an authenticated connection to a server 811 resource. The server returns Tid to the client when the client 812 successfully connects to a resource, and the client uses Tid in 813 subsequent requests referring to the resource. 815 In most SMB requests, Tid must contain a valid value. Exceptions are 816 those used prior to getting a Tid established, including 817 SMB_COM_NEGOTIATE, SMB_COM_TREE_CONNECT_ANDX, SMB_COM_ECHO, and 818 SMB_COM_SESSION_SETUP_ANDX. 0xFFFF should be used for Tid for these 819 situations. The server is always responsible for enforcing use of a 820 valid Tid where appropriate. 822 On SMB_COM_TREE_DISCONNECT over a given transport connection, with a 823 given Tid, the server will close any files opened with that Tid over 824 that connection. 826 3.2.5 Pid Field 828 The Pid field identifies to the server the "process" that opened a file 829 (see SMB_COM_FLUSH) or that owns a byte range lock (see 830 SMB_COM_LOCKING_ANDX). This "process" may or may not correspond to the 831 client operating system's notion of process. 833 The client chooses the value of the Pid field; servers MUST set the Pid 834 field of responses to the same value as in the corresponding request. 835 The Pid is relative to a transport connection -- the same Pid in 836 requests sent over different connections will be considered to represent 837 a different process. 839 3.2.6 Uid Field 841 Uid is a user ID assigned by the server after a user authenticates to 842 it, and that it will associate with that user until the client requests 843 the association be broken. After authentication to the server, the 844 client SHOULD make sure that the Uid is not used for a different user 845 that the one that authenticated. (It is permitted that a single user 846 have more than one Uid.) Requests that do authorization, such as open 847 requests, will perform access checks using the identity associated with 848 the Uid. 850 3.2.7 Mid Field 852 The multiplex ID (Mid) is used to allow multiplexing the single client 853 and server connection among the client's multiple processes, threads, 854 and requests per thread. Clients may have many outstanding requests at 855 one time. Servers MAY respond to requests in any order, but a response 856 message MUST always contain the same Mid value as the corresponding 857 request message. The client MUST NOT have multiple outstanding requests 858 to a server with the same Mid. 860 3.2.8 Status Field 862 An SMB returns error information to the client in the Status field. 863 Protocol dialects prior to NT LM 0.12 return status to the client using 864 the combination of Status.DosError.ErrorClass and Status.DosError.Error. 865 Beginning with NT LM 0.12 CIFS servers can return 32 bit error 866 information to clients using Status.Status if the incoming client SMB 867 has bit 14 set in the Flags2 field of the SMB header. The contents of 868 response parameters are not guaranteed in the case of an error return, 869 and must be ignored. For write-behind activity, a subsequent write or 870 close of the file may return the fact that a previous write failed. 871 Normally write-behind failures are limited to hard disk errors and 872 device out of space. 874 3.2.9 Timeouts 876 In general, SMBs are not expected to block at the server; they should 877 return "immediately". But some SMB requests do indicate timeout periods 878 for the completion of the request on the server. If a server 879 implementation can not support timeouts, then an error can be returned 880 just as if a timeout had occurred if the resource is not available 881 immediately upon request. 883 3.2.10 Data Buffer (BUFFER) and String Formats 885 The data portion of SMBs typically contains the data to be read or 886 written, file paths, or directory paths. The format of the data portion 887 depends on the message. All fields in the data portion have the same 888 format. In every case it consists of an identifier byte followed by the 889 data. 891 Identifier Description Value 892 =============== ========================= ===== 894 Data Block See Below 1 895 Dialect Null terminated String 2 896 Pathname Null terminated String 3 897 ASCII Null terminated String 4 898 Variable block See Below 5 900 When the identifier indicates a data block or variable block then the 901 format is a word indicating the length followed by the data. 903 In all dialects prior to NT LM 0.12, all strings are encoded in ASCII. 904 If the agreed dialect is NT LM 0.12 or later, Unicode strings may be 905 exchanged. Unicode strings include file names, resource names, and user 906 names. This applies to null-terminated strings, length specified 907 strings and the type-prefixed strings. In all cases where a string is 908 passed in Unicode format, the Unicode string must be word-aligned with 909 respect to the beginning of the SMB. Should the string not naturally 910 fall on a two-byte boundary, a null byte of padding will be inserted, 911 and the Unicode string will begin at the next address. In the 912 description of the SMBs, items that may be encoded in Unicode or ASCII 913 are labeled as STRING. If the encoding is ASCII, even if the negotiated 914 string is Unicode, the quantity is labeled as UCHAR. 916 For type-prefixed Unicode strings, the padding byte is found after the 917 type byte. The type byte is 4 (indicating SMB_FORMAT_ASCII) independent 918 of whether the string is ASCII or Unicode. For strings whose start 919 addresses are found using offsets within the fixed part of the SMB (as 920 opposed to simply being found at the byte following the preceding 921 field,) it is guaranteed that the offset will be properly aligned. 923 Strings that are never passed in Unicode are: 925 o The protocol strings in the Negotiate SMB request. 927 o The service name string in the Tree_Connect_AndX SMB. 929 When Unicode is negotiated, the SMB_FLAGS2_UNICODE bit should be set in 930 the Flags2 field of every SMB header. 932 Despite the flexible encoding scheme, no field of a data portion may be 933 omitted or included out of order. In addition, neither a WordCount nor 934 ByteCount of value 0 at the end of a message may be omitted. 936 3.3 File Names 938 File names in the CIFS protocol consist of components separated by a 939 backslash ('\'). Early clients of the CIFS protocol required that the 940 name components adhere to an 8.3 format name. These names consist of 941 two parts: a basename of no more than 8 characters, and an extension of 942 no more than 3 characters. The basename and extension are separated by 943 a '.'. All characters are legal in the basename and extension except 944 the space character (0x20) and: 946 " . / \[]:+|<>=;,*? 948 If the client has indicated long name support by setting bit2 in the 949 Flags2 field of the SMB header, this indicates that the client is not 950 bound by the 8.3 convention. Specifically this indicates that any SMB 951 which returns file names to the client may return names which do not 952 adhere to the 8.3 convention, and have a total length of up to 255 953 characters. This capability was introduced with the LM1.2X002 protocol 954 dialect. 956 3.4 Wildcards 958 Some SMB requests allow wildcards to be given for the filename. The 959 wildcard allows a number of files to be operated on as a unit without 960 having to separately enumerate the files and individually operate on 961 each one from the client. 963 If the client is using 8.3 names, each part of the name ( base (8) or 964 extension (3) ) is treated separately. For long filenames the . in the 965 name is significant even though there is no longer a restriction on the 966 size of each of the components. 968 The ? character is a wild card for a single character. If a filename 969 part commences with one or more "?"s then exactly that number of 970 characters will be matched by the wildcards, e.g., "??x" equals "abx" 971 but not "abcx" or "ax". When a filename part has trailing "?"s then it 972 matches the specified number of characters or less, e.g., "x??" matches 973 "xab", "xa" and "x", but not "xabc". If only "?"s are present in the 974 filename part, then it is handled as for trailing "?"s 976 The * character matches an entire part of the name, as does an empty 977 specification for that part. A part consisting of * means that the rest 978 of the component should be filled with ? and the search should be 979 performed with this wildcard character. For example, "*.abc" or ".abc" 980 match any file with an extension of "abc". "*.*", "*" or "null" match 981 all files in a directory. 983 If the negotiated dialect is "NT LM 0.12" or later, and the client 984 requires MS-DOS wildcard matching semantics, UNICODE wildcards should 985 be translated according to the following rules: 987 Translate the ? literal to > 989 Translate the . literal to " if it is followed by a ? or a * 991 Translate the * literal to < if it is followed by a . 993 The translation can be performed in-place. 995 3.5 DFS Pathnames 997 A DFS pathname adheres to the standard described in the FileNames 998 section. A DFS enabled client accessing a DFS share should set the 999 Flags2 bit 12 in all name based SMB requests indicating to the server 1000 that the enclosed pathname should be resolved in the Distributed File 1001 System namespace. The pathname should always have the full file name, 1002 including the server name and share name. If the server can resolve the 1003 DFS name to a piece of local storage, the local storage will be 1004 accessed. If the server determines that the DFS name actually maps to a 1005 different server share, the access to the name will fail with the 32 bit 1006 status STATUS_PATH_NOT_COVERED (0xC0000257), or DOS error 1007 ERRsrv/ERRbadpath. 1009 On receiving this error, the DFS enabled client should ask the server 1010 for a referral (see TRANS2_GET_DFS_REFERRAL). The referral request 1011 should contain the full file name. 1013 The response to the request will contain a list of server and share 1014 names to try, and the part of the request file name that junctions to 1015 the list of server shares. If the ServerType field of the referral is 1016 set to 1 (SMB server), then the client should resubmit the request with 1017 the original file name to one of the server shares in the list, once 1018 again setting the Flags2 bit 12 bit in the SMB. If the ServerType field 1019 is not 1, then the client should strip off the part of the file name 1020 that junctions to the server share before resubmitting the request to 1021 one of servers in the list. 1023 A response to a referral request may elicit a response that does not 1024 have the StorageServers bit set. In that case, the client should 1025 resubmit the referral request to one of the servers in the list, until 1026 it finally obtains a referral response that has the StorageServers bit 1027 set, at which point the client can resubmit the request SMB to one of 1028 the listed server shares. 1030 If, after getting a referral with the StorageServers bit set and 1031 resubmitting the request to one of the server shares in the list, the 1032 server fails the request with STATUS_PATH_NOT_COVERED, it must be the 1033 case that there is an inconsistency between the view of the DFS 1034 namespace held by the server granting the referral and the server listed 1035 in that referral. In this case, the client may inform the server 1036 granting the referral of this inconsistency via the 1037 TRANS2_REPORT_DFS_INCONSISTENCY SMB. 1039 3.6 Time And Date Encoding 1041 When SMB requests or responses encode time values, the following 1042 describes the various encodings used. 1044 struct { 1045 USHORT Day : 5; 1046 USHORT Month : 4; 1047 USHORT Year : 7; 1048 } SMB_DATE; 1050 The Year field has a range of 0-119, which represents years 1980 - 2099. 1051 The Month is encoded as 1-12, and the day ranges from 1-31 1053 struct { 1054 USHORT TwoSeconds : 5; 1055 USHORT Minutes : 6; 1056 USHORT Hours : 5; 1057 } SMB_TIME; 1059 Hours ranges from 0-23, Minutes range from 0-59, and TwoSeconds ranges 1060 from 0-29 representing two second increments within the minute. 1062 typedef struct { 1063 ULONG LowTime; 1064 LONG HighTime; 1065 } TIME; 1067 TIME indicates a signed 64-bit integer representing either an absolute 1068 time or a time interval. Times are specified in units of 100ns. A 1069 positive value expresses an absolute time, where the base time (the 64- 1070 bit integer with value 0) is the beginning of the year 1601 AD in the 1071 Gregorian calendar. A negative value expresses a time interval relative 1072 to some base time, usually the current time. 1074 typedef unsigned long UTIME; 1076 UTIME is the number of seconds since Jan 1, 1970, 00:00:00.0. 1078 3.7 Access Mode Encoding 1080 Various client requests and server responses, such as SMB_COM_OPEN, pass 1081 file access modes encoded into a USHORT. The encoding of these is as 1082 follows: 1084 1111 11 1085 5432 1098 7654 3210 1086 rWrC rLLL rSSS rAAA 1088 where: 1090 W - Write through mode. No read ahead or write behind allowed on 1091 this file or device. When the response is returned, data is 1092 expected to be on the disk or device. 1094 S - Sharing mode: 1095 0 - Compatibility mode 1096 1 - Deny read/write/execute (exclusive) 1097 2 - Deny write 1098 3 - Deny read/execute 1099 4 - Deny none 1101 A - Access mode 1102 0 - Open for reading 1103 1 - Open for writing 1104 2 - Open for reading and writing 1105 3 - Open for execute 1107 rSSSrAAA = 11111111 (hex FF) indicates FCB open (???) 1109 C - Cache mode 1110 0 - Normal file 1111 1 - Do not cache this file 1113 L - Locality of reference 1114 0 - Locality of reference is unknown 1115 1 - Mainly sequential access 1116 2 - Mainly random access 1117 3 - Random access with some locality 1118 4 to 7 - Currently undefined 1120 3.8 Access Mask Encoding 1122 The ACCESS_MASK structure is one 32 bit value containing standard, 1123 specific, and generic rights. These rights are used in access-control 1124 entries (ACEs) and are the primary means of specifying the requested or 1125 granted access to an object. 1127 The bits in this value are allocated as follows: 1129 Bits Meaning 1130 0 - 15 Specific rights. Contains the access mask specific to the 1131 object type associated with the mask. 1132 16 - 23 Standard rights. Contains the object's standard access rights 1133 and can be a combination of the following predefined flags: 1135 Bit Flag Meaning 1137 16 DELETE Delete access 1138 17 READ_CONTROL Read access to the owner, group, and 1139 discretionary access-control list (ACL) of the 1140 security descriptor 1141 18 WRITE_DAC Write access to the discretionary access- 1142 control list (ACL) 1143 19 WRITE_OWNER Write access to owner 1144 20 SYNCHRONIZE Windows NT: Synchronize access 1146 Bits Meaning 1148 24 Access system security (ACCESS_SYSTEM_SECURITY). This flag is 1149 not a typical access type. It is used to indicate access to a 1150 system ACL. This type of access requires the calling process to 1151 have a specific privilege. 1152 25 Maximum allowed (MAXIMUM_ALLOWED) 1153 26, 27 Reserved 1154 28 Generic all (GENERIC_ALL) 1155 29 Generic execute (GENERIC_EXECUTE) 1156 30 Generic write (GENERIC_WRITE) 1157 31 Generic read (GENERIC_READ) 1159 3.9 Open Function Encoding 1161 OpenFunction specifies the action to be taken depending on whether or 1162 not the file exists. This word has the following format: 1164 bits: 1166 1111 11 1167 5432 1098 7654 3210 1168 rrrr rrrr rrrC rrOO 1169 where: 1171 C - Create (action to be taken if file does not exist). 1172 0 -- Fail. 1173 1 -- Create file. 1175 r - reserved (must be zero). 1177 O - Open (action to be taken if file exists). 1178 0 - Fail. 1179 1 - Open file. 1180 2 - Truncate file. 1182 3.10 Open Action Encoding 1184 Action in the response to an open or create request describes the action 1185 taken as a result of the request. It has the following format: 1187 bits: 1189 1111 11 1190 5432 1098 7654 3210 1191 Lrrr rrrr rrrr rrOO 1193 where: 1195 L - Lock (single user total file lock status). 1196 0 -- file opened by another user (or mode not supported by server). 1197 1 -- file is opened only by this user at the present time. 1199 r - reserved (must be zero). 1201 O - Open (action taken on Open). 1202 1 - The file existed and was opened. 1203 2 - The file did not exist but was created. 1204 3 - The file existed and was truncated. 1206 3.11 File Attribute Encoding 1208 When SMB messages exchange file attribute information, it is encoded in 1209 16 bits as: 1211 Value Description 1212 ======= ===================== 1214 0x01 Read only file 1215 0x02 Hidden file 1216 0x04 System file 1217 0x08 Volume 1218 0x10 Directory 1219 0x20 Archive file 1220 others Reserved - must be 0 1222 3.12 Extended File Attribute Encoding 1224 The extended file attributes is a 32 bit value composed of attributes 1225 and flags. 1227 Any combination of the following attributes is acceptable, except all 1228 other file attributes override FILE_ATTR_NORMAL: 1230 Name Value Meaning 1231 ==== ===== ======= 1232 ATTR_ARCHIVE 0x020 The file has not been archived since it was 1233 last modified. Applications use this 1234 attribute to mark files for backup or 1235 removal. 1236 ATTR_COMPRESSED 0x800 The file or directory is compressed. For a 1237 file, this means that all of the data in the 1238 file is compressed. For a directory, this 1239 means that compression is the default for 1240 newly created files and subdirectories. 1241 ATTR_NORMAL 0x080 The file has no other attributes set. This 1242 attribute is valid only if used alone. 1243 ATTR_HIDDEN 0x002 The file is hidden. It is not to be included 1244 in an ordinary directory listing. 1245 ATTR_READONLY 0x001 The file is read only. Applications can read 1246 the file but cannot write to it or delete it. 1247 ATTR_TEMPORARY 0x100 The file is temporary 1248 ATTR_DIRECTORY 0x010 The file is a directory 1249 ATTR_SYSTEM 0x004 The file is part of or is used exclusively by 1250 the operating system. 1252 Any combination of the following flags is acceptable: 1254 Name Value Meaning 1255 ==== ===== ======= 1256 WRITE_THROUGH 0x80000000 Instructs the operating system to write 1257 through any intermediate cache and go 1258 directly to the file. The operating 1259 system can still cache write 1260 operations, but cannot lazily flush 1261 them. 1262 NO_BUFFERING 0x20000000 Requests the server to open the file 1263 with no intermediate buffering or 1264 caching; the server is not obliged to 1265 honor the request. An application must 1266 meet certain requirements when working 1267 with files opened with 1268 FILE_FLAG_NO_BUFFERING. File access 1269 must begin at offsets within the file 1270 that are integer multiples of the 1271 volume's sector size; and must be for 1272 numbers of bytes that are integer 1273 multiples of the volume's sector size. 1274 For example, if the sector size is 512 1275 bytes, an application can request reads 1276 and writes of 512, 1024, or 2048 bytes, 1277 but not of 335, 981, or 7171 bytes. 1278 RANDOM_ACCESS 0x10000000 Indicates that the application intends 1279 to access the file randomly. The server 1280 MAY use this flag to optimize file 1281 caching. 1282 SEQUENTIAL_SCAN 0x08000000 Indicates that the file is to be 1283 accessed sequentially from beginning to 1284 end. Windows uses this flag to optimize 1285 file caching. If an application moves 1286 the file pointer for random access, 1287 optimum caching may not occur; however, 1288 correct operation is still guaranteed. 1289 Specifying this flag can increase 1290 performance for applications that read 1291 large files using sequential access. 1292 Performance gains can be even more 1293 noticeable for applications that read 1294 large files mostly sequentially, but 1295 occasionally skip over small ranges of 1296 bytes. 1297 DELETE_ON_CLOSE 0x04000000 Requests that the server is delete the 1298 file immediately after all of its 1299 handles have been closed. 1301 BACKUP_SEMANTICS 0x02000000 Indicates that the file is being opened 1302 or created for a backup or restore 1303 operation. The server SHOULD allow the 1304 client to override normal file security 1305 checks, provided it has the necessary 1306 permission to do so. 1307 POSIX_SEMANTICS 0x01000000 Indicates that the file is to be 1308 accessed according to POSIX rules. This 1309 includes allowing multiple files with 1310 names differing only in case, for file 1311 systems that support such naming. (Use 1312 care when using this option because 1313 files created with this flag may not be 1314 accessible by applications written for 1315 MS-DOS, Windows 3.x, or Windows NT.) 1317 3.13 Batching Requests ("AndX" Messages) 1319 LANMAN1.0 and later dialects of the CIFS protocol allow multiple SMB 1320 requests to be sent in one message to the server. Messages of this type 1321 are called AndX SMBs, and they obey the following rules: 1323 o The embedded command does not repeat the SMB header information. 1324 Rather the next SMB starts at the WordCount field. 1326 o All multiple (chained) requests must fit within the negotiated 1327 transmit size. For example, if SMB_COM_TREE_CONNECT_ANDX included 1328 OPENandX SMB_COM_OPEN_ANDX which included SMB_COM_WRITE were sent, 1329 they would all have to fit within the negotiated buffer size. This 1330 would limit the size of the write. 1332 o There is one message sent containing the chained requests and there 1333 is one response message to the chained requests. The server may NOT 1334 elect to send separate responses to each of the chained requests. 1336 o All chained responses must fit within the negotiated transmit size. 1337 This limits the maximum value on an embedded SMB_COM_READ for 1338 example. It is the client's responsibility to not request more bytes 1339 than will fit within the multiple response. 1341 o The server will implicitly use the result of the first command in the 1342 "X" command. For example the Tid obtained via 1343 SMB_COM_TREE_CONNECT_ANDX would be used in the embedded 1344 SMB_COM_OPEN_ANDX and the Fid obtained in the SMB_COM_OPEN_ANDX would 1345 be used in the embedded SMB_COM_READ. 1347 o Each chained request can only reference the same Fid and Tid as the 1348 other commands in the combined request. The chained requests can be 1349 thought of as performing a single (multi-part) operation on the same 1350 resource. 1352 o The first Command to encounter an error will stop all further 1353 processing of embedded commands. The server will not back out 1354 commands that succeeded. Thus if a chained request contained 1355 SMB_COM_OPEN_ANDX and SMB_COM_READ and the server was able to open 1356 the file successfully but the read encountered an error, the file 1357 would remain open. This is exactly the same as if the requests had 1358 been sent separately. 1360 o If an error occurs while processing chained requests, the last 1361 response (of the chained responses in the buffer) will be the one 1362 which encountered the error. Other unprocessed chained requests will 1363 have been ignored when the server encountered the error and will not 1364 be represented in the chained response. Actually the last valid 1365 AndXCommand (if any) will represent the SMB on which the error 1366 occurred. If no valid AndXCommand is present, then the error 1367 occurred on the first request/response and Command contains the 1368 command which failed. In all cases the error information are 1369 returned in the SMB header at the start of the response buffer. 1371 o Each chained request and response contains the offset (from the start 1372 of the SMB header) to the next chained request/response (in the 1373 AndXOffset field in the various "and X" protocols defined later e.g. 1374 SMB_COM_OPEN_ANDX). This allows building the requests unpacked. 1375 There may be space between the end of the previous request (as 1376 defined by WordCount and ByteCount) and the start of the next chained 1377 request. This simplifies the building of chained protocol requests. 1378 Note that because the client must know the size of the data being 1379 returned in order to post the correct number of receives (e.g. 1380 SMB_COM_TRANSACTION, SMB_COM_READ_MPX), the data in each response SMB 1381 is expected to be truncated to the maximum number of 512 byte blocks 1382 (sectors) which will fit (starting at a 32 bit boundary) in the 1383 negotiated buffer size with the odd bytes remaining (if any) in the 1384 final buffer. 1386 3.14 "Transaction" Style Subprotocols 1388 The "transaction" style subprotocols are used for commands that 1389 potentially need to transfer a large amount of data (greater than 64K 1390 bytes). 1392 3.14.1 SMB_COM_TRANSACTION2 Format 1394 Primary Client Request Description 1395 =============================== ==================================== 1397 Command SMB_COM_TRANSACTION2 1398 UCHAR WordCount; Count of parameter words; value = 1399 (14 + SetupCount) 1400 USHORT TotalParameterCount; Total parameter bytes being sent 1401 USHORT TotalDataCount; Total data bytes being sent 1402 USHORT MaxParameterCount; Max parameter bytes to return 1403 USHORT MaxDataCount; Max data bytes to return 1404 UCHAR MaxSetupCount; Max setup words to return 1405 UCHAR Reserved; 1406 USHORT Flags; Additional information: 1407 bit 0 - also disconnect TID in TID 1408 ULONG Timeout; 1409 USHORT Reserved2; 1410 USHORT ParameterCount; Parameter bytes sent this buffer 1411 USHORT ParameterOffset; Offset (from header start) to 1412 Parameters 1413 USHORT DataCount; Data bytes sent this buffer 1414 USHORT DataOffset; Offset (from header start) to data 1415 UCHAR SetupCount; Count of setup words 1416 UCHAR Reserved3; Reserved (pad above to word) 1417 USHORT Setup[SetupCount]; Setup words (# = SetupWordCount) 1418 USHORT ByteCount; Count of data bytes 1419 STRING Name[]; Must be NULL 1420 UCHAR Pad[]; Pad to SHORT or LONG 1421 UCHAR Parameters[ Parameter bytes (# = ParameterCount) 1422 ParameterCount]; 1423 UCHAR Pad1[]; Pad to SHORT or LONG 1424 UCHAR Data[ DataCount ]; Data bytes (# = DataCount) 1426 Interim Server Response Description 1427 =============================== ==================================== 1429 UCHAR WordCount; Count of parameter words = 0 1430 USHORT ByteCount; Count of data bytes = 0 1431 Secondary Client Request Description 1432 =============================== ==================================== 1434 Command SMB_COM_TRANSACTION_SECONDARY 1436 UCHAR WordCount; Count of parameter words = 8 1437 USHORT TotalParameterCount; Total parameter bytes being sent 1438 USHORT TotalDataCount; Total data bytes being sent 1439 USHORT ParameterCount; Parameter bytes sent this buffer 1440 USHORT ParameterOffset; Offset (from header start) to 1441 Parameters 1442 USHORT ParameterDisplacement; Displacement of these Parameter 1443 bytes 1444 USHORT DataCount; Data bytes sent this buffer 1445 USHORT DataOffset; Offset (from header start) to data 1446 USHORT DataDisplacement; Displacement of these data bytes 1447 USHORT Fid; FID for handle based requests, else 1448 0xFFFF. This field is present only 1449 if this is an SMB_COM_TRANSACTION2 1450 request. 1451 USHORT ByteCount; Count of data bytes 1452 UCHAR Pad[]; Pad to SHORT or LONG 1453 UCHAR Parameter bytes (# = ParameterCount) 1454 Parameters[ParameterCount]; 1455 UCHAR Pad1[]; Pad to SHORT or LONG 1456 UCHAR Data[DataCount]; Data bytes (# = DataCount) 1457 Server Response Description 1458 =============================== ==================================== 1460 UCHAR WordCount; Count of data bytes; value = 10 + 1461 SetupCount 1462 USHORT TotalParameterCount; Total parameter bytes being sent 1463 USHORT TotalDataCount; Total data bytes being sent 1464 USHORT Reserved; 1465 USHORT ParameterCount; Parameter bytes sent this buffer 1466 USHORT ParameterOffset; Offset (from header start) to 1467 Parameters 1468 USHORT ParameterDisplacement; Displacement of these Parameter 1469 bytes 1470 USHORT DataCount; Data bytes sent this buffer 1471 USHORT DataOffset; Offset (from header start) to data 1472 USHORT DataDisplacement; Displacement of these data bytes 1473 UCHAR SetupCount; Count of setup words 1474 UCHAR Reserved2; Reserved (pad above to word) 1475 USHORT Setup[SetupWordCount]; Setup words (# = SetupWordCount) 1476 USHORT ByteCount; Count of data bytes 1477 UCHAR Pad[]; Pad to SHORT or LONG 1478 UCHAR Parameter bytes (# = ParameterCount) 1479 Parameters[ParameterCount]; 1480 UCHAR Pad1[]; Pad to SHORT or LONG 1481 UCHAR Data[DataCount]; Data bytes (# = DataCount) 1483 3.14.2 3.13.2 SMB_COM_NT_TRANSACTION Formats 1485 Primary Client Request Description 1486 =============================== ==================================== 1488 UCHAR WordCount; Count of parameter words; value = 1489 (19 + SetupCount) 1490 UCHAR MaxSetupCount; Max setup words to return 1491 USHORT Reserved; 1492 ULONG TotalParameterCount; Total parameter bytes being sent 1493 ULONG TotalDataCount; Total data bytes being sent 1494 ULONG MaxParameterCount; Max parameter bytes to return 1495 ULONG MaxDataCount; Max data bytes to return 1496 ULONG ParameterCount; Parameter bytes sent this buffer 1497 ULONG ParameterOffset; Offset (from header start) to 1498 Parameters 1499 ULONG DataCount; Data bytes sent this buffer 1500 ULONG DataOffset; Offset (from header start) to data 1501 UCHAR SetupCount; Count of setup words 1502 USHORT Function; The transaction function code 1503 UCHAR Buffer[1]; 1504 USHORT Setup[SetupWordCount]; Setup words 1505 USHORT ByteCount; Count of data bytes 1506 UCHAR Pad1[]; Pad to LONG 1507 UCHAR Parameter bytes 1508 Parameters[ParameterCount]; 1509 UCHAR Pad2[]; Pad to LONG 1510 UCHAR Data[DataCount]; Data 1511 bytes 1513 Interim Server Response Description 1514 =============================== ==================================== 1516 UCHAR WordCount; Count of parameter words = 0 1517 USHORT ByteCount; Count of data bytes = 0 1519 Secondary Client Request Description 1520 =============================== ==================================== 1522 UCHAR WordCount; Count of parameter words = 18 1523 UCHAR Reserved[3]; MBZ 1524 ULONG TotalParameterCount; Total parameter bytes being sent 1525 ULONG TotalDataCount; Total data bytes being sent 1526 ULONG ParameterCount; Parameter bytes sent this buffer 1527 ULONG ParameterOffset; Offset (from header start) to 1528 Parameters 1529 ULONG ParameterDisplacement; Specifies the offset from the start 1530 of the overall parameter block to 1531 the parameter bytes that are 1532 contained in this message 1533 ULONG DataCount; Data bytes sent this buffer 1534 ULONG DataOffset; Offset (from header start) to data 1535 ULONG DataDisplacement; Specifies the offset from the start 1536 of the overall data block to the 1537 data bytes that are contained in 1538 this message. 1539 UCHAR Reserved1; 1540 USHORT ByteCount; Count of data bytes 1541 UCHAR Pad1[]; Pad to LONG 1542 UCHAR Parameter bytes 1543 Parameters[ParameterCount]; 1544 UCHAR Pad2[]; Pad to LONG 1545 UCHAR Data[DataCount]; Data bytes 1546 Server Response Description 1547 =============================== ==================================== 1549 UCHAR WordCount; Count of data bytes; value = 18 + 1550 SetupCount 1551 UCHAR Reserved[3]; 1552 ULONG TotalParameterCount; Total parameter bytes being sent 1553 ULONG TotalDataCount; Total data bytes being sent 1554 ULONG ParameterCount; Parameter bytes sent this buffer 1555 ULONG ParameterOffset; Offset (from header start) to 1556 Parameters 1557 ULONG ParameterDisplacement; Specifies the offset from the start 1558 of the overall parameter block to 1559 the parameter bytes that are 1560 contained in this message 1561 ULONG DataCount; Data bytes sent this buffer 1562 ULONG DataOffset; Offset (from header start) to data 1563 ULONG DataDisplacement; Specifies the offset from the start 1564 of the overall data block to the 1565 data bytes that are contained in 1566 this message. 1567 UCHAR SetupCount; Count of setup words 1568 USHORT Setup[SetupWordCount]; Setup words 1569 USHORT ByteCount; Count of data bytes 1570 UCHAR Pad1[]; Pad to LONG 1571 UCHAR Parameter bytes 1572 Parameters[ParameterCount]; 1573 UCHAR Pad2[]; Pad to SHORT or LONG 1574 UCHAR Data[DataCount]; Data bytes 1576 3.14.3 Functional Description 1578 The transaction Setup information and/or Parameters define functions 1579 specific to a particular resource on a particular server. Therefore the 1580 functions supported are not defined by the transaction sub-protocol. 1581 The transaction protocol simply provides a means of delivering them and 1582 retrieving the results. 1584 The number of bytes needed in order to perform the transaction request 1585 may be more than will fit in a single buffer. 1587 At the time of the request, the client knows the number of parameter and 1588 data bytes expected to be sent and passes this information to the server 1589 via the primary request (TotalParameterCount and TotalDataCount). This 1590 may be reduced by lowering the total number of bytes expected 1591 (TotalParameterCount and TotalDataCount) in each (if any) secondary 1592 request. 1594 When the amount of parameter bytes received (total of each 1595 ParameterCount) equals the total amount of parameter bytes expected 1596 (smallest TotalParameterCount) received, then the server has received 1597 all the parameter bytes. 1599 Likewise, when the amount of data bytes received (total of each 1600 DataCount) equals the total amount of data bytes expected (smallest 1601 TotalDataCount) received, then the server has received all the data 1602 bytes. 1604 The parameter bytes should normally be sent first followed by the data 1605 bytes. However, the server knows where each begins and ends in each 1606 buffer by the offset fields (ParameterOffset and DataOffset) and the 1607 length fields (ParameterCount and DataCount). The displacement of the 1608 bytes (relative to start of each) is also known (ParameterDisplacement 1609 and DataDisplacement). Thus the server is able to reassemble the 1610 parameter and data bytes should the individual requests be received out 1611 of sequence. 1613 If all parameter bytes and data bytes fit into a single buffer, then no 1614 interim response is expected and no secondary request is sent. 1616 The client knows the maximum amount of data bytes and parameter bytes 1617 which the server may return (from MaxParameterCount and MaxDataCount of 1618 the request). Thus the client initializes its bytes expected variables 1619 to these values. The server then informs the client of the actual 1620 amounts being returned via each message of the server response 1621 (TotalParameterCount and TotalDataCount). The server may reduce the 1622 expected bytes by lowering the total number of bytes expected 1623 (TotalParameterCount and/or TotalDataCount) in each (any) response. 1625 When the amount of parameter bytes received (total of each 1626 ParameterCount) equals the total amount of parameter bytes expected 1627 (smallest TotalParameterCount) received, then the client has received 1628 all the parameter bytes. 1630 Likewise, when the amount of data bytes received (total of each 1631 DataCount) equals the total amount of data bytes expected (smallest 1632 TotalDataCount) received, then the client has received all the data 1633 bytes. 1635 The parameter bytes should normally be returned first followed by the 1636 data bytes. However, the client knows where each begins and ends in 1637 each buffer by the offset fields (ParameterOffset and DataOffset) and 1638 the length fields (ParameterCount and DataCount). The displacement of 1639 the bytes (relative to start of each) is also known 1640 (ParameterDisplacement and DataDisplacement). The client is able to 1641 reassemble the parameter and data bytes should the server responses be 1642 received out of sequence. 1644 The flow for these transactions over a connection oriented transport is: 1646 1. The client sends the primary client request identifying the total 1647 bytes (both parameters and data) which are expected to be sent and 1648 contains the set up words and as many of the parameter and data bytes 1649 as will fit in a negotiated size buffer. This request also identifies 1650 the maximum number of bytes (setup, parameters and data) the server is 1651 to return on the transaction completion. If all the bytes fit in the 1652 single buffer, skip to step 4. 1654 2. The server responds with a single interim response meaning "OK, send 1655 the remainder of the bytes" or (if error response) terminate the 1656 transaction. 1658 3. The client then sends another buffer full of bytes to the server. 1659 This step is repeated until all of the bytes are sent and received. 1661 4. The Server sets up and performs the transaction with the information 1662 provided. 1664 5. Upon completion of the transaction, the server sends back (up to) 1665 the number of parameter and data bytes requested (or as many as will 1666 fit in the negotiated buffer size). This step is repeated until all 1667 result bytes have been returned. 1669 The flow for the transaction protocol when the request parameters and 1670 data do not all fit in a single buffer is: 1672 Client <-> Server 1673 =============================== ==== ============================== 1675 Primary TRANSACTION request -> 1676 <- Interim Server Response 1677 Secondary TRANSACTION request 1 -> 1678 Secondary TRANSACTION request 2 -> 1679 Secondary TRANSACTION request N -> 1680 <- TRANSACTION response 1 1681 <- TRANSACTION response 2 1682 <- TRANSACTION response m 1684 The flow for the transaction protocol when the request parameters and 1685 data does all fit in a single buffer is: 1687 Client <-> Server 1688 =============================== ==== ============================== 1690 Primary TRANSACTION request -> 1691 <- TRANSACTION response 1 1692 <- TRANSACTION response 2 1693 <- TRANSACTION response m 1695 The primary transaction request through the final response make up the 1696 complete transaction exchange, thus the Tid, Pid, Uid and Mid must remain 1697 constant and can be used as appropriate by both the server and the 1698 client. Of course, other SMB requests may intervene as well. 1700 There are (at least) three ways that actual server responses have been 1701 observed to differ from what might be expected. First, some servers will 1702 send Pad bytes to move the DataOffset to a 2- or 4-byte boundary even if 1703 there are no data bytes; the point here is that the ByteCount must be 1704 used instead of ParameterOffset plus ParameterCount to infer the actual 1705 message length. Second, some servers always return MaxParameterCount 1706 bytes even if the particular Transact2 has no parameter response. 1707 Finally, in case of an error, some servers send the "traditional 1708 WordCount==0/ByteCount==0" response while others generate a Transact 1709 response format. 1711 3.15 Valid SMB Requests by Negotiated Dialect 1713 CIFS clients and servers may exchange the following SMB messages if the 1714 "PC NETWORK PROGRAM 1.0" dialect is negotiated: 1716 SMB_COM_CREATE_DIRECTORY SMB_COM_DELETE_DIRECTORY 1717 SMB_COM_OPEN SMB_COM_CREATE 1718 SMB_COM_CLOSE SMB_COM_FLUSH 1719 SMB_COM_DELETE SMB_COM_RENAME 1720 SMB_COM_QUERY_INFORMATION SMB_COM_SET_INFORMATION 1721 SMB_COM_READ SMB_COM_WRITE 1722 SMB_COM_LOCK_BYTE_RANGE SMB_COM_UNLOCK_BYTE_RANGE 1723 SMB_COM_CREATE_TEMPORARY SMB_COM_CREATE_NEW 1724 SMB_COM_CHECK_DIRECTORY SMB_COM_PROCESS_EXIT 1725 SMB_COM_SEEK SMB_COM_TREE_CONNECT 1726 SMB_COM_TREE_DISCONNECT SMB_COM_NEGOTIATE 1727 SMB_COM_QUERY_INFORMATION_DISK SMB_COM_SEARCH 1728 SMB_COM_OPEN_PRINT_FILE SMB_COM_WRITE_PRINT_FILE 1729 SMB_COM_CLOSE_PRINT_FILE SMB_COM_GET_PRINT_QUEUE 1730 If the "LANMAN 1.0" dialect is negotiated, all of the messages in the 1731 previous list must be supported. Clients negotiating LANMAN 1.0 and 1732 higher dialects will probably no longer send SMB_COM_PROCESS_EXIT, and 1733 the response format for SMB_COM_NEGOTIATE is modified as well. New 1734 messages introduced with the LANMAN 1.0 dialect are: 1736 SMB_COM_LOCK_AND_READ SMB_COM_WRITE_AND_UNLOCK 1737 SMB_COM_READ_RAW SMB_COM_READ_MPX 1738 SMB_COM_WRITE_MPX SMB_COM_WRITE_RAW 1739 SMB_COM_WRITE_COMPLETE SMB_COM_WRITE_MPX_SECONDARY 1740 SMB_COM_SET_INFORMATION2 SMB_COM_QUERY_INFORMATION2 1741 SMB_COM_LOCKING_ANDX SMB_COM_TRANSACTION 1742 SMB_COM_TRANSACTION_SECONDARY SMB_COM_IOCTL 1743 SMB_COM_IOCTL_SECONDARY SMB_COM_COPY 1744 SMB_COM_MOVE SMB_COM_ECHO 1745 SMB_COM_WRITE_AND_CLOSE SMB_COM_OPEN_ANDX 1746 SMB_COM_READ_ANDX SMB_COM_WRITE_ANDX 1747 SMB_COM_SESSION_SETUP_ANDX SMB_COM_TREE_CONNECT_ANDX 1748 SMB_COM_FIND SMB_COM_FIND_UNIQUE 1749 SMB_COM_FIND_CLOSE 1751 The "LM1.2X002" dialect introduces these new SMBs: 1753 SMB_COM_TRANSACTION2 SMB_COM_TRANSACTION2_SECONDARY 1754 SMB_COM_FIND_CLOSE2 SMB_COM_LOGOFF_ANDX 1756 "NT LM 0.12" dialect introduces: 1758 SMB_COM_NT_TRANSACT SMB_COM_NT_TRANSACT_SECONDARY 1759 SMB_COM_NT_CREATE_ANDX SMB_COM_NT_CANCEL 1760 SMB_COM_NT_RENAME 1762 4 SMB Requests 1764 This section lists the "best practice" SMB requests -- ones that would 1765 permit a client to exercise full CIFS functionality and optimum 1766 performance when interoperating with a server speaking the latest 1767 dialect as of this writing ("NT LM 0.12"). 1769 Note that, as of this writing, no existing client restricts itself to 1770 only these requests, so no useful server can be written that supports 1771 just them. The classification is provided so that future clients will be 1772 written to permit future servers to be simpler. 1774 4.1 Session Requests 1776 4.1.1 NEGOTIATE: Negotiate Protocol 1778 Client Request Description 1779 ============================ ======================================= 1781 UCHAR WordCount; Count of parameter words = 0 1782 USHORT ByteCount; Count of data bytes; min = 2 1783 struct { 1784 UCHAR BufferFormat; 0x02 -- Dialect 1785 UCHAR DialectName[]; ASCII null-terminated string 1786 } Dialects[]; 1788 The Client sends a list of dialects that it can communicate with. The 1789 response is a selection of one of those dialects (numbered 0 through n) 1790 or -1 (hex FFFF) indicating that none of the dialects were acceptable. 1791 The negotiate message is binding on the virtual circuit and must be 1792 sent. One and only one negotiate message may be sent, subsequent 1793 negotiate requests will be rejected with an error response and no action 1794 will be taken. 1796 The protocol does not impose any particular structure to the dialect 1797 strings. Implementers of particular protocols may choose to include, 1798 for example, version numbers in the string. 1800 If the server does not understand any of the dialect strings, or if PC 1801 NETWORK PROGRAM 1.0 is the chosen dialect, the response format is 1803 Server Response Description 1804 ============================ ======================================= 1806 UCHAR WordCount; Count of parameter words = 1 1807 USHORT DialectIndex; Index of selected dialect 1808 USHORT ByteCount; Count of data bytes = 0 1809 If the chosen dialect is greater than core up to and including 1810 LANMAN2.1, the protocol response format is 1812 Server Response Description 1813 ============================ ======================================= 1815 UCHAR WordCount; Count of parameter words = 13 1816 USHORT DialectIndex; Index of selected dialect 1817 USHORT SecurityMode; Security mode: 1818 bit 0: 0 = share, 1 = user 1819 bit 1: 1 = use challenge/response 1820 authentication 1821 USHORT MaxBufferSize; Max transmit buffer size (>= 1024) 1822 USHORT MaxMpxCount; Max pending multiplexed requests 1823 USHORT MaxNumberVcs; Max VCs between client and server 1824 USHORT RawMode; Raw modes supported: 1825 bit 0: 1 = Read Raw supported 1826 bit 1: 1 = Write Raw supported 1827 ULONG SessionKey; Unique token identifying this session 1828 SMB_TIME ServerTime; Current time at server 1829 SMB_DATE ServerDate; Current date at server 1830 USHORT ServerTimeZone; Current time zone at server 1831 USHORT ChallengeLength; Length of Challenge; MBZ if not LM2.1 1832 dialect or later 1833 USHORT Reserved; MBZ 1834 USHORT ByteCount Count of data bytes 1835 UCHAR Challenge[]; The challenge 1836 STRING PrimaryDomain[]; The server's primary domain 1838 MaxBufferSize is the size of the largest message which the client can 1839 legitimately send to the server. 1841 If bit0 of the Flags field is set in the negotiate response, this 1842 indicates the server supports the obsolescent SMB_COM_LOCK_AND_READ and 1843 SMB_COM_WRITE_AND_UNLOCK client requests. 1845 If the SecurityMode field indicates the server is running in user mode, 1846 the client must send appropriate SMB_COM_SESSION_SETUP_ANDX requests 1847 before the server will allow the client to access resources. If the 1848 SecurityMode field indicates the client should use challenge/response 1849 authentication, the client should use the authentication mechanism 1850 specified in the CIFS Security document. 1852 Clients using the "MICROSOFT NETWORKS 1.03" dialect use a different 1853 form of raw reads than documented here, and servers are better off 1854 setting RawMode in this response to 0 for such sessions. 1856 If the negotiated dialect is "DOS LANMAN2.1" or "LANMAN2.1", then 1857 PrimaryDomain string should be included in this response. 1859 If the negotiated dialect is NT LM 0.12, the response format is 1861 Server Response Description 1862 ===================== ========================================= 1863 = 1864 UCHAR WordCount; Count of parameter words = 17 1865 USHORT DialectIndex; Index of selected dialect 1866 UCHAR SecurityMode; Security mode: 1867 bit 0: 0 = share, 1 = user 1868 bit 1: 1 = use challenge/response 1869 authentication 1870 bit 2: 1 = Security Signatures (SMB integrity 1871 check) enabled 1872 bit 3: 1 = Security Signatures (SMB integrity 1873 check) required 1874 USHORT MaxMpxCount; Max pending outstanding requests 1875 USHORT MaxNumberVcs; Max VCs between client and server 1876 ULONG MaxBufferSize; Max transmit buffer size 1877 ULONG MaxRawSize; Maximum raw buffer size 1878 ULONG SessionKey; Unique token identifying this session 1879 ULONG Capabilities; Server capabilities 1880 ULONG SystemTimeLow; System (UTC) time of the server (low). 1881 ULONG SystemTimeHigh; System (UTC) time of the server (high). 1882 USHORT Time zone of server (minutes from UTC) 1883 ServerTimeZone; 1884 UCHAR Length of SecurityBlob 1885 SecurityBlobLength; 1886 USHORT ByteCount; Count of data bytes 1887 UCHAR GUID[16] A globally unique identifier assigned to the 1888 server; present only when 1889 CAP_EXTENDED_SECURITY is on in the 1890 Capabilities field. 1891 UCHAR SecurityBlob[] Opaque Security Blob associated with the 1892 security package if CAP_EXTENDED_SECURITY is 1893 on in the Capabilities field; else challenge 1894 for CIFS challenge/response authentication. 1895 UCHAR The name of the domain (in OEM chars); not 1896 OemDomainName[]; present if CAP_EXTENDED_SECURITY is on in the 1897 Capabilities field 1899 In addition to the definitions above, MaxBufferSize is the size of the 1900 largest message which the client can legitimately send to the server. 1901 If the client is using a connectionless protocol, MaxBufferSize must be 1902 set to the smaller of the server's internal buffer size and the amount 1903 of data which can be placed in a response packet. 1905 MaxRawSize specifies the maximum message size the server can send or 1906 receive for the obsolescent SMB_COM_WRITE_RAW or SMB_COM_READ_RAW 1907 requests. 1909 Capabilities allows the server to tell the client what it supports. The 1910 bit definitions are: 1912 Capability Name Encoding Meaning 1913 ==================== ======== ================================== 1914 CAP_RAW_MODE 0x0001 The server supports 1915 SMB_COM_READ_RAW and 1916 SMB_COM_WRITE_RAW (obsolescent) 1917 CAP_MPX_MODE 0x0002 The server supports 1918 SMB_COM_READ_MPX and 1919 SMB_COM_WRITE_MPX (obsolescent) 1920 CAP_UNICODE 0x0004 The server supports Unicode 1921 strings 1922 CAP_LARGE_FILES 0x0008 The server supports large files 1923 with 64 bit offsets 1924 CAP_NT_SMBS 0x0010 The server supports the SMBs 1925 particular to the NT LM 0.12 1926 dialect. Implies CAP_NT_FIND. 1927 CAP_RPC_REMOTE_APIS 0x0020 The server supports remote admin 1928 API requests via DCE RPC 1929 CAP_STATUS32 0x0040 The server can respond with 32 bit 1930 status codes in Status.Status 1931 CAP_LEVEL_II_OPLOCKS 0x0080 The server supports level 2 1932 oplocks 1933 CAP_LOCK_AND_READ 0x0100 The server supports the 1934 SMB_COM_LOCK_AND_READ SMB 1935 CAP_NT_FIND 0x0200 1936 CAP_DFS 0x1000 The server is DFS aware 1937 CAP_LARGE_READX 0x4000 The server supports large 1938 SMB_COM_READ_ANDX 1939 CAP_LARGE_WRITEX 0x8000 The server supports large 1940 SMB_COM_READ_ANDX 1941 CAP_RESERVED 0x02000000 Reserved for future use. 1942 CAP_EXTENDED_SECURITY 0x80000000 The server supports extended 1943 security exchanges. 1945 Undefined bit MUST be set to zero by servers, and MUST be ignored by 1946 clients. 1948 Extended security exchanges provides a means of supporting arbitrary 1949 authentication protocols within CIFS. Security blobs are opaque to the 1950 CIFS protocol; they are messages in some authentication protocol that 1951 has been agreed upon by client and server by some out of band mechanism, 1952 for which CIFS merely functions as a transport. When 1953 CAP_EXTENDED_SECURITY is negotiated, the server includes a first 1954 security blob in its response; subsequent security blobs are exchanged 1955 in SMB_COM_SESSION_SETUP_ANDX requests and responses until the 1956 authentication protocol terminates. 1958 4.1.1.1 Errors 1960 SUCCESS/SUCCESS 1961 ERRSRV/ERRerror 1963 4.1.2 SESSION_SETUP_ANDX: Session Setup 1965 This SMB is used to further "Set up" the session normally just 1966 established via the negotiate protocol. 1968 One primary function is to perform a "user logon" in the case where the 1969 server is in user level security mode. The Uid in the SMB header is set 1970 by the client to be the userid desired for the AccountName and validated 1971 by the AccountPassword. 1973 4.1.2.1 Pre NT LM 0.12 1975 If the negotiated protocol is prior to NT LM 0.12, the format of 1976 SMB_COM_SESSION_SETUP_ANDX is: 1978 Client Request Description 1979 ============================== ===================================== 1981 UCHAR WordCount; Count of parameter words = 10 1982 UCHAR AndXCommand; Secondary (X) command; 0xFF = none 1983 UCHAR AndXReserved; Reserved (must be 0) 1984 USHORT AndXOffset; Offset to next command WordCount 1985 USHORT MaxBufferSize; Client maximum buffer size 1986 USHORT MaxMpxCount; Actual maximum multiplexed pending 1987 requests 1988 USHORT VcNumber; 0 = first (only), nonzero=additional 1989 VC number 1990 ULONG SessionKey; Session key (valid iff VcNumber != 0) 1991 USHORT PasswordLength; Account password size 1992 ULONG Reserved; Must be 0 1993 USHORT ByteCount; Count of data bytes; min = 0 1994 UCHAR AccountPassword[]; Account Password 1995 STRING AccountName[]; Account Name 1996 STRING PrimaryDomain[]; Client's primary domain 1997 STRING NativeOS[]; Client's native operating system 1998 STRING NativeLanMan[]; Client's native LAN Manager type 2000 and the response is: 2002 Server Response Description 2003 ================================== ================================= 2005 UCHAR WordCount; Count of parameter words = 3 2006 UCHAR AndXCommand; Secondary (X) command; 0xFF = 2007 none 2008 UCHAR AndXReserved; Reserved (must be 0) 2009 USHORT AndXOffset; Offset to next command WordCount 2010 USHORT Action; Request mode: 2011 bit0 = logged in as GUEST 2012 USHORT ByteCount; Count of data bytes 2013 STRING NativeOS[]; Server's native operating system 2014 STRING NativeLanMan[]; Server's native LAN Manager type 2015 STRING PrimaryDomain[]; Server's primary domain 2017 If the server is in "share level security mode", the account name and 2018 password should be ignored by the server. 2020 If challenge/response authentication is not being used, AccountPassword 2021 should be a null terminated ASCII string with PasswordLength set to the 2022 string size including the null; the password will case insensitive. If 2023 challenge/response authentication is being used, then AccountPassword 2024 will be the response to the server's challenge, and PasswordLength 2025 should be set to its length. 2027 The server validates the name and password supplied and if valid, it 2028 registers the user identifier on this session as representing the 2029 specified AccountName. The Uid field in the SMB header will then be 2030 used to validate access on subsequent SMB requests. The SMB requests 2031 where permission checks are required are those which refer to a 2032 symbolically named resource such as SMB_COM_OPEN, SMB_COM_RENAME, 2033 SMB_COM_DELETE, etc.. The value of the Uid is relative to a specific 2034 client/server session so it is possible to have the same Uid value 2035 represent two different users on two different sessions at the server. 2037 Multiple session setup commands may be sent to register additional users 2038 on this session. If the server receives an additional 2039 SMB_COM_SESSION_SETUP_ANDX, only the Uid, AccountName and 2040 AccountPassword fields need contain valid values (the server MUST ignore 2041 the other fields). 2043 The client writes the name of its domain in PrimaryDomain if it knows 2044 what the domain name is. If the domain name is unknown, the client 2045 either encodes it as a NULL string, or as a question mark. 2047 If bit0 of Action is set, this informs the client that although the 2048 server did not recognize the AccountName, it logged the user in as a 2049 guest. This is optional behavior by the server, and in any case one 2050 would ordinarily expect guest privileges to limited. 2052 Another function of the Session Set Up protocol is to inform the server 2053 of the maximum values which will be utilized by this client. Here 2054 MaxBufferSize is the maximum message size which the client can receive. 2055 Thus although the server may support 16k buffers (as returned in the 2056 SMB_COM_NEGOTIATE response), if the client only has 4k buffers, the 2057 value of MaxBufferSize here would be 4096. The minimum allowable value 2058 for MaxBufferSize is 1024. The SMB_COM_NEGOTIATE response includes the 2059 server buffer size supported. Thus this is the maximum SMB message size 2060 which the client can send to the server. This size may be larger than 2061 the size returned to the server from the client via the 2062 SMB_COM_SESSION_SETUP_AND X protocol which is the maximum SMB message 2063 size which the server may send to the client. Thus if the server's 2064 buffer size were 4k and the client's buffer size were only 2K, the 2065 client could send up to 4k (standard) write requests but must only 2066 request up to 2k for (standard) read requests. 2068 The VcNumber field specifies whether the client wants this to be the 2069 first VC or an additional VC. 2071 The values for MaxBufferSize, MaxMpxCount, and VcNumber must be less 2072 than or equal to the maximum values supported by the server as returned 2073 in the SMB_COM_NEGOTIATE response. 2075 If the server gets a SMB_COM_SESSION_SETUP_ANDX request with VcNumber of 2076 0 and other VCs are still connected to that client, they will be aborted 2077 thus freeing any resources held by the server. This condition could 2078 occur if the client was rebooted and reconnected to the server before 2079 the transport level had informed the server of the previous VC 2080 termination. 2082 4.1.2.2 NT LM 0.12 2084 If the negotiated SMB dialect is "NT LM 0.12" and the server supports 2085 ExtendedSecurity i.e. the CAP_EXTENDED_SECURITY flag is set in the 2086 Capabilities field of the Negotiate Response SMB, the Extended Security 2087 SessionSetup SMB format is: 2089 Client Request Description 2090 ============================== ===================================== 2092 UCHAR WordCount; Count of parameter words = 12 2093 UCHAR AndXCommand; Secondary (X) command; 0xFF = none 2094 UCHAR AndXReserved; Reserved (must be 0) 2095 USHORT AndXOffset; Offset to next command WordCount 2096 USHORT MaxBufferSize; Client's maximum buffer size 2097 USHORT MaxMpxCount; Actual maximum multiplexed pending 2098 requests 2099 USHORT VcNumber; 0 = first (only), nonzero=additional 2100 VC number 2101 ULONG SessionKey; Session key (valid iff VcNumber != 0) 2102 USHORT SecurityBlobLength; Length of opaque security blob 2103 ULONG Reserved; must be 0 2104 ULONG Capabilities; Client capabilities 2105 USHORT ByteCount; Count of data bytes; min = 0 2106 UCHAR SecurityBlob[] The opaque security blob 2107 STRING NativeOS[]; Client's native operating system, 2108 Unicode 2109 STRING NativeLanMan[]; Client's native LAN Manager type, 2110 Unicode 2112 The response is: 2114 Server Response Description 2115 ================================== ================================= 2117 UCHAR WordCount; Count of parameter words = 3 2118 UCHAR AndXCommand; Secondary (X) command; 0xFF = 2119 none 2120 UCHAR AndXReserved; Reserved (must be 0) 2121 USHORT AndXOffset; Offset to next command WordCount 2122 USHORT Action; Request mode: 2123 bit0 = logged in as GUEST 2124 USHORT SecurityBlobLength length of Security Blob that 2125 follows in a later field 2126 USHORT ByteCount; Count of data bytes 2127 UCHAR SecurityBlob[] SecurityBlob of length specified 2128 in field SecurityBlobLength 2129 STRING NativeOS[]; Server's native operating system 2130 STRING NativeLanMan[]; Server's native LAN Manager type 2131 STRING PrimaryDomain[]; Server's primary domain 2133 There may be multiple round trips involved in the security blob 2134 exchange. In that case, the server may return an error 2135 STATUS_MORE_PROCESSING_REQUEIRED (a value of 0xC0000016) in the SMB 2136 status. The client can then repeat the SessionSetupAndX SMB with the 2137 next the security blob. 2139 If the negotiated SMB dialect is "NT LM 0.12" or later and the server 2140 does not support Extended Security (i.e. the CAP_EXTENDED_SECURITY flag 2141 in the Capabilities field of the Negotiate Response SMB is not set), the 2142 format of the response SMB is unchanged, but the request is: 2144 Client Request Description 2145 ============================== ===================================== 2147 UCHAR WordCount; Count of parameter words = 13 2148 UCHAR AndXCommand; Secondary (X) command; 0xFF = none 2149 UCHAR AndXReserved; Reserved (must be 0) 2150 USHORT AndXOffset; Offset to next command WordCount 2151 USHORT MaxBufferSize; Client's maximum buffer size 2152 USHORT MaxMpxCount; Actual maximum multiplexed pending 2153 requests 2154 USHORT VcNumber; 0 = first (only), nonzero=additional 2155 VC number 2156 ULONG SessionKey; Session key (valid iff VcNumber != 0) 2157 USHORT Account password size, ANSI 2158 CaseInsensitivePasswordLength; 2159 USHORT Account password size, Unicode 2160 CaseSensitivePasswordLength; 2161 ULONG Reserved; must be 0 2162 ULONG Capabilities; Client capabilities 2163 USHORT ByteCount; Count of data bytes; min = 0 2164 UCHAR Account Password, ANSI 2165 CaseInsensitivePassword[]; 2166 UCHAR CaseSensitivePassword[]; Account Password, Unicode 2167 STRING AccountName[]; Account Name, Unicode 2168 STRING PrimaryDomain[]; Client's primary domain, Unicode 2169 STRING NativeOS[]; Client's native operating system, 2170 Unicode 2171 STRING NativeLanMan[]; Client's native LAN Manager type, 2172 Unicode 2173 The client expresses its capabilities to the server encoded in the 2174 Capabilities field: 2176 Capability Name Encoding Description 2177 ======================== ========= ================================ 2179 CAP_UNICODE 0x0004 The client can use UNICODE 2180 strings 2181 CAP_LARGE_FILES 0x0008 The client can deal with files 2182 having 64 bit offsets 2183 CAP_NT_SMBS 0x0010 The client understands the SMBs 2184 introduced with the NT LM 0.12 2185 dialect. Implies CAP_NT_FIND. 2186 CAP_NT_FIND 0x0200 2187 CAP_ STATUS32 0x0040 The client can receive 32 bit 2188 errors encoded in Status.Status 2189 CAP_LEVEL_II_OPLOCKS 0x0080 The client understands Level II 2190 oplocks 2192 The entire message sent and received including the optional ANDX SMB 2193 must fit in the negotiated maximum transfer size. The following are the 2194 only valid SMB commands for AndXCommand for SMB_COM_SESSION_SETUP_ANDX 2196 SMB_COM_TREE_CONNECT_ANDX SMB_COM_OPEN 2197 SMB_COM_OPEN_ANDX SMB_COM_CREATE 2198 SMB_COM_CREATE_NEW SMB_COM_CREATE_DIRECTORY 2199 SMB_COM_DELETE SMB_COM_DELETE_DIRECTORY 2200 SMB_COM_FIND SMB_COM_FIND_UNIQUE 2201 SMB_COM_COPY SMB_COM_RENAME 2202 SMB_COM_NT_RENAME SMB_COM_CHECK_DIRECTORY 2203 SMB_COM_QUERY_INFORMATION SMB_COM_SET_INFORMATION 2204 SMB_COM_NO_ANDX_COMMAND SMB_COM_OPEN_PRINT_FILE 2205 SMB_COM_GET_PRINT_QUEUE SMB_COM_TRANSACTION 2207 4.1.2.3 Errors 2209 ERRSRV/ERRerror - no NEG_PROT issued 2210 ERRSRV/ERRbadpw - password not correct for given username 2211 ERRSRV/ERRtoomanyuids - maximum number of users per session exceeded 2212 ERRSRV/ERRnosupport - chaining of this request to the previous one is 2213 not supported 2214 4.1.3 LOGOFF_ANDX: User Logoff 2216 This SMB is the inverse of SMB_COM_SESSION_SETUP_ANDX. 2218 Client Request Description 2219 ================================== ================================= 2221 UCHAR WordCount; Count of parameter words = 2 2222 UCHAR AndXCommand; Secondary (X) command; 0xFF = 2223 none 2224 UCHAR AndXReserved; Reserved (must be 0) 2225 USHORT AndXOffset; Offset to next command WordCount 2226 USHORT ByteCount; Count of data bytes = 0 2228 Server Response Description 2229 ================================== ================================= 2231 UCHAR WordCount; Count of parameter words = 2 2232 UCHAR AndXCommand; Secondary (X) command; 0xFF = 2233 none 2234 UCHAR AndXReserved; Reserved (must be 0) 2235 USHORT AndXOffset; Offset to next command WordCount 2236 USHORT ByteCount; Count of data bytes = 0 2238 The user represented by Uid in the SMB header is logged off. The server 2239 closes all files currently open by this user, and invalidates any 2240 outstanding requests with this Uid. 2242 SMB_COM_SESSION_SETUP_ANDX is the only valid AndXCommand. for this SMB. 2244 4.1.3.1 Errors 2246 ERRSRV/invnid - TID was invalid 2247 ERRSRV/baduid - UID was invalid 2248 4.1.4 TREE_CONNECT_ANDX: Tree Connect 2250 Client Request Description 2251 ================================= ================================= 2253 UCHAR WordCount; Count of parameter words = 4 2254 UCHAR AndXCommand; Secondary (X) command; 0xFF = none 2255 UCHAR AndXReserved; Reserved (must be 0) 2256 USHORT AndXOffset; Offset to next command WordCount 2257 USHORT Flags; Additional information 2258 bit 0 set = disconnect Tid 2259 USHORT PasswordLength; Length of Password[] 2260 USHORT ByteCount; Count of data bytes; min = 3 2261 UCHAR Password[]; Password 2262 STRING Path[]; Server name and share name 2263 STRING Service[]; Service name 2265 The serving machine verifies the combination and returns an error code 2266 or an identifier. The full name is included in this request message and 2267 the identifier identifying the connection is returned in the Tid field 2268 of the SMB header. The Tid field in the client request is ignored. The 2269 meaning of this identifier (Tid) is server specific; the client must not 2270 associate any specific meaning to it. 2272 If the negotiated dialect is LANMAN1.0 or later, then it is a protocol 2273 violation for the client to send this message prior to a successful 2274 SMB_COM_SESSION_SETUP_ANDX, and the server ignores Password. 2276 If the negotiated dialect is prior to LANMAN1.0 and the client has not 2277 sent a successful SMB_COM_SESSION_SETUP_ANDX request when the tree 2278 connect arrives, a user level security mode server must nevertheless 2279 validate the client's credentials as discussed earlier in this document. 2281 Path follows UNC style syntax, that is to say it is encoded as 2282 \\server\share and it indicates the name of the resource to which the 2283 client wishes to connect. 2285 Because Password may be an authentication response, it is a variable 2286 length field with the length specified by PasswordLength. If 2287 authentication is not being used, Password should be a null terminated 2288 ASCII string with PasswordLength set to the string size including the 2289 terminating null. 2291 The server can enforce whatever policy it desires to govern share 2292 access. Typically, if the server is paused, administrative privilege is 2293 required to connect to any share; if the server is not paused, 2294 administrative privilege is required only for administrative shares (C$, 2295 etc.). Other such policies may include valid times of day, software 2296 usage license limits, number of simultaneous server users or share 2297 users, etc. 2299 The Service component indicates the type of resource the client intends 2300 to access. Valid values are: 2302 Service Description Earliest Dialect Allowed 2303 ======== ======================== ================================ 2305 A: disk share PC NETWORK PROGRAM 1.0 2306 LPT1: printer PC NETWORK PROGRAM 1.0 2307 IPC named pipe MICROSOFT NETWORKS 3.0 2308 COMM communications device MICROSOFT NETWORKS 3.0 2309 ????? any type of device MICROSOFT NETWORKS 3.0 2311 If bit0 of Flags is set, the tree connection to Tid in the SMB header 2312 should be disconnected. If this tree disconnect fails, the error should 2313 be ignored. 2315 If the negotiated dialect is earlier than DOS LANMAN2.1, the response to 2316 this SMB is: 2318 Server Response Description 2319 ================================ =================================== 2321 UCHAR WordCount; Count of parameter words = 2 2322 UCHAR AndXCommand; Secondary (X) command; 0xFF = none 2323 UCHAR AndXReserved; Reserved (must be 0) 2324 USHORT AndXOffset; Offset to next command WordCount 2325 USHORT ByteCount; Count of data bytes; min = 3 2327 If the negotiated is DOS LANMAN2.1 or later, the response to this SMB 2328 is: 2330 Server Response Description 2331 ================================ =================================== 2333 UCHAR WordCount; Count of parameter words = 3 2334 UCHAR AndXCommand; Secondary (X) command; 0xFF = none 2335 UCHAR AndXReserved; Reserved (must be 0) 2336 USHORT AndXOffset; Offset to next command WordCount 2337 USHORT OptionalSupport; Optional support bits 2338 USHORT ByteCount; Count of data bytes; min = 3 2339 UCHAR Service[]; Service type connected to. Always 2340 ANSII. 2341 STRING NativeFileSystem[]; Native file system for this tree 2342 NativeFileSystem is the name of the filesystem; values to be expected 2343 include FAT, NTFS, etc. 2345 OptionalSupport bits has the encoding: 2347 Name Encoding Description 2348 ============================= ========= ========================== 2350 SMB_SUPPORT_SEARCH_BITS 0x0001 2352 SMB_SHARE_IS_IN_DFS 0x0002 2354 Some servers negotiate "DOS LANMAN2.1" dialect or later and still send 2355 the "downlevel" (i.e. wordcount==2) response. Valid AndX following 2356 commands are 2358 SMB_COM_OPEN SMB_COM_OPEN_ANDX SMB_COM_CREATE 2359 SMB_COM_CREATE_NEW SMB_COM_CREATE_DIRECTORY SMB_COM_DELETE 2360 SMB_COM_DELETE_DIRECTORY SMB_COM_FIND SMB_COM_COPY 2361 SMB_COM_FIND_UNIQUE SMB_COM_RENAME 2362 SMB_COM_CHECK_DIRECTORY SMB_COM_QUERY_INFORMATION 2363 SMB_COM_GET_PRINT_QUEUE SMB_COM_OPEN_PRINT_FILE 2364 SMB_COM_TRANSACTION SMB_COM_NO_ANDX_CMD 2365 SMB_COM_SET_INFORMATION SMB_COM_NT_RENAME 2367 4.1.4.1 Errors 2369 ERRDOS/ERRnomem 2370 ERRDOS/ERRbadpath 2371 ERRDOS/ERRinvdevice 2372 ERRSRV/ERRaccess 2373 ERRSRV/ERRbadpw 2374 ERRSRV/ERRinvnetname 2376 4.1.5 TREE_DISCONNECT: Tree Disconnect 2378 This message informs the server that the client no longer wishes to 2379 access the resource connected to with a prior SMB_COM_TREE_CONNECT or 2380 SMB_COM_TREE_CONNECT_ANDX. 2382 Client Request Description 2383 ================================== ================================= 2385 UCHAR WordCount; Count of parameter words = 0 2386 USHORT ByteCount; Count of data bytes = 0 2387 The resource sharing connection identified by Tid in the SMB header is 2388 logically disconnected from the server. Tid is invalidated; it will not 2389 be recognized if used by the client for subsequent requests. All locks, 2390 open files, etc. created on behalf of Tid are released. 2392 Server Response Description 2393 ================================== ================================= 2395 UCHAR WordCount; Count of parameter words = 0 2396 USHORT ByteCount; Count of data bytes = 0 2398 4.1.5.1 Errors 2400 ERRSRV/ERRinvnid 2401 ERRSRV/ERRbaduid 2403 4.1.6 TRANS2_QUERY_FS_INFORMATION: Get File System Information 2405 This transaction requests information about a filesystem on the server. 2407 Client Request Value 2408 ================================== ================================= 2410 WordCount; 15 2411 TotalParameterCount; 2 or 4 2412 MaxSetupCount; 0 2413 SetupCount; 1 or 2 2414 Setup[0]; TRANS2_QUERY_FS_INFORMATION 2416 Parameter Block Encoding Description 2417 ================================== ================================= 2419 USHORT Information Level; Level of information requested 2421 The filesystem is identified by Tid in the SMB header. 2423 MaxDataCount in the transaction request must be large enough to 2424 accommodate the response. 2426 The encoding of the response parameter block depends on the 2427 InformationLevel requested. Information levels whose values are greater 2428 than 0x102 are mapped to corresponding calls to 2429 NtQueryVolumeInformationFile calls by the server. The two levels below 2430 0x102 are described below. The requested information is placed in the 2431 Data portion of the transaction response. 2433 InformationLevel Value 2435 ============================= ====== 2437 SMB_INFO_ALLOCATION 1 2438 SMB_INFO_VOLUME 2 2439 SMB_QUERY_FS_VOLUME_INFO 0x102 2440 SMB_QUERY_FS_SIZE_INFO 0x103 2441 SMB_QUERY_FS_DEVICE_INFO 0x104 2442 SMB_QUERY_FS_ATTRIBUTE_INFO 0x105 2444 The following sections describe the InformationLevel dependent encoding 2445 of the data part of the transaction response. 2447 4.1.6.1 SMB_INFO_ALLOCATION 2449 Data Block Encoding Description 2450 =================== ================================================ 2452 ULONG idFileSystem; File system identifier. NT server always 2453 returns 0 2454 ULONG cSectorUnit; Number of sectors per allocation unit 2455 ULONG cUnit; Total number of allocation units 2456 ULONG cUnitAvail; Total number of available allocation units 2457 USHORT cbSector; Number of bytes per sector 2459 4.1.6.2 SMB_INFO_VOLUME 2461 Data Block Encoding Description 2462 =================== ================================================ 2464 ULONG ulVsn; Volume serial number 2465 UCHAR cch; Number of characters in Label 2466 STRING Label; The volume label 2468 4.1.6.3 SMB_QUERY_FS_VOLUME_INFO 2470 Data Block Encoding Description 2471 =================== ================================================ 2473 LARGE_INTEGER Volume Creation Time 2474 ULONG Volume Serial Number 2475 ULONG Length of Volume Label in bytes 2477 BYTE Reserved 2479 BYTE Reserved 2481 STRING Label; The volume label 2482 4.1.6.4 SMB_QUERY_FS_SIZE_INFO 2484 Data Block Encoding Description 2485 =================== ================================================ 2487 LARGE_INTEGER Total Number of Allocation units on the Volume 2488 LARGE_INTEGER Number of free Allocation units on the Volume 2489 ULONG Number of sectors in each Allocation unit 2491 ULONG Number of bytes in each sector 2493 4.1.6.5 SMB_QUERY_FS_DEVICE_INFO 2495 Data Block Encoding Value 2496 ==================== =============================================== 2498 ULONG DeviceType; Values as specified below 2499 ULONG Characteristics of the device; Values as 2500 specified below 2502 For DeviceType, note that the values 0-32767 are reserved for the 2503 exclusive use of Microsoft Corporation. The following device types are 2504 currently defined: 2506 FILE_DEVICE_BEEP 0x00000001 2508 FILE_DEVICE_CD_ROM 0x00000002 2509 FILE_DEVICE_CD_ROM_FILE_SYSTEM 0x00000003 2510 FILE_DEVICE_CONTROLLER 0x00000004 2511 FILE_DEVICE_DATALINK 0x00000005 2512 FILE_DEVICE_DFS 0x00000006 2513 FILE_DEVICE_DISK 0x00000007 2514 FILE_DEVICE_DISK_FILE_SYSTEM 0x00000008 2515 FILE_DEVICE_FILE_SYSTEM 0x00000009 2516 FILE_DEVICE_INPORT_PORT 0x0000000a 2517 FILE_DEVICE_KEYBOARD 0x0000000b 2518 FILE_DEVICE_MAILSLOT 0x0000000c 2519 FILE_DEVICE_MIDI_IN 0x0000000d 2520 FILE_DEVICE_MIDI_OUT 0x0000000e 2521 FILE_DEVICE_MOUSE 0x0000000f 2522 FILE_DEVICE_MULTI_UNC_PROVIDER 0x00000010 2523 FILE_DEVICE_NAMED_PIPE 0x00000011 2524 FILE_DEVICE_NETWORK 0x00000012 2525 FILE_DEVICE_NETWORK_BROWSER 0x00000013 2526 FILE_DEVICE_NETWORK_FILE_SYSTEM 0x00000014 2527 FILE_DEVICE_NULL 0x00000015 2528 FILE_DEVICE_PARALLEL_PORT 0x00000016 2529 FILE_DEVICE_PHYSICAL_NETCARD 0x00000017 2530 FILE_DEVICE_PRINTER 0x00000018 2531 FILE_DEVICE_SCANNER 0x00000019 2532 FILE_DEVICE_SERIAL_MOUSE_PORT 0x0000001a 2533 FILE_DEVICE_SERIAL_PORT 0x0000001b 2534 FILE_DEVICE_SCREEN 0x0000001c 2535 FILE_DEVICE_SOUND 0x0000001d 2536 FILE_DEVICE_STREAMS 0x0000001e 2537 FILE_DEVICE_TAPE 0x0000001f 2538 FILE_DEVICE_TAPE_FILE_SYSTEM 0x00000020 2539 FILE_DEVICE_TRANSPORT 0x00000021 2540 FILE_DEVICE_UNKNOWN 0x00000022 2541 FILE_DEVICE_VIDEO 0x00000023 2542 FILE_DEVICE_VIRTUAL_DISK 0x00000024 2543 FILE_DEVICE_WAVE_IN 0x00000025 2544 FILE_DEVICE_WAVE_OUT 0x00000026 2545 FILE_DEVICE_8042_PORT 0x00000027 2546 FILE_DEVICE_NETWORK_REDIRECTOR 0x00000028 2547 FILE_DEVICE_BATTERY 0x00000029 2548 FILE_DEVICE_BUS_EXTENDER 0x0000002a 2549 FILE_DEVICE_MODEM 0x0000002b 2550 FILE_DEVICE_VDM 0x0000002c 2551 Some of these device types are not currently accessible over the network 2552 and may never be accessible over the network. Some may change to be 2553 accessible over the network. The values for device types that may never 2554 be accessible over the network may be redefined to be just reserved at 2555 some date in the future. 2557 Characteristics is the sum of any of the following: 2559 FILE_REMOVABLE_MEDIA 0x00000001 2560 FILE_READ_ONLY_DEVICE 0x00000002 2561 FILE_FLOPPY_DISKETTE 0x00000004 2562 FILE_WRITE_ONE_MEDIA 0x00000008 2563 FILE_REMOTE_DEVICE 0x00000010 2564 FILE_DEVICE_IS_MOUNTED 0x00000020 2565 FILE_VIRTUAL_VOLUME 0x00000040 2567 4.1.6.6 SMB_QUERY_FS_ATTRIBUTE_INFO 2569 Data Block Encoding Description 2570 =================== ================================================ 2572 ULONG File System Attributes; possible values 2573 described below 2574 LONG Maximum length of each file name component in 2575 number of bytes 2576 ULONG Length, in bytes, of the name of the file system 2578 STRING Name of the file system 2580 Where FileSystemAttributes is the sum of any of the following: 2582 FILE_CASE_SENSITIVE_SEARCH 0x00000001 2583 FILE_CASE_PRESERVED_NAMES 0x00000002 2584 FILE_PRSISTENT_ACLS 0x00000004 2585 FILE_FILE_COMPRESSION 0x00000008 2586 FILE_VOLUME_QUOTAS 0x00000010 2587 FILE_DEVICE_IS_MOUNTED 0x00000020 2588 FILE_VOLUME_IS_COMPRESSED 0x00008000 2590 4.1.6.7 Errors 2592 ERRSRV/invnid - TID was invalid 2593 ERRSRV/baduid - UID was invalid 2594 ERRHRD/ERRnotready - the file system has been removed 2595 ERRHRD/ERRdata - disk I/O error 2596 ERRSRV/ERRaccess - user does not have the right to perform this 2597 operation 2598 ERRSRV/ERRinvdevice - resource identified by TID is not a file system 2600 4.1.7 ECHO: Ping the Server 2602 This request is used to test the connection to the server, and to see if 2603 the server is still responding. 2605 Client Request Description 2606 ================================== ================================= 2608 UCHAR WordCount; Count of parameter words = 1 2609 USHORT EchoCount; Number of times to echo data back 2610 USHORT ByteCount; Count of data bytes; min = 1 2611 UCHAR Buffer[1]; Data to echo 2613 Server Response Description 2614 ================================== ================================= 2616 UCHAR WordCount; Count of parameter words = 1 2617 USHORT SequenceNumber; Sequence number of this echo 2618 USHORT ByteCount; Count of data bytes; min = 4 2619 UCHAR Buffer[1]; Echoed data 2621 Each response echoes the data sent, though ByteCount may indicate no 2622 data If EchoCount is zero, no response is sent. 2624 Tid in the SMB header is ignored, so this request may be sent to the 2625 server even if there are no valid tree connections to the server. 2627 The flow for the ECHO protocol is: 2629 Client Request <-> Server Response 2630 ================================= ==== ============================ 2632 Echo Request (EchoCount == n) -> 2633 <- Echo Response 1 2634 <- Echo Response 2 2635 <- Echo Response n 2636 4.1.7.1 Errors 2638 ERRSRV/ERRbaduid - UID was invalid 2639 ERRSRV/ERRnoaccess - session has not been established 2640 ERRSRV/ERRnosupport - ECHO function is not supported 2642 4.1.8 NT_CANCEL: Cancel request 2644 This SMB allows a client to cancel a request currently pending at the 2645 server. 2647 Client Request Description 2648 ================================== ================================= 2650 UCHAR WordCount; No words are sent (== 0) 2651 USHORT ByteCount; No bytes (==0) 2653 The Sid, Uid, Pid, Tid, and Mid fields of the SMB are used to locate an 2654 pending server request from this session. If a pending request is 2655 found, it is "hurried along" which may result in success or failure of 2656 the original request. No other response is generated for this SMB. 2658 4.2 File Requests 2660 4.2.1 NT_CREATE_ANDX: Create or Open File 2662 This command is used to create or open a file or a directory. 2664 Client Request Description 2665 ================================= ================================== 2667 UCHAR WordCount; Count of parameter words = 24 2668 UCHAR AndXCommand; Secondary command; 0xFF = None 2669 UCHAR AndXReserved; Reserved (must be 0) 2670 USHORT AndXOffset; Offset to next command WordCount 2671 UCHAR Reserved; Reserved (must be 0) 2672 USHORT NameLength; Length of Name[] in bytes 2673 ULONG Flags; Create bit set: 2674 0x02 - Request an oplock 2675 0x04 - Request a batch oplock 2676 0x08 - Target of open must be 2677 directory 2678 ULONG RootDirectoryFid; If non-zero, open is relative to 2679 this directory 2680 ACCESS_MASK DesiredAccess; access desired 2681 LARGE_INTEGER AllocationSize; Initial allocation size 2682 ULONG ExtFileAttributes; File attributes 2683 ULONG ShareAccess; Type of share access 2684 ULONG CreateDisposition; Action to take if file exists or 2685 not 2686 ULONG CreateOptions; Options to use if creating a file 2687 ULONG ImpersonationLevel; Security QOS information 2688 UCHAR SecurityFlags; Security tracking mode flags: 2689 0x1 - SECURITY_CONTEXT_TRACKING 2690 0x2 - SECURITY_EFFECTIVE_ONLY 2691 USHORT ByteCount; Length of byte parameters 2692 STRING Name[]; File to open or create 2694 The DesiredAccess parameter is specified in section 3.8 on Access Mask 2695 Encoding. 2697 If no value is specified, it still allows an application to query 2698 attributes without actually accessing the file. 2700 The ExtFIleAttributes parameter specifies the file attributes and flags 2701 for the file. The parameter's value is the sum of allowed attributes and 2702 flags defined in section 3.12 on Extended File Attribute Encoding 2704 The ShareAccess field Specifies how this file can be shared. This 2705 parameter must be some combination of the following values: 2707 Name Value Meaning 2708 0 Prevents the file from being shared. 2709 FILE_SHARE_READ 0x00000001 Other open operations can be performed on 2710 the file for read access. 2711 FILE_SHARE_WRITE 0x00000002 Other open operations can be performed on 2712 the file for write access. 2713 FILE_SHARE_DELETE 0x00000004 Other open operations can be performed on 2714 the file for delete access. 2716 The CreateDisposition parameter can contain one of the following values: 2718 CREATE_NEW Creates a new file. The function fails if the 2719 specified file already exists. 2720 CREATE_ALWAYS Creates a new file. The function overwrites the file 2721 if it exists. 2722 OPEN_EXISTING Opens the file. The function fails if the file does 2723 not exist. 2724 OPEN_ALWAYS Opens the file, if it exists. If the file does not 2725 exist, act like CREATE_NEW. 2726 TRUNCATE_EXISTING Opens the file. Once opened, the file is truncated so 2727 that its size is zero bytes. The calling process must 2728 open the file with at least GENERIC_WRITE access. The 2729 function fails if the file does not exist. 2731 The ImpersonationLevel parameter can contain one or more of the 2732 following values: 2734 SECURITY_ANONYMOUS Specifies to impersonate the client at the 2735 Anonymous impersonation level. 2736 SECURITY_IDENTIFICATION Specifies to impersonate the client at the 2737 Identification impersonation level. 2738 SECURITY_IMPERSONATION Specifies to impersonate the client at the 2739 Impersonation impersonation level. 2740 SECURITY_DELEGATION Specifies to impersonate the client at the 2741 Delegation impersonation level. 2743 The SecurityFlags parameter can have either of the following two flags 2744 set: 2746 SECURITY_CONTEXT_TRACKING Specifies that the security tracking mode is 2747 dynamic. If this flag is not specified, 2748 Security Tracking Mode is static. 2749 SECURITY_EFFECTIVE_ONLY Specifies that only the enabled aspects of 2750 the client's security context are available 2751 to the server. If you do not specify this 2752 flag, all aspects of the client's security 2753 context are available. This flag allows the 2754 client to limit the groups and privileges 2755 that a server can use while impersonating the 2756 client. 2758 The response is as follows: 2760 Server Response Description 2761 ================================= ================================== 2763 UCHAR WordCount; Count of parameter words = 26 2764 UCHAR AndXCommand; 0xFF = None 2765 UCHAR AndXReserved; MBZ 2766 USHORT AndXOffset; Offset to next command WordCount 2767 UCHAR OplockLevel; The oplock level granted 2768 0 - No oplock granted 2769 1 - Exclusive oplock granted 2770 2 - Batch oplock granted 2771 3 - Level II oplock granted 2772 USHORT Fid; The file ID 2773 ULONG CreateAction; The action taken 2774 TIME CreationTime; The time the file was created 2775 TIME LastAccessTime; The time the file was accessed 2776 TIME LastWriteTime; The time the file was last written 2777 TIME ChangeTime; The time the file was last changed 2778 ULONG ExtFileAttributes; The file attributes 2779 LARGE_INTEGER AllocationSize; The number of byes allocated 2780 LARGE_INTEGER EndOfFile; The end of file offset 2781 USHORT FileType; 2782 USHORT DeviceState; state of IPC device (e.g. pipe) 2783 BOOLEAN Directory; TRUE if this is a directory 2784 USHORT ByteCount; = 0 2786 The following SMBs may follow SMB_COM_NT_CREATE_ANDX: 2788 SMB_COM_READ SMB_COM_READ_ANDX 2789 SMB_COM_IOCTL 2790 4.2.2 NT_TRANSACT_CREATE: Create or Open File with EAs or SD 2792 This command is used to create or open a file or a directory, when EAs 2793 or an SD must be applied to the file. 2795 Request Parameter Block Encoding Description 2796 =================================== ================================ 2798 ULONG Flags; Creation flags (see below) 2799 ULONG RootDirectoryFid; Optional directory for relative 2800 open 2801 ACCESS_MASK DesiredAccess; Desired access 2802 LARGE_INTEGER AllocationSize; The initial allocation size in 2803 bytes, if file created 2804 ULONG ExtFileAttributes; The extended file attributes 2805 ULONG ShareAccess; The share access 2806 ULONG CreateDisposition; Action to take if file exists or 2807 not 2808 ULONG CreateOptions; Options for creating a new file 2809 ULONG SecurityDescriptorLength; Length of SD in bytes 2810 ULONG EaLength; Length of EA in bytes 2811 ULONG NameLength; Length of name in characters 2812 ULONG ImpersonationLevel; Security QOS information 2813 UCHAR SecurityFlags; Security QOS information 2814 STRING Name[NameLength]; The name of the file (not NULL 2815 terminated) 2817 Data Block Encoding Description 2818 =================================== ================================ 2820 UCHAR SecurityDescriptor[ 2821 SecurityDescriptorLength]; 2822 UCHAR ExtendedAttributes[EaLength]; 2824 Creation Flag Name Value Description 2825 ========================== ====== ================================== 2827 NT_CREATE_REQUEST_OPLOCK 0x02 Level I oplock requested 2828 NT_CREATE_REQUEST_OPBATCH 0x04 Batch oplock requested 2829 NT_CREATE_OPEN_TARGET_DIR 0x08 Target for open is a directory 2830 Output Parameter Block Encoding Description 2831 ================================== ================================== 2833 UCHAR OplockLevel; The oplock level granted 2834 UCHAR Reserved; 2835 USHORT Fid; The file ID 2836 ULONG CreateAction; The action taken 2837 ULONG EaErrorOffset; Offset of the EA error 2838 TIME CreationTime; The time the file was created 2839 TIME LastAccessTime; The time the file was accessed 2840 TIME LastWriteTime; The time the file was last written 2841 TIME ChangeTime; The time the file was last changed 2842 ULONG ExtFileAttributes; The file attributes 2843 LARGE_INTEGER AllocationSize; The number of byes allocated 2844 LARGE_INTEGER EndOfFile; The end of file offset 2845 USHORT FileType; 2846 USHORT DeviceState; state of IPC device (e.g. pipe) 2847 BOOLEAN Directory; TRUE if this is a directory 2849 See the description of NT_CREATE_ANDX for the definition of the 2850 parameters. 2852 4.2.3 CREATE_TEMPORARY: Create Temporary File 2854 The server creates a data file in Directory relative to Tid in the SMB 2855 header and assigns a unique name to it. 2857 Client Request Server Response 2858 ================================== ================================= 2860 UCHAR WordCount; Count of parameter words = 3 2861 USHORT reserved; Ignored by the server 2862 UTIME CreationTime; New file's creation time stamp 2863 USHORT ByteCount; Count of data bytes; min = 2 2864 UCHAR BufferFormat; 0x04 2865 STRING DirectoryName[]; Directory name 2867 Server Response Description 2868 ================================== ================================= 2870 UCHAR WordCount; Count of parameter words = 1 2871 USHORT Fid; File handle 2872 USHORT ByteCount; Count of data bytes; min = 2 2873 UCHAR BufferFormat; 0x04 2874 STRING Filename[]; File name 2875 Fid is the returned handle for future file access. Filename is the name 2876 of the file which was created within the requested Directory. It is 2877 opened in compatibility mode with read/write access for the client. 2879 Support of CreationTime by the server is optional. 2881 4.2.4 READ_ANDX: Read Bytes 2883 Large File Client Request Description 2884 ========================== =================================== 2885 ====== 2887 UCHAR WordCount; Count of parameter words = 10 or 12 2888 UCHAR AndXCommand; Secondary (X) command; 0xFF = none 2889 UCHAR AndXReserved; Reserved (must be 0) 2890 USHORT AndXOffset; Offset to next command WordCount 2891 USHORT Fid; File handle 2892 ULONG Offset; Offset in file to begin read 2893 USHORT MaxCount; Max number of bytes to return 2894 USHORT MinCount; Reserved for obsolescent requests 2895 ULONG MaxCountHigh; High 16 bits of MaxCount if 2896 CAP_LARGE_READX; else MBZ 2897 USHORT Remaining; Reserved for obsolescent requests 2898 ULONG OffsetHigh; Upper 32 bits of offset (only if 2899 WordCount is 12) 2900 USHORT ByteCount; Count of data bytes = 0 2901 Server Response Description 2902 ========================== =================================== 2903 ====== 2905 UCHAR WordCount; Count of parameter words = 12 2906 UCHAR AndXCommand; Secondary (X) command; 0xFF = none 2907 UCHAR AndXReserved; Reserved (must be 0) 2908 USHORT AndXOffset; Offset to next command WordCount 2909 USHORT Remaining; Reserved -- must be -1 2910 USHORT DataCompactionMode; 2911 USHORT Reserved; Reserved (must be 0) 2912 USHORT DataLength; Number of data bytes (min = 0) 2913 USHORT DataOffset; Offset (from header start) to data 2914 USHORT DataLengthHigh; High 16 bits of number of data bytes if 2915 CAP_LARGE_READX; else MBZ 2916 USHORT Reserved[4]; Reserved (must be 0) 2917 USHORT ByteCount; Count of data bytes; ignored if 2918 CAP_LARGE_READX 2919 UCHAR Pad[]; 2920 UCHAR Data[ DataLength]; Data from resource 2922 If the file specified by Fid has any portion of the range specified by 2923 Offset and MaxCount locked for exclusive use by a client with a 2924 different connection or Pid, the request will fail with ERRlock. 2926 If the negotiated dialect is NT LM 0.12 or later, the client may use 2927 the 12 parameter word version of the request. This version allows 2928 specification of 64 bit file offsets. 2930 If CAP_LARGE_READX was indicated by the server in the negotiate protocol 2931 response, the request's MaxCount field may exceed the negotiated buffer 2932 size if Fid refers to a disk file. The server may arbitrarily elect to 2933 return fewer than MaxCount bytes in response. 2935 The following SMBs may follow SMB_COM_READ_ANDX: 2936 SMB_COM_CLOSE 2938 4.2.4.1 Errors 2940 ERRDOS/ERRnoaccess 2941 ERRDOS/ERRbadfid 2942 ERRDOS/ERRlock 2943 ERRDOS/ERRbadaccess 2944 ERRSRV/ERRinvid 2945 ERRSRV/ERRbaduid 2946 4.2.5 WRITE_ANDX: Write Bytes to file or resource 2948 Client Request Description 2949 ========================= ==================================== 2950 ====== 2952 UCHAR WordCount; Count of parameter words = 12 or 14 2953 UCHAR AndXCommand; Secondary (X) command; 0xFF = none 2954 UCHAR AndXReserved; Reserved (must be 0) 2955 USHORT AndXOffset; Offset to next command WordCount 2956 USHORT Fid; File handle 2957 ULONG Offset; Offset in file to begin write 2958 ULONG Reserved; Must be 0 2959 USHORT WriteMode; Write mode bits: 2960 0 - write through 2961 USHORT Remaining; Bytes remaining to satisfy request 2962 USHORT DataLengthHigh; High 16 bits of data length if 2963 CAP_LARGE_WRITEX; else MBZ 2964 USHORT DataLength; Number of data bytes in buffer (>=0) 2965 USHORT DataOffset; Offset to data bytes 2966 ULONG OffsetHigh; Upper 32 bits of offset (only present if 2967 WordCount = 14) 2968 USHORT ByteCount; Count of data bytes; ignored if 2969 CAP_LARGE_WRITEX 2970 UCHAR Pad[]; Pad to SHORT or LONG 2971 UCHAR Data[DataLength]; Data to write 2973 Server Response Description 2974 ========================= ==================================== 2975 ====== 2977 UCHAR WordCount; Count of parameter words = 6 2978 UCHAR AndXCommand; Secondary (X) command; 0xFF = none 2979 UCHAR AndXReserved; Reserved (must be 0) 2980 USHORT AndXOffset; Offset to next command WordCount 2981 USHORT Count; Number of bytes written 2982 USHORT Remaining; Reserved 2983 ULONG Reserved; 2984 USHORT ByteCount; Count of data bytes = 0 2986 If the file specified by Fid has any portion of the range specified by 2987 Offset and MaxCount locked for shared or exclusive use by a client with 2988 a different connection or Pid, the request will fail with ERRlock. 2990 A ByteCount of 0 does not truncate the file. Rather a zero length write 2991 merely transfers zero bytes of information to the file. A request such 2992 as SMB_COM_WRITE must be used to truncate the file. 2994 If WriteMode has bit0 set in the request and Fid refers to a disk file, 2995 the response is not sent from the server until the data is on stable 2996 storage. 2998 If the negotiated dialect is NT LM 0.12 or later, the 14 word format of 2999 this SMB may be used to access portions of files requiring offsets 3000 expressed as 64 bits. Otherwise, the OffsetHigh field must be omitted 3001 from the request. 3003 If CAP_LARGE_WRITEX was indicated by the server in the negotiate 3004 protocol response, the request's DataLength field may exceed the 3005 negotiated buffer size if Fid refers to a disk file. 3007 The following are the valid AndXCommand values for this SMB: 3009 SMB_COM_READ SMB_COM_READ_ANDX 3010 SMB_COM_LOCK_AND_READ SMB_COM_WRITE_ANDX 3011 SMB_COM_CLOSE 3013 4.2.5.1 Errors 3015 ERRDOS/ERRnoaccess 3016 ERRDOS/ERRbadfid 3017 ERRDOS/ERRlock 3018 ERRDOS/ERRbadaccess 3019 ERRSRV/ERRinvid 3020 ERRSRV/ERRbaduid 3022 4.2.6 LOCKING_ANDX: Lock or Unlock Byte Ranges 3024 SMB_COM_LOCKING_ANDX allows both locking and/or unlocking of file range(s). 3026 Client Request Description 3027 ================================== ================================= 3029 UCHAR WordCount; Count of parameter words = 8 3030 UCHAR AndXCommand; Secondary (X) command; 0xFF = 3031 none 3032 UCHAR AndXReserved; Reserved (must be 0) 3033 USHORT AndXOffset; Offset to next command WordCount 3034 USHORT Fid; File handle 3035 UCHAR LockType; See LockType table below 3036 UCHAR OplockLevel; The new oplock level 3037 ULONG Timeout; Milliseconds to wait for unlock 3038 USHORT NumberOfUnlocks; Num. unlock range structs 3039 following 3040 USHORT NumberOfLocks; Num. lock range structs following 3041 USHORT ByteCount; Count of data bytes 3042 LOCKING_ANDX_RANGE Unlocks[]; Unlock ranges 3043 LOCKING_ANDX_RANGE Locks[]; Lock ranges 3045 LockType Flag Name Value Description 3046 ============================ ===== ================================ 3048 LOCKING_ANDX_SHARED_LOCK 0x01 Read-only lock 3049 LOCKING_ANDX_OPLOCK_RELEASE 0x02 Oplock break notification 3050 LOCKING_ANDX_CHANGE_LOCKTYPE 0x04 Change lock type 3051 LOCKING_ANDX_CANCEL_LOCK 0x08 Cancel outstanding request 3052 LOCKING_ANDX_LARGE_FILES 0x10 Large file locking format 3054 LOCKING_ANDX_RANGE Format 3055 ===================================================================== 3057 USHORT Pid; PID of process "owning" lock 3058 ULONG Offset; Offset to bytes to [un]lock 3059 ULONG Length; Number of bytes to [un]lock 3061 Large File LOCKING_ANDX_RANGE Format 3062 ===================================================================== 3064 USHORT Pid; PID of process "owning" lock 3065 USHORT Pad; Pad to DWORD align (mbz) 3066 ULONG OffsetHigh; Offset to bytes to [un]lock 3067 (high) 3068 ULONG OffsetLow; Offset to bytes to [un]lock (low) 3069 ULONG LengthHigh; Number of bytes to [un]lock 3070 (high) 3071 ULONG LengthLow; Number of bytes to [un]lock (low) 3072 Server Response Description 3073 ================================== ================================= 3075 UCHAR WordCount; Count of parameter words = 2 3076 UCHAR AndXCommand; Secondary (X) command; 0xFF = 3077 none 3078 UCHAR AndXReserved; Reserved (must be 0) 3079 USHORT AndXOffset; Offset to next command WordCount 3080 USHORT ByteCount; Count of data bytes = 0 3082 Locking is a simple mechanism for synchronizing processes' read/write 3083 accesses to regions of a file. The locked regions can be anywhere in 3084 the logical file. Locking beyond end-of-file is permitted. Any request 3085 coming in on the same connection and using the same Pid and Fid as 3086 specified in a successful lock request has access to the locked bytes; 3087 other requests will be denied the locking, reading, or writing of the 3088 locked bytes if they are incompatible with the lock mode. 3090 The proper method for using locks is not to rely on being denied read or 3091 write access on any of the read/write protocols but rather to attempt 3092 the locking protocol and proceed with the read/write only if the locks 3093 succeeded. 3095 Locking a range of bytes will fail if any subranges or overlapping 3096 ranges are locked. In other words, if any of the specified bytes are 3097 already locked, the lock will fail. 3099 If NumberOfUnlocks is non-zero, the Unlocks vector contains 3100 NumberOfUnlocks elements. Each element requests that a lock at Offset 3101 of Length be released. If NumberOfLocks is nonzero, the Locks vector 3102 contains NumberOfLocks elements. Each element requests the acquisition 3103 of a lock at Offset of Length. 3105 Timeout is the maximum amount of time to wait for the byte range(s) 3106 specified to become unlocked. A timeout value of 0 indicates that the 3107 server should fail immediately if any lock range specified is locked. A 3108 timeout value of -1 indicates that the server should wait as long as it 3109 takes for each byte range specified to become unlocked so that it may be 3110 again locked by this protocol. Any other value of smb_timeout specifies 3111 the maximum number of milliseconds to wait for all lock range(s) 3112 specified to become available. 3114 If any of the lock ranges timeout because of the area to be locked is 3115 already locked (or the lock fails), the other ranges in the protocol 3116 request which were successfully locked as a result of this protocol will 3117 be unlocked (either all requested ranges will be locked when this 3118 protocol returns to the client or none). 3120 If LockType has the LOCKING_ANDX_SHARED_LOCK flag set, the lock is 3121 specified as a shared lock. Locks for both read and write (where 3122 LOCKING_ANDX_SHARED_LOCK is clear) should be prohibited, but other 3123 shared locks should be permitted. If shared locks can not be supported 3124 by a server, the server should map the lock to a lock for both read and 3125 write. Closing a file with locks still in force causes the locks to be 3126 released in no defined order. 3128 If LockType has the LOCKING_ANDX_LARGE_FILES flag set then the Locks and 3129 Unlocks vectors are in the Large File LOCKING_ANDX_RANGE format. This 3130 allows specification of 64 bit offsets for very large files. 3132 If the one and only member of the Locks vector has the 3133 LOCKING_ANDX_CANCEL_LOCK flag set in the LockType field, the client is 3134 requesting the server to cancel a previously requested, but not yet 3135 responded to, lock. 3137 If LockType has the LOCKING_ANDX_CHANGE_LOCKTYPE flag set, the client is 3138 requesting that the server atomically change the lock type from a shared 3139 lock to an exclusive lock or vice versa. If the server can not do this 3140 in an atomic fashion, the server must reject this request. (Note: 3141 Windows NT and Windows 95 servers do not support this capability.) 3143 4.2.6.1 Oplocks 3145 Oplocks are described in the "Opportunistic Locks" section elsewhere in 3146 this document. Part of their specification requires that the client 3147 will be notified when another client makes certain requests. When that 3148 happens, the server delays the second request and notifies the client 3149 via an SMB_LOCKING_ANDX SMB asynchronously sent from the server to the 3150 client. This message has the LOCKING_ANDX_OPLOCK_RELEASE flag set 3151 indicating to the client that the oplock is being broken. OplockLevel 3152 indicates the type of oplock the client now owns. If OplockLevel is 0, 3153 the client possesses no oplocks on the file at all, if OplockLevel is 1 3154 the client possesses a Level II oplock. 3156 If an acknowledgement is required, the client responds to the server 3157 with either an SMB_LOCKING_ANDX SMB having the 3158 LOCKING_ANDX_OPLOCK_RELEASE flag set, or with a file close if the file 3159 is no longer in use by the client. If the client sends an 3160 SMB_LOCKING_ANDX SMB with the LOCKING_ANDX_OPLOCK_RELEASE flag set and 3161 NumberOfLocks is zero, the server MUST NOT send a response. Since a 3162 close being sent to the server and break oplock notification from the 3163 server could cross on the wire, if the client gets an oplock 3164 notification on a file which it does not have open, that notification 3165 should be ignored. 3167 The entire message sent and received including the optional second 3168 protocol must fit in the negotiated maximum transfer size. The 3169 following are the only valid SMB commands for AndXCommand for 3170 SMB_COM_LOCKING_ANDX: 3172 SMB_COM_READ SMB_COM_READ_ANDX 3173 SMB_COM_WRITE SMB_COM_WRITE_ANDX 3174 SMB_COM_FLUSH 3176 4.2.6.2 Errors 3178 ERRDOS/ERRbadfile 3179 ERRDOS/ERRbadfid 3180 ERRDOS/ERRlock 3181 ERRDOS/ERRinvdevice 3182 ERRSRV/ERRinvid 3183 ERRSRV/ERRbaduid 3185 4.2.7 FLUSH: Flush File 3187 The flush SMB is sent to ensure all data and allocation information for 3188 the corresponding file has been written to stable storage. When the Fid 3189 has a value -1 (hex FFFF) the server performs a flush for all file 3190 handles associated with the client and Pid. The response is not sent 3191 until the writes are complete. 3193 Client Request Description 3194 ================================== ================================= 3196 UCHAR WordCount; Count of parameter words = 1 3197 USHORT Fid; File handle 3198 USHORT ByteCount; Count of data bytes = 0 3200 This client request is probably expensive to perform at the server, 3201 since the server's operating system is generally scheduling disk writes 3202 is a way which is optimal for the system's read and write activity 3203 integrated over the entire population of clients. This message from a 3204 client "interferes" with the server's ability to optimally schedule the 3205 disk activity; clients are discouraged from overuse of this SMB request. 3207 Server Response Description 3208 ================================== ================================= 3210 UCHAR WordCount; Count of parameter words = 0 3211 USHORT ByteCount; Count of data bytes = 0 3213 4.2.7.1 Errors 3215 ERRDOS/ERRbadfid 3216 ERRSRV/ERRinvid 3217 ERRSRV/ERRbaduid 3219 4.2.8 CLOSE: Close File 3221 The close message is sent to invalidate a file handle for the requesting 3222 process. All locks or other resources held by the requesting process on 3223 the file should be released by the server. The requesting process can 3224 no longer use Fid for further file access requests. 3226 Client Request Description 3227 ================================== ================================= 3229 UCHAR WordCount; Count of parameter words = 3 3230 USHORT Fid; File handle 3231 UTIME LastWriteTime Time of last write 3232 USHORT ByteCount; Count of data bytes = 0 3234 If LastWriteTime is 0, the server should allow its local operating 3235 system to set the file's times. Otherwise, the server should set the 3236 time to the values requested. Failure to set the times, even if 3237 requested by the client in the request message, should not result in an 3238 error response from the server. 3240 If Fid refers to a print spool file, the file should be spooled to the 3241 printer at this time. 3243 Server Response Description 3244 ================================== ================================= 3246 UCHAR WordCount; Count of parameter words = 0 3247 USHORT ByteCount; Count of data bytes = 0 3249 4.2.8.1 Errors 3251 ERRDOS/ERRbadfid 3252 ERRSRV/ERRinvdevice 3253 ERRSRV/ERRinvid 3254 ERRSRV/ERRbaduid 3255 4.2.9 DELETE: Delete File 3257 The delete file message is sent to delete a data file. The appropriate 3258 Tid and additional pathname are passed. Read only files may not be 3259 deleted, the read-only attribute must be reset prior to file deletion. 3261 Client Request Description 3262 ================================== ================================= 3264 UCHAR WordCount; Count of parameter words = 1 3265 USHORT SearchAttributes; 3266 USHORT ByteCount; Count of data bytes; min = 2 3267 UCHAR BufferFormat; 0x04 3268 STRING FileName[]; File name 3270 Multiple files may be deleted in response to a single request as 3271 SMB_COM_DELETE supports wildcards 3273 SearchAttributes indicates the attributes that the target file(s) must 3274 have. If the attribute is zero then only normal files are deleted. If 3275 the system file or hidden attributes are specified then the delete is 3276 inclusive -both the specified type(s) of files and normal files are 3277 deleted. Attributes are described in the "Attribute Encoding" section 3278 of this document. 3280 If bit0 of the Flags2 field of the SMB header is set, a pattern is 3281 passed in, and the file has a long name, then the passed pattern much 3282 match the long file name for the delete to succeed. If bit0 is clear, a 3283 pattern is passed in, and the file has a long name, then the passed 3284 pattern must match the file's short name for the deletion to succeed. 3286 Server Response Description 3287 ================================== ================================= 3289 UCHAR WordCount; Count of parameter words = 0 3290 USHORT ByteCount; Count of data bytes = 0 3292 4.2.9.1 Errors 3294 ERRDOS/ERRbadpath 3295 ERRDOS/ERRbadfile 3296 ERRDOS/ERRnoaccess 3297 ERRHRD/ERRnowrite 3298 ERRSRV/ERRaccess 3299 ERRSRV/ERRinvdevice 3300 ERRSRV/ERRinvid 3301 ERRSRV/ERRbaduid 3302 4.2.10 RENAME: Rename File 3304 The rename file message is sent to change the name of a file. 3306 Client Request Description 3307 ================================== ================================= 3309 UCHAR WordCount; Count of parameter words = 1 3310 USHORT SearchAttributes; Target file attributes 3311 USHORT ByteCount; Count of data bytes; min = 4 3312 UCHAR BufferFormat1; 0x04 3313 STRING OldFileName[]; Old file name 3314 UCHAR BufferFormat2; 0x04 3315 STRING NewFileName[]; New file name 3317 Files OldFileName must exist and NewFileName must not. Both pathnames 3318 must be relative to the Tid specified in the request. Open files may be 3319 renamed. 3321 Multiple files may be renamed in response to a single request as Rename 3322 File supports wildcards in the file name (last component of the 3323 pathname). 3325 SearchAttributes indicates the attributes that the target file(s) must 3326 have. If SearchAttributes is zero then only normal files are renamed. 3327 If the system file or hidden attributes are specified then the rename is 3328 inclusive -both the specified type(s) of files and normal files are 3329 renamed. The encoding of SearchAttributes is described in section 3.11 3330 - File Attribute Encoding. 3332 Server Response Description 3333 ================================== ================================= 3335 UCHAR WordCount; Count of parameter words = 0 3336 USHORT ByteCount; Count of data bytes = 0 3338 4.2.10.1 Errors 3340 ERRDOS/ERRbadpath 3341 ERRDOS/ERRbadfile 3342 ERRDOS/ERRnoaccess 3343 ERRDOS/ERRdiffdevice 3344 ERRHRD/ERRnowrite 3345 ERRSRV/ERRaccess 3346 ERRSRV/ERRinvdevice 3347 ERRSRV/ERRinvid 3348 ERRSRV/ERRbaduid 3349 4.2.11 MOVE: Rename File 3351 The source file is copied to the destination and the source is 3352 subsequently deleted. 3354 Client Request Description 3355 ================================== ================================= 3357 UCHAR WordCount; Count of parameter words = 3 3358 USHORT Tid2; Second (target) file id 3359 USHORT OpenFunction; what to do if target file exists 3360 USHORT Flags; Flags to control move operations: 3361 0 - target must be a file 3362 1 - target must be a directory 3363 2 - reserved (must be 0) 3364 3 - reserved (must be 0) 3365 4 - verify all writes 3366 USHORT ByteCount; Count of data bytes; min = 2 3367 UCHAR Format1; 0x04 3368 STRING OldFileName[]; Old file name 3369 UCHAR FormatNew; 0x04 3370 STRING NewFileName[]; New file name 3372 OldFileName is copied to NewFileName, then OldFileName is deleted. Both 3373 OldFileName and NewFileName must refer to paths on the same server. 3374 NewFileName can refer to either a file or a directory. All file 3375 components except the last must exist; directories will not be created. 3377 NewFileName can be required to be a file or a directory by the Flags 3378 field. 3380 The Tid in the header is associated with the source while Tid2 is 3381 associated with the destination. These fields may contain the same or 3382 differing valid values. Tid2 can be set to -1 indicating that this is to 3383 be the same Tid as in the SMB header. This allows use of the move 3384 protocol with SMB_TREE_CONNECT_ANDX. 3386 Server Response Description 3387 ================================== ================================= 3389 UCHAR WordCount; Count of parameter words = 1 3390 USHORT Count; Number of files moved 3391 USHORT ByteCount; Count of data bytes; min = 0 3392 UCHAR ErrorFileFormat; 0x04 (only if error) 3393 STRING ErrorFileName[]; Pathname of file where error 3394 occurred 3395 The source path must refer to an existing file or files. Wildcards are 3396 permitted. Source files specified by wildcards are processed until an 3397 error is encountered. If an error is encountered, the expanded name of 3398 the file is returned in ErrorFileName. Wildcards are not permitted in 3399 NewFileName. 3401 OpenFunction controls what should happen if the destination file exists. 3402 If (OpenFunction & 0x30) == 0, the operation should fail if the 3403 destination exists. If (OpenFunction & 0x30) == 0x20, the destination 3404 file should be overwritten. 3406 4.2.11.1 Errors 3408 ERRDOS/ERRfilexists 3409 ERRDOS/ERRbadfile 3410 ERRDOS/ERRnoaccess 3411 ERRDOS/ERRnofiles 3412 ERRDOS/ERRbadshare 3413 ERRHRD/ERRnowrite 3414 ERRSRV/ERRnoaccess 3415 ERRSRV/ERRinvdevice 3416 ERRSRV/ERRinvid 3417 ERRSRV/ERRbaduid 3418 ERRSRV/ERRnosupport 3419 ERRSRV/ERRaccess 3420 4.2.12 COPY: Copy File 3422 Client Request Description 3423 ================================== ================================= 3425 UCHAR WordCount; Count of parameter words = 3 3426 USHORT Tid2; Second (target) path TID 3427 USHORT OpenFunction; What to do if target file exists 3428 USHORT Flags; Flags to control copy operation: 3429 bit 0 - target must be a file 3430 bit 1 - target must be a dir. 3431 bit 2 - copy target mode: 3432 0 = binary, 1 = ASCII 3433 bit 3 - copy source mode: 3434 0 = binary, 1 = ASCII 3435 bit 4 - verify all writes 3436 bit 5 - tree copy 3437 USHORT ByteCount; Count of data bytes; min = 2 3438 UCHAR SourceFileNameFormat; 0x04 3439 STRING SourceFileName; Pathname of source file 3440 UCHAR TargetFileNameFormat; 0x04 3441 STRING TargetFileName; Pathname of target file 3443 The file at SourceName is copied to TargetFileName, both of which must refer 3444 to paths on the same server. 3446 The Tid in the header is associated with the source while Tid2 is 3447 associated with the destination. These fields may contain the same or 3448 differing valid values. Tid2 can be set to -1 indicating that this is to 3449 be the same Tid as in the SMB header. This allows use of the move 3450 protocol with SMB_TREE_CONNECT_ANDX. 3452 Server Response Description 3453 ================================== ================================= 3455 UCHAR WordCount; Count of parameter words = 1 3456 USHORT Count; Number of files copied 3457 USHORT ByteCount; Count of data bytes; min = 0 3458 UCHAR ErrorFileFormat; 0x04 (only if error) 3459 STRING ErrorFileName; 3461 The source path must refer to an existing file or files. Wildcards are 3462 permitted. Source files specified by wildcards are processed until an 3463 error is encountered. If an error is encountered, the expanded name of 3464 the file is returned in ErrorFileName. Wildcards are not permitted in 3465 TargetFileName. TargetFileName can refer to either a file or a direc- 3466 tory. 3468 The destination can be required to be a file or a directory by the bits 3469 in Flags. If neither bit0 nor bit1 are set, the destination may be 3470 either a file or a directory. Flags also controls the copy mode. In a 3471 binary copy for the source, the copy stops the first time an EOF 3472 (control-Z) is encountered. In a binary copy for the target, the server 3473 must make sure that there is exactly one EOF in the target file and that 3474 it is the last character of the file. 3476 If the destination is a file and the source contains wildcards, the 3477 destination file will either be truncated or appended to at the start of 3478 the operation depending on bits in OpenFunction (see section 3.7). 3479 Subsequent files will then be appended to the file. 3481 If the negotiated dialect is LM1.2X002 or later, bit5 of Flags is used 3482 to specify a tree copy on the remote server. When this option is 3483 selected the destination must not be an existing file and the source 3484 mode must be binary. A request with bit5 set and either bit0 or bit3 3485 set is therefore an error. When the tree copy mode is selected, the 3486 Count field in the server response is undefined. 3488 4.2.12.1 Errors 3490 ERRDOS/ERRfilexists 3491 ERRDOS/ERRshare 3492 ERRDOS/ERRnofids 3493 ERRDOS/ERRbadfile 3494 ERRDOS/ERRnoaccess 3495 ERRDOS/ERRnofiles 3496 ERRDOS/ERRbadshare 3497 ERRSRV/ERRnoaccess 3498 ERRSRV/ERRinvdevice 3499 ERRSRV/ERRinvid 3500 ERRSRV/ERRbaduid 3501 ERRSRV/ERRaccess 3503 4.2.13 TRANS2_QUERY_PATH_INFORMATION: Get File Attributes given 3504 Path 3506 This request is used to get information about a specific file or 3507 subdirectory. 3509 Client Request Value 3510 ========================== ========================================= 3512 WordCount 15 3513 MaxSetupCount 0 3514 SetupCount 1 3515 Setup[0] TRANS2_QUERY_PATH_INFORMATION 3517 Parameter Block Encoding Description 3518 ========================== ========================================= 3520 USHORT InformationLevel; Level of information requested 3521 ULONG Reserved; Must be zero 3522 STRING FileName; File or directory name 3524 The following InformationLevels may be requested: 3526 Information Level Value 3528 ================================ ===== 3530 SMB_INFO_STANDARD 1 3531 SMB_INFO_QUERY_EA_SIZE 2 3532 SMB_INFO_QUERY_EAS_FROM_LIST 3 3533 SMB_INFO_QUERY_ALL_EAS 4 3534 SMB_INFO_IS_NAME_VALID 6 3535 SMB_QUERY_FILE_BASIC_INFO 0x101 3536 SMB_QUERY_FILE_STANDARD_INFO 0x102 3537 SMB_QUERY_FILE_EA_INFO 0x103 3538 SMB_QUERY_FILE_NAME_INFO 0x104 3539 SMB_QUERY_FILE_ALL_INFO 0x107 3540 SMB_QUERY_FILE_ALT_NAME_INFO 0x108 3541 SMB_QUERY_FILE_STREAM_INFO 0x109 3542 SMB_QUERY_FILE_COMPRESSION_INFO 0x10B 3544 The requested information is placed in the Data portion of the 3545 transaction response. For the information levels greater than 0x100, 3546 the transaction response has 1 parameter word which should be ignored by 3547 the client. 3549 The following sections describe the InformationLevel dependent encoding 3550 of the data part of the transaction response. 3552 4.2.13.1 SMB_INFO_STANDARD & SMB_INFO_QUERY_EA_SIZE 3554 Data Block Encoding Description 3555 =============================== ==================================== 3557 SMB_DATE CreationDate; Date when file was created 3558 SMB_TIME CreationTime; Time when file was created 3559 SMB_DATE LastAccessDate; Date of last file access 3560 SMB_TIME LastAccessTime; Time of last file access 3561 SMB_DATE LastWriteDate; Date of last write to the file 3562 SMB_TIME LastWriteTime; Time of last write to the file 3563 ULONG DataSize; File Size 3564 ULONG AllocationSize; Size of filesystem allocation unit 3565 USHORT Attributes; File Attributes 3566 ULONG EaSize; Size of file's EA information 3567 (SMB_INFO_QUERY_EA_SIZE) 3569 4.2.13.2 SMB_INFO_QUERY_EAS_FROM_LIST & SMB_INFO_QUERY_ALL_EAS 3571 Response Field Value 3572 ==================== =============================================== 3574 MaxDataCount Length of EAlist found (minimum value is 4) 3576 Parameter Block Description 3577 Encoding =============================================== 3578 ==================== 3580 USHORT EaErrorOffset Offset into EAList of EA error 3582 Data Block Encoding Description 3583 ==================== =============================================== 3585 ULONG ListLength; Length of the remaining data 3586 UCHAR EaList[] The extended attributes list 3588 4.2.13.3 SMB_INFO_IS_NAME_VALID 3590 This requests checks to see if the name of the file contained in the 3591 request's Data field has a valid path syntax. No parameters or data are 3592 returned on this information request. An error is returned if the syntax 3593 of the name is incorrect. Success indicates the server accepts the path 3594 syntax, but it does not ensure the file or directory actually exists. 3596 4.2.13.4 SMB_QUERY_FILE_BASIC_INFO 3598 Data Block Encoding Description 3599 =============================== ==================================== 3601 LARGE_INTEGER CreationTime; Time when file was created 3602 LARGE_INTEGER LastAccessTime; Time of last file access 3603 LARGE_INTEGER LastWriteTime; Time of last write to the file 3604 LARGE_INTEGER ChangeTime Time when file was last changed 3605 USHORT Attributes; File Attributes 3607 4.2.13.5 SMB_QUERY_FILE_STANDARD_INFO 3609 Data Block Encoding Description 3610 =============================== ==================================== 3612 LARGE_INTEGER AllocationSize Allocated size of the file in number 3613 of bytes 3614 LARGE_INTEGER EndofFile; Offset to the first free byte in the 3615 file 3616 ULONG NumberOfLinks Number of hard links to the file 3617 BOOLEAN DeletePending Indicates whether the file is marked 3618 for deletion 3619 BOOLEAN Directory Indicates whether the file is a 3620 directory 3622 4.2.13.6 SMB_QUERY_FILE_EA_INFO 3624 Data Block Encoding Description 3625 =============================== ==================================== 3627 ULONG EASize Size of the file's extended 3628 attributes in number of bytes 3630 4.2.13.7 SMB_QUERY_FILE_NAME_INFO 3632 Data Block Encoding Description 3633 =============================== ==================================== 3635 ULONG FileNameLength Length of the file name in number of 3636 bytes 3637 STRING FileName Name of the file 3638 4.2.13.8 SMB_QUERY_FILE_ALL_INFO 3640 Data Block Encoding Description 3641 =============================== ==================================== 3643 LARGE_INTEGER CreationTime; Time when file was created 3644 LARGE_INTEGER LastAccessTime; Time of last file access 3645 LARGE_INTEGER LastWriteTime; Time of last write to the file 3646 LARGE_INTEGER ChangeTime Time when file was last changed 3647 USHORT Attributes; File Attributes 3648 LARGE_INTEGER AllocationSize Allocated size of the file in number 3649 of bytes 3650 LARGE_INTEGER EndofFile; Offset to the first free byte in the 3651 file 3652 ULONG NumberOfLinks Number of hard links to the file 3653 BOOLEAN DeletePending Indicates whether the file is marked 3654 for deletion 3655 BOOLEAN Directory Indicates whether the file is a 3656 directory 3657 LARGE_INTEGER Index Number A file system unique identifier 3658 ULONG EASize Size of the file's extended 3659 attributes in number of bytes 3660 ULONG AccessFlags Access that a caller has to the 3661 file; Possible values and meanings 3662 are specified below 3663 LARGE_INTEGER Index Number A file system unique identifier 3664 LARGE_INTEGER CurrentByteOffset Current byte offset within the file 3665 ULONG Mode Current Open mode of the file handle 3666 to the file; possible values and 3667 meanings are detailed below 3668 ULONG AlignmentRequirement Buffer Alignment required by device; 3669 possible values detailed below 3670 ULONG FileNameLength Length of the file name in number of 3671 bytes 3672 STRING FileName Name of the file 3674 The AccessFlags specifies the access permissions a caller has to the 3675 file and can have any suitable combination of the following values: 3677 Value Meaning 3679 ILE_READ_DATA 0x00000001 Data can be read from the file 3680 ILE_WRITE_DATA 0x00000002 Data can be written to the file 3681 ILE_APPEND_DATA 0x00000004 Data can be appended to the file 3682 ILE_READ_EA 0x00000008 Extended attributes associated 3683 with the file can be read 3684 ILE_WRITE_EA 0x00000010 Extended attributes associated 3685 with the file can be written 3686 ILE_EXECUTE 0x00000020 Data can be read into memory from 3687 the file using system paging I/O 3688 ILE_READ_ATTRIBUTES 0x00000080 Attributes associated with the 3689 file can be read 3690 ILE_WRITE_ATTRIBUTES 0x00000100 Attributes associated with the 3691 file can be written 3692 ELETE 0x00010000 The file can be deleted 3693 EAD_CONTROL 0x00020000 The access control list and 3694 ownership associated with the 3695 file can be read 3696 RITE_DAC 0x00040000 The access control list and 3697 ownership associated with the 3698 file can be written. 3699 RITE_OWNER 0x00080000 Ownership information associated 3700 with the file can be written 3701 YNCHRONIZE 0x00100000 The file handle can waited on to 3702 synchronize with the completion 3703 of an input/output request 3704 The Mode field specifies the mode in which the file is currently opened. 3705 The possible values may be a suitable and logical combination of the 3706 following: 3708 Value Meaning 3710 FILE_WRITE_THROUGH 0x00000002 File is opened in mode 3711 where data is written to 3712 file before the driver 3713 completes a write request 3714 FILE_SEQUENTIAL_ONLY 0x00000004 All access to the file is 3715 sequential 3716 FILE_SYNCHRONOUS_IO_ALERT 0x00000010 All operations on the 3717 file are performed 3718 synchronously 3719 FILE_SYNCHRONOUS_IO_NONALERT 0x00000020 All operations on the 3720 file are to be performed 3721 synchronously. Waits in 3722 the system to synchronize 3723 I/O queuing and 3724 completion are not 3725 subject to alerts. 3727 The AlignmentRequirement field specifies buffer alignment required by 3728 the device and can have any one of the following values: 3730 Value Meaning 3732 FILE_BYTE_ALIGNMENT 0x00000000 The buffer needs to be aligned 3733 on a byte boundary 3734 FILE_WORD_ALIGNMENT 0x00000001 The buffer needs to be aligned 3735 on a word boundary 3736 FILE_LONG_ALIGNMENT 0x00000003 The buffer needs to be aligned 3737 on a 4 byte boundary 3738 FILE_QUAD_ALIGNMENT 0x00000007 The buffer needs to be aligned 3739 on an 8 byte boundary 3740 FILE_OCTA_ALIGNMENT 0x0000000f The buffer needs to be aligned 3741 on a 16 byte boundary 3742 FILE_32_BYTE_ALIGNMENT 0x0000001f The buffer needs to be aligned 3743 on a 32 byte boundary 3744 FILE_64_BYTE_ALIGNMENT 0x0000003f The buffer needs to be aligned 3745 on a 64 byte boundary 3746 FILE_128_BYTE_ALIGNMENT 0x0000007f The buffer needs to be aligned 3747 on a 128 byte boundary 3748 FILE_256_BYTE_ALIGNMENT 0x000000ff The buffer needs to be aligned 3749 on a 256 byte boundary 3750 FILE_512_BYTE_ALIGNMENT 0x000001ff The buffer needs to be aligned 3751 on a 512 byte boundary 3753 4.2.13.9 SMB_QUERY_FILE_ALT_NAME_INFO 3755 Data Block Encoding Description 3756 ===================== ================================= 3757 === === 3759 ULONG FileNameLength Length of the file name in number 3760 of bytes 3761 STRING FileName Name of the file 3762 4.2.13.10 SMB_QUERY_FILE_STREAM_INFO 3764 Data Block Encoding Description 3765 =============================== ==================================== 3767 ULONG NextEntryOffset Offset to the next entry (in bytes) 3768 ULONG StreamNameLength Length of the stream name in number 3769 of bytes 3770 LARGE_INTEGER StreamSize Size of the stream in number of 3771 bytes 3772 LARGE_INTEGER Allocated size of the stream in 3773 StreamAllocationSize number of bytes 3774 STRING FileName Name of the stream 3776 4.2.13.11 SMB_QUERY_FILE_COMPRESSION_INFO 3778 Data Block Encoding Description 3779 =============================== ==================================== 3781 LARGE_INTEGER Size of the compressed file in 3782 CompressedFileSize number of bytes 3783 USHORT CompressionFormat A constant signifying the 3784 compression algorithm used. Possible 3785 values are: 3786 0 - There is no compression 3787 2- Compression Format is LZNT 3788 UCHAR CompressionUnitShift 3789 UCHAR ChunkShift stored in log2 format. 1<