We have a problem with file sharing when processes on several hosts accesses the same file. All hosts are running the same version of Windows 2012 R2. (host A mentioned below is a node in HA Failover Cluster, not sure if that is relevant.) One of our service engineers was able to catch a Wireshark log on when the problem occured. From the logs I can follow the smb2 messages and see that:
At this point hosts B and C has not sent SMB2 close, even though the file has been closed from the code in the read_processes, but the SMB2 close is not sent due to the opportunistic lock. Now write_process on host A want to write to the file but the Create Request immideately gets a NT Status: STATUS_SHARING_VIOLATION (0xc0000043)
The interesting thing is that I can see in the same Wireshark another file access which works as expected:
Before seeing the second, successful, example I had the theory that the problem was that host A accesses the file with no oplock. But I would now rule out that theory.
This is how the create request from host A looks like:
Frame 14521: 416 bytes on wire (3328 bits), 416 bytes captured (3328 bits) on interface 6 Null/Loopback Internet Protocol Version 4, Src: <ip A>, Dst: <ip D> Transmission Control Protocol, Src Port: 50198, Dst Port: 445, Seq: 3973846, Ack: 68498, Len: 372 NetBIOS Session Service SMB2 (Server Message Block Protocol version 2) SMB2 Header Server Component: SMB2 Header Length: 64 Credit Charge: 1 Channel Sequence: 0 Reserved: 0000 Command: Create (5) Credits requested: 1536 Flags: 0x00000008, Signing Chain Offset: 0x00000000 Message ID: Unknown (811455) Process Id: 0x0000feff Tree Id: 0x001c0025 <share name> Session Id: 0x0008500d64000069 Signature: a8ac43ccf4b4d59f2fb9b930ea01c421 [Response in: 14523] Create Request (0x05) StructureSize: 0x0039 Oplock: No oplock (0x00) Impersonation level: Impersonation (2) Create Flags: 0x0000000000000000 Reserved: 0000000000000000 Access Mask: 0x00120089 File Attributes: 0x00000080 Share Access: 0x00000003, Read, Write Disposition: Create (if file exists fail, else create it) (2) Create Options: 0x00000060 Filename: <filename> ExtraInfo SMB2_CREATE_DURABLE_HANDLE_REQUEST_V2 SMB2_CREATE_QUERY_MAXIMAL_ACCESS_REQUEST SMB2_CREATE_QUERY_ON_DISK_ID
The create request from host C look like this:
Frame 16263: 502 bytes on wire (4016 bits), 502 bytes captured (4016 bits) on interface 0 Ethernet II, Src: Cisco_a5:07:01 (00:24:14:a5:07:01), Dst: HewlettP_7a:d4:58 (14:02:ec:7a:d4:58) Internet Protocol Version 4, Src: <ip C>, Dst: <ip D> Transmission Control Protocol, Src Port: 51747, Dst Port: 445, Seq: 29594, Ack: 5030645, Len: 448 NetBIOS Session Service SMB2 (Server Message Block Protocol version 2) SMB2 Header Server Component: SMB2 Header Length: 64 Credit Charge: 1 Channel Sequence: 0 Reserved: 0000 Command: Create (5) Credits requested: 0 Flags: 0x00000008, Signing Chain Offset: 0x00000000 Message ID: Unknown (2340656) Process Id: 0x0000feff Tree Id: 0x001c0029 <share name> Session Id: 0x0008500b7c000d81 Signature: ff6476de30378d5fbba4f438c2168510 [Response in: 16304] Create Request (0x05) StructureSize: 0x0039 Oplock: Lease (0xff) Impersonation level: Anonymous (0) Create Flags: 0x0000000000000000 Reserved: 0000000000000000 Access Mask: 0x00120089 File Attributes: 0x00000000 Share Access: 0x00000005, Read, Delete Disposition: Open (if file exists open it, else fail) (1) Create Options: 0x00400060 Filename: <filename> Offset: 0x00000078 Length: 140 ExtraInfo SMB2_CREATE_DURABLE_HANDLE_REQUEST_V2 SMB2_CREATE_QUERY_MAXIMAL_ACCESS_REQUEST SMB2_CREATE_QUERY_ON_DISK_ID SMB2_CREATE_REQUEST_LEASE Offset: 0x00000108 Length: 180 Chain Element: SMB2_CREATE_DURABLE_HANDLE_REQUEST_V2 "DH2Q" Chain Element: SMB2_CREATE_QUERY_MAXIMAL_ACCESS_REQUEST "MxAc" Chain Element: SMB2_CREATE_QUERY_ON_DISK_ID "QFid" Chain Element: SMB2_CREATE_REQUEST_LEASE "RqLs"
Any idea why the breaking of the oplock works in one case but not on another?
User contributions licensed under CC BY-SA 3.0