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

> Why can a REST operation report a concurrent modification after a Linux SMB writer has closed the file?

- Canonical URL: https://update.dsesecurity.com/updates/dse-20260909-487-account-for-deferred-smb-close-before-a-rest-client-uses-the-file-etag/
- Publisher: Detection Systems & Engineering (DSE Security)
- Author: DSE Security Editorial Team
- Published: 2026-09-10T00:23:49+00:00
- Modified: 2026-09-10T02:08:05+00:00
- Last reviewed by DSE: 2026-09-09
- Resource type: Guide
- DSE priority: Information
- Topics: Cybersecurity, Networks & Infrastructure
- Reading time: 2 minutes

## What you need to know

Why can a REST operation report a concurrent modification after a Linux SMB writer has closed the file?

## Potentially affected

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.

## Article

## 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](https://learn.microsoft.com/en-us/azure/storage/files/storage-how-to-use-files-linux).

## 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](https://learn.microsoft.com/en-us/azure/storage/files/storage-how-to-use-files-linux).

## Primary reference

- Name: Mount SMB Azure File Share on Linux | Microsoft Learn
- Authority: Microsoft Learn
- URL: https://learn.microsoft.com/en-us/azure/storage/files/storage-how-to-use-files-linux
- Source publication date: Not stated by the source

## Citation and use

Preferred citation: “Account for deferred SMB close before a REST client uses the file ETag,” DSE Security, https://update.dsesecurity.com/updates/dse-20260909-487-account-for-deferred-smb-close-before-a-rest-client-uses-the-file-etag/
Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/
Usage and citation policy: https://update.dsesecurity.com/usage/
Copyright © 2026 Detection Systems & Engineering. All rights reserved.