# File Share Auditing: Find Who Deleted a File in 5 Steps

Source: https://srvscripts.com/guides/file-share-auditing-who-deleted-file/
Updated: 2026-10-03
Publisher: srvScripts (https://srvscripts.com/)

File share auditing on Windows Server records who opened, changed or deleted files on a share, but only if two things are in place before the incident: the **Audit File System** policy and an auditing entry (SACL) on the folder. This guide sets both up on Windows Server 2025 and 2022, explains which events prove a deletion (4663 with the DELETE access mask, 4660 and 5145), gives a PowerShell script that finds the user and source IP, and shows how to get the file back.

**Short answer:** Enable `Advanced Audit Policy Configuration » Object Access » Audit File System` (Success) in a GPO for the file servers. On the share’s root folder, open **Properties » Security » Advanced » Auditing** and add Everyone, type Success, with **Delete** and **Delete subfolders and files**. From then on, each deletion writes Security event **4663** with Access Mask `0x10000`, showing the account and the full path. Restore the file itself from Previous Versions or backup.

In short: Enable Advanced Audit Policy Configuration » Object Access » Audit File System (Success) in a GPO for the file servers.

## How Windows records a deletion

Deleting a file over SMB produces a chain of events. File share auditing works best when you know which one to search for and how they link.

| Event | Subcategory | Meaning | Useful fields |
| --- | --- | --- | --- |
| 4656 | Audit File System | A handle to an object was requested (with DELETE access) | ObjectName, HandleId, AccessMask |
| 4663 | Audit File System | An attempt was made to access an object: the DELETE right was used | SubjectUserName, SubjectLogonId, ObjectName, AccessMask 0x10000, HandleId |
| 4660 | Audit File System | An object was deleted | SubjectUserName, HandleId (no file name) |
| 4658 | Audit Handle Manipulation | The handle to an object was closed | HandleId |
| 5145 | Audit Detailed File Share | A network share object was checked to see whether the client can be granted desired access | ShareName, RelativeTargetName, IpAddress, AccessMask |
| 4670 | Audit File System | Permissions on an object were changed | ObjectName, old and new security descriptor |

Key points from Microsoft’s event documentation:

- **4663** shows that a right was actually used, and it includes the file name. It is the main event for “who deleted”. It is also written when a file is renamed or moved, because those operations use the DELETE right too.

- **4660** is written only for real deletions but carries no file name. Link it to the 4663 with the same `HandleId` to confirm a delete rather than a rename.

- **5145** adds the client IP address, but it is very noisy and does not need a SACL: it logs every access to every share on the server.

## Which method to use

| Method | Answers | Volume | Notes |
| --- | --- | --- | --- |
| Audit File System + delete SACL | Who deleted, renamed or moved which file, and when | Low to medium | Recommended baseline |
| Audit Detailed File Share (5145) | Every access with client IP | High on file servers | Enable Failure only, or Success for short investigations |
| Global Object Access Auditing | Same as SACLs, applied to every file on the server | Can be very high | Useful when you cannot edit folder SACLs; scope rights carefully |
| File Server Resource Manager | Quotas, file screens, storage reports | None | Does not record who deleted a file |
| Previous Versions (shadow copies) and backup | Gets the file back | None | Does not tell you who deleted it |

## Prerequisites

- A domain-joined Windows Server 2025, 2022 or 2019 file server with NTFS or ReFS volumes.

- Rights to edit GPOs linked to the file server OU, and local administrator rights on the server to change SACLs (this needs the Manage auditing and security log right, which Administrators hold).

- Enough space for a larger Security log, or an event collector or SIEM.

- Well-structured share and NTFS permissions, so audit entries match the people who can actually delete.

## Step 1: Enable the audit policy

- In **Group Policy Management**, create a GPO linked to the OU holding the file servers, for example SRV – File Server Auditing.

- Go to `Computer Configuration » Policies » Windows Settings » Security Settings » Advanced Audit Policy Configuration » Audit Policies » Object Access`.

- Configure **Audit File System** for **Success**. Add Failure if you also want denied attempts on audited folders.

- Optionally configure **Audit Detailed File Share** for **Failure**. Success here logs every file access on every share; turn it on only for a limited investigation.

- Leave **Audit Handle Manipulation** off. It only adds handle-close (4658) and duplicate events, which Microsoft describes as of little security value and high volume.

- Under `Security Settings » Local Policies » Security Options`, enable **“Audit: Force audit policy subcategory settings (Windows Vista or later) to override audit policy category settings”**.

Apply and check on the server:

```
gpupdate /force
auditpol /get /subcategory:"File System","Detailed File Share","Handle Manipulation"
```

The output should show File System: Success. The audit policy on its own logs nothing for files: Windows writes file system events only for objects whose SACL matches the access.

## Step 2: Add a SACL to the shared folder

### In the GUI

- On the file server, open the share’s root folder (for example `D:\Shares\Finance`) and choose **Properties » Security » Advanced**.

- Select the **Auditing** tab and click **Continue** if prompted, then **Add**.

- Click **Select a principal** and enter Everyone (or Authenticated Users).

- Set **Type** to Success and **Applies to** to This folder, subfolders and files.

- Click **Show advanced permissions**, clear everything, then tick **Delete** and **Delete subfolders and files**. Tick **Change permissions** and **Take ownership** as well if you want permission changes (4670).

- Click **OK** on each dialog. Windows applies the entry to every existing file, which can take a while on large folders.

### With PowerShell

The same SACL, applied from an elevated session. `Get-Acl -Audit` reads the existing audit rules so they are kept:

```
$path = "D:\Shares\Finance"
$acl  = Get-Acl -Path $path -Audit
$rule = New-Object System.Security.AccessControl.FileSystemAuditRule("Everyone", "Delete, DeleteSubdirectoriesAndFiles", "ContainerInherit, ObjectInherit", "None", "Success")
$acl.AddAuditRule($rule)
Set-Acl -Path $path -AclObject $acl
(Get-Acl -Path $path -Audit).Audit | Format-Table IdentityReference, FileSystemRights, AuditFlags, InheritanceFlags -AutoSize
```

Loop over the root folder of each share to cover a whole server. Folders that have inheritance disabled deeper in the tree keep their own SACL, so check them separately.

### Global Object Access Auditing

If you cannot edit SACLs folder by folder, define one for the whole server in the same GPO: `Advanced Audit Policy Configuration » Audit Policies » Global Object Access Auditing » File system`. Click **Configure**, add Everyone with Success for Delete only. It applies to every file on every local volume, including system files, so keep the rights narrow.

## Decide what to audit

File share auditing works best when it is scoped to the questions you actually get. Most service desks hear “who deleted this?” and “who changed the permissions?”, so a baseline of delete, change permissions and take ownership on every share root covers the common cases. Add more only for specific folders:

| Question | SACL rights | Where |
| --- | --- | --- |
| Who deleted, renamed or moved a file? | Delete, Delete subfolders and files | Every share root |
| Who changed permissions or ownership? | Change permissions, Take ownership | Every share root |
| Who changed a sensitive document? | Create files / write data, Write attributes | Only folders such as HR or Payroll |
| Who opened a sensitive document? | List folder / read data | Only when compliance requires it; very high volume |
| Who tried and failed? | Same rights, type Fail | Sensitive folders |

Write down the scope in your file share auditing standard, including which GPO enables the policy and which folders carry extra SACL entries, so the next admin knows where the evidence comes from.

## Step 3: Read the events for a deletion

With file share auditing active, delete a test file from a client and open **Event Viewer » Windows Logs » Security** on the file server. Filter for 4663 and look for:

- **Subject » Account Name**: the user who deleted the file.

- **Object » Object Name**: the full local path, for example `D:\Shares\Finance\Budget 2026.xlsx`.

- **Access Request Information » Accesses**: DELETE, and **Access Mask** `0x10000`.

- **Process Information » Process Name**: for access over the share this is the System process (the SMB server). A local process name such as `explorer.exe` means the file was deleted on the server itself, for example over RDP.

A 4660 with the same Handle ID a moment later confirms the file was deleted rather than renamed. If only 4663 exists, check whether the file now exists under a new name or in another folder.

Files deleted over a network share do not go to the user’s Recycle Bin, so the deletion is final from the user’s point of view.

## Step 4: Search with PowerShell

This script lists every DELETE access in the last two days, optionally filtered by file name, and adds the source IP from the matching network logon (event 4624, matched on the logon ID).

```
$hours = 48
$name  = "Budget"
$ms    = $hours * 3600 * 1000
$xpath = "*[System[(EventID=4663) and TimeCreated[timediff(@SystemTime)