Account for deferred SMB close before a REST client uses the file ETag

Source facts

The Linux SMB client can defer sending CLOSE after the application closes a file. On Azure Files, receiving CLOSE after a write updates the last-modified time and ETag. A REST client can therefore obtain an ETag and then fail a conditional operation with HTTP 412 when the deferred close changes it. Microsoft recommends closetimeo=0 for SMB-writer/REST-reader handoffs, trading some open/close performance for immediate close processing. Microsoft Learn.

Applicability

Use this check for a Linux SMB writer and FileREST client accessing the same Azure file share. Confirm the supported client and mount configuration; this article is not an instruction to change the share’s authentication method.

DSE recommendation

Trace the close-to-REST handoff before removing concurrency protection. Have both application owners identify when the writer considers its work finished and when the REST caller obtains its condition value. Review the documented mount option in a controlled client configuration, keeping the previous value available. Do not replace a conditional write with an unconditional overwrite merely to hide the error. Include the performance tradeoff in the acceptance decision.

Verification

In an approved test, correlate the SMB close, observed ETag and REST result for the same file. Repeat the handoff after the reviewed mount change and check both correctness and representative open/close behavior. Retain other genuine concurrent writers in the investigation if failures remain. Accept the change only when the intended handoff works without weakening the application’s concurrency checks.

Official references

Microsoft Learn: Mount SMB Azure File Share on Linux.