Azure Files Diagnostic Logs - How to reliably identify files deleted over SMB and automate deleted file reporting?

Question

We have an Azure File Share mounted on a Linux server using the SMB protocol. We have enabled Azure Files Diagnostic Settings and enabled on Delete Operation and are sending the logs to a Log Analytics Workspace.

Our requirement is to identify which files are permanently deleted from the mounted file share and automate a report of those deleted files.

During our testing, we observed the following:

• When a file is deleted from the Azure Portal (HTTPS/REST API):
  • OperationName = DeleteFile
    • This clearly indicates a delete operation.
    • When a file is deleted from the mounted server over SMB:
      • OperationName = Close
        • Category = StorageDelete
          • SmbCommandMinor = FileCloseAndDelete

In my test environment, deleting a file (rm file.txt) generated the above SMB log, and the file was actually removed from the file share.

However, in our production environment, we also see multiple entries with:

• Category = StorageDelete
• OperationName = Close

but some of those files are still present in the Azure File Share. This suggests the application may be deleting and recreating or replacing files as part of its normal processing.

Our queries are related to:

1. Is Category = StorageDelete with SmbCommandMinor = FileCloseAndDelete expected to represent every SMB delete request, even if the file is later recreated?
2. Is there any Azure diagnostic log or audit log that can definitively identify files that were permanently deleted over SMB?
3. Is there any Microsoft-recommended approach to generate a daily/weekly report of deleted files from Azure File Shares?
4. What would be the most cost-effective way to automate such a report? For example:

• Log Analytics scheduled query
• Azure Workbook
• Logic App
• Azure Automation Runbook
• Azure Function

Answer 1

Hello Abrar Adil S,

Greetings! Thanks for raising this question in the Q&A forum.

The behavior you are seeing is expected, and it comes down to how SMB2 reports deletes at the protocol level rather than anything wrong with your diagnostic settings.

Root cause

Over SMB, there is no separate "delete" command the way there is with the REST API's DeleteFile operation. Instead, deletion happens through the Close request when the file handle was opened with the delete-on-close flag set. Azure Files surfaces this as Category = StorageDelete, OperationName = Close, SmbCommandMinor = FileCloseAndDelete. This entry only tells you that a delete-on-close was requested at that moment, not that the path stays gone. A very common pattern in applications (editors, sync clients, atomic-save logic, some backup or ETL tools) is to write a new temp file, delete the original, then rename or recreate the file at the same path, so you will legitimately see repeated FileCloseAndDelete entries for paths that are still present. There is no separate flag in the log that marks a delete as "final."

1. Confirm you are reading the correct schema

Run a quick sample query first to see the exact column names in your workspace, since field naming can vary slightly by log format version:

StorageFileLogs
| where Category == "StorageDelete"
| take 10

2. Correlate deletes with subsequent creates on the same path

Since Azure Files does not emit a distinct "permanent delete" event, the reliable way to identify files that stayed deleted is to join StorageDelete/Close events against any later StorageWrite/Create event on the same Uri within a reasonable window (adjust the window to match your application's write pattern):

let window = 1d;
let recreates = StorageFileLogs
| where TimeGenerated > ago(window)
| where Category == "StorageWrite" and OperationName == "Create"
| project Uri, CreateTime = TimeGenerated;
StorageFileLogs
| where TimeGenerated > ago(window)
| where Category == "StorageDelete" and OperationName == "Close" and SmbCommandMinor == "FileCloseAndDelete"
| project Uri, DeleteTime = TimeGenerated, CorrelationId
| join kind=leftouter recreates on Uri
| extend WasRecreated = isnotempty(CreateTime) and CreateTime > DeleteTime
| where WasRecreated == false
| project DeleteTime, Uri, CorrelationId
| order by DeleteTime desc

Anything left after this filter is a delete-on-close that had no matching create afterward inside your window, which is the closest practical definition of "permanently deleted" available from the log data.

3. Do not rely on file-level soft delete for this

Azure Files soft delete only protects the entire file share, not individual files or folders. If you want a point-in-time comparison as a secondary verification method, use scheduled share snapshots and diff snapshot contents against the live share, rather than expecting a built-in per-file recovery log.

4. Most cost-effective automation path

Since your data already lives in Log Analytics, the cheapest option is a native Log Analytics Scheduled Query Rule running the KQL above on a daily or weekly cadence, firing an action group (email or webhook) with the results. This avoids extra compute:

• Log Analytics scheduled query: lowest cost, no added compute, native to your existing workspace — recommended
• Azure Workbook: good for an interactive dashboard on top of the same query, minimal extra cost, but not ideal for automated report delivery
• Logic App: reasonable if you need to format results into email/Excel/Teams, adds Logic App consumption cost
• Azure Automation Runbook / Azure Function: only worth it if you need custom logic beyond what KQL can express; adds compute cost for little benefit here

For your scenario, a scheduled query rule (or a workbook if you just want to eyeball it) is the simplest and cheapest path.

If this answer helps you kindly accept the answer which will help others who have similar questions.

Best Regards,

Jerald Felix.