SMB handles and leases: reconnect is not write durability

Separate recovery, caching and access

The distinctions follow the protocol's open state and leasing rules, with failover context from Microsoft's implementation account. [open state] [leasing] [failover]

A durable handle preserves an open, not a connection

The specification describes a durable open as recoverable after a network disconnect. Its scope is a file, not a directory, named pipe or printer. [glossary] The server records whether the open is reconnectable, how long to retain it and who originally opened it. A timeout or failed authorization can prevent recovery. [open state]

Reconnection is an explicit protocol operation: the client reaches the share and sends CREATE with a reconnect context. The SMB 3.x form identifies the old open and its create identifier; a persistent open also carries the persistent flag. Reusing a path string alone is not that recovery procedure. [re-establishment]

Persistent handles add a failover contract

For a non-directory open, the underlying store must first grant durability. SMB 3.x then requires the persistent request flag, a continuously available share and server support for persistent handles. Inspect the granted response and effective share configuration, not merely the client's requested flag. [V2 processing]

Microsoft's 2012 Windows Server design persists handle state for recovery through another cluster node and combines persistent opens with write-through. It explicitly describes a temporary I/O stall. Thus handle recovery and data persistence are coordinated but distinct, and transparent failover does not mean uninterrupted throughput. This is a historical implementation explanation, not a measured guarantee for every SMB appliance. [failover]

A lease is a caching agreement

READ caching retains fetched data; WRITE caching permits buffered writes; HANDLE caching can defer closes or opens. Multiple opens with the same client lease identity can share state. Conflicting operations can require a reduction in caching rights through a lease break. HANDLE caching is not a synonym for durable-handle recovery. [leasing]

Nor is a lease simply an application-selected rental period: the LeaseDuration field in the lease-request structure is reserved. Do not use it as an expiry timer. [lease request] The client tracks granted caching rights in its per-file lease state. [client state]

The same word does not imply the same timer

Gray and Cheriton's 1989 paper describes time-bounded cache rights: a conflicting write waits for approval or expiry. Its safety argument assumes bounded clock drift and server-persistent writes. The evaluation combines an analytical model with a V-system recompilation trace from one client, not an SMB deployment. [sections 2, 3.2, 5]

SMB's reserved LeaseDuration field does not expose that lease-term policy. Follow SMB's granted rights and break protocol, not a timer inferred from the historical name. This is a comparison of contracts, not evidence that either mechanism is universally faster or that this paper specifies SMB. [lease request]

Cache grants are not byte-range locks

An opportunistic lock (oplock) coordinates client caching. It is not an application lock on file bytes. [oplocks] Classic oplock levels and leases use different CREATE encodings; a lease requires an accompanying create context. SMB 2.0.2 does not accept the lease request level. [CREATE] Break handling also varies: a level-II-to-none oplock break does not require client acknowledgement. [break acknowledgement]

A byte-range lock instead associates shared or exclusive access restrictions with an open and a byte interval. The client resolves process-level conflicts locally. [LOCK] Shared locking permits reads but prevents writes by every open, including the holder; exclusive locking blocks other opens from reading, writing or locking that interval. Unlocking a subrange of the original lock is not permitted. [range semantics]

These mechanisms interact: WRITE caching can include byte-range locks. [client state] Their roles remain distinct. A successful lock is not evidence of a completed stable write, and these SMB rules alone do not certify exclusion through unrelated access paths.

Ask which write actually completed

SMB WRITE defines separate write-through and unbuffered flags. Their permitted dialects also differ. A request to bypass buffering is not interchangeable with a request for write-through. [WRITE request]

FLUSH is not always another physical flush

For an open file, SMB FLUSH asks for cached information to reach its backing persistent store. For a named pipe, it instead waits for a reader to consume previously written data. [FLUSH request] After validation, a persistent open returns success without another object-store flush; other opens request that flush and wait for completion. [server processing]

The CREATE path separately requires FILE_WRITE_THROUGH for SMB 3.x on a continuously available disk share when the server advertises persistent-handle support. This rule does not require a persistent handle to be requested or granted. [CREATE processing] A successful protocol response is not an independent hardware power-loss test.

Consider an application record still held only in a client's volatile buffer when that client loses power. Recovering the server's file-open state cannot reconstruct bytes the server never received. This is a constructed boundary example, not an observed SMB failure. It makes no claim that a correctly completed write-through operation loses its acknowledged data.

A useful isolated test would record the negotiated dialect, granted create contexts, share capabilities, write and flush outcomes, and application recovery checks. Separate a network outage from server failover and client power loss. These are proposed verification steps; no fault-injection test was performed for this review.

Scope and further reading

This review explains protocol contracts. It does not certify a NAS, client, filesystem or storage controller, supply a recovery-time bound, or establish application transaction atomicity. The current specification governs protocol details; the 2012 source explains one implementation's design.

Compare NFS stability and COMMIT and uncertain completion after a timeout.

Structured definitions: SMB, durable handle, persistent handle, lease, oplock and byte-range lock.

Primary sources

1. Microsoft MS-SMB2 section 1.1: Glossary
2. Microsoft MS-SMB2 section 3.3.1.10: Per Open
3. Microsoft MS-SMB2 section 3.2.4.4: Re-establishing a Durable Open
4. Microsoft MS-SMB2 section 3.3.5.9.10: Durable Handle Request V2 processing
5. Microsoft Windows Server engineering team: Taking Server Application Storage to Windows File Shares (2012)
6. Microsoft MS-SMB2 section 3.3.1.4: Algorithm for Leasing in an Object Store
7. Microsoft MS-SMB2 section 2.2.13.2.8: Lease request
8. Microsoft MS-SMB2 section 3.2.1.5: Per Open File
9. Microsoft MS-SMB2 section 2.2.21: SMB2 WRITE Request
10. Microsoft Win32: Opportunistic Locks
11. Microsoft MS-SMB2 section 2.2.13: SMB2 CREATE Request
12. Microsoft MS-SMB2 section 2.2.24.1: Oplock Break Acknowledgment
13. Microsoft MS-SMB2 section 2.2.26: SMB2 LOCK Request
14. Microsoft MS-SMB2 section 2.2.26.1: SMB2_LOCK_ELEMENT Structure
15. Microsoft MS-SMB2 section 2.2.17: SMB2 FLUSH Request
16. Microsoft MS-SMB2 section 3.3.5.11: Receiving an SMB2 FLUSH Request
17. Microsoft MS-SMB2 section 3.3.5.9: Receiving an SMB2 CREATE Request
18. Cary G. Gray and David R. Cheriton: Leases: An Efficient Fault-Tolerant Mechanism for Distributed File Cache Consistency (SOSP 1989), sections 2, 3.2 and 5

Reviewed 14 October 2026. No copied diagrams or hardware measurements.