SMB 2.2 durable handles fallback to SMB 2.1 behavior on Windows 8 clients

Question

Determine whether a Windows 8 client will automatically disable durable handles and revert to non‑durable SMB 2.1 semantics when the server advertises only SMB 2.1, and how this affects write retry safety.

The documentation states that durable handles are enabled by default for SMB 2.2 connections but does not specify the client‑side fallback logic when the negotiated dialect is lower than 2.2. This leaves uncertainty about whether the client treats the connection as non‑durable, attempts to emulate durability, or applies a different timeout/retry scheme.

What does the Windows 8 client do with durable handle state when connecting to an SMB 2.1‑only server?
Does the fallback automatically disable durable handles, and if so, is this behavior configurable?
How does the fallback impact the likelihood of duplicate writes on brief network interruptions?

Tasadduq Burney · Answer

Durable Handle Fallback Logic
A Windows 8 client will automatically disable durable handles and revert to non-durable SMB 2.1 semantics when the server advertises only SMB 2.1. Because durable handles are a feature introduced specifically in the SMB 2.2 dialect, they cannot be emulated or applied to a connection negotiated at a lower version.

Behavioral Analysis
When the Negotiate Protocol exchange concludes with the selection of SMB 2.1, the client adheres strictly to the SMB 2.1 specification. This has the following effects:

Automatic Disablement: The client does not send the durable handle flag in Create Request packets.
  State Loss: Any file handles held during a session are tied to that specific session ID. If the session expires or the network disconnects, the server drops the handles immediately.
  Non-Configurability: This fallback is a result of the negotiated protocol dialect; there is no registry key or group policy to "force" durable handle behavior on a server that does not support the SMB 2.2 dialect.

Impact on Write Retry Safety
The fallback significantly reduces write retry safety during brief network interruptions. In a durable handle scenario (SMB 2.2+), the client can reconnect and resume operations using the existing handle. In an SMB 2.1 fallback:

The connection is severed, and the server invalidates the handle.
  The client receives an error (typically STATUS_NETWORK_NAME_DELETED or STATUS_CONNECTION_DISCONNECTED).
  The application must re-open the file to obtain a new handle.

This creates a risk of duplicate writes or data inconsistency if the client retries a write operation without knowing whether the previous request was processed by the server before the disconnect occurred.

Verification Steps
To confirm the current behavior in your environment, use a protocol analyzer like Wireshark:

Check Dialect: Inspect the Negotiate Protocol Response to confirm the dialect is 2.1.
  Inspect Create Requests: Verify that the Create Request packets do not contain the durable handle flags.
  Test Recovery: Simulate a network drop. If the application immediately reports an invalid handle rather than pausing for a transparent reconnect, the client is operating under SMB 2.1 semantics.

Missing Diagnostic: Please specify if the client is connecting to a Windows Server or a non-Windows (Samba) implementation, as some third-party implementations may handle session timeouts differently even within the 2.1 dialect.

SMB 2.2 durable handles fallback to SMB 2.1 behavior on Windows 8 clients

1 answer

Durable Handle Fallback Logic

Behavioral Analysis

Impact on Write Retry Safety

Verification Steps

Your perspective belongs here.

0 question comments