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

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.

Applies to Windows Server 2019, 2022 and 2025 file servers (NTFS or ReFS)

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.

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

1. In Group Policy Management, create a GPO linked to the OU holding the file servers, for example SRV – File Server Auditing.
2. Go to Computer Configuration » Policies » Windows Settings » Security Settings » Advanced Audit Policy Configuration » Audit Policies » Object Access.
3. Configure Audit File System for Success. Add Failure if you also want denied attempts on audited folders.
4. 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.
5. 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.
6. 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

1. On the file server, open the share’s root folder (for example D:\Shares\Finance) and choose Properties » Security » Advanced.
2. Select the Auditing tab and click Continue if prompted, then Add.
3. Click Select a principal and enter Everyone (or Authenticated Users).
4. Set Type to Success and Applies to to This folder, subfolders and files.
5. 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).
6. 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) <= $ms]]] and *[EventData[Data[@Name='AccessMask']='0x10000']]"
$events = Get-WinEvent -LogName Security -FilterXPath $xpath -ErrorAction SilentlyContinue
$result = foreach ($e in $events) {
  $x = [xml]$e.ToXml(); $d = @{}
  foreach ($n in $x.Event.EventData.Data) { $d[$n.Name] = $n.'#text' }
  if ($d.ObjectName -notlike "*$name*") { continue }
  $lx = "*[System[(EventID=4624)]] and *[EventData[Data[@Name='TargetLogonId']='$($d.SubjectLogonId)']]"
  $logon = Get-WinEvent -LogName Security -FilterXPath $lx -MaxEvents 1 -ErrorAction SilentlyContinue
  $ip = if ($logon) { ([xml]$logon.ToXml()).Event.EventData.Data | Where-Object Name -eq 'IpAddress' | Select-Object -ExpandProperty '#text' } else { 'n/a' }
  [pscustomobject]@{ Time = $e.TimeCreated; User = "$($d.SubjectDomainName)\$($d.SubjectUserName)"; File = $d.ObjectName; Process = $d.ProcessName; SourceIP = $ip }
}
$result | Sort-Object Time | Format-Table -AutoSize
$result | Export-Csv C:\Temp\deleted-files.csv -NoTypeInformation

Notes on the script:

• Set $name = "" to list all deletions. On a busy server, narrow $hours first.
• The logon lookup finds the source IP only while the 4624 is still in the log; short-lived network logons are usually recent enough.
• To run it against a remote file server, add -ComputerName fs01 to both Get-WinEvent calls.
• If you enabled Audit Detailed File Share, 5145 events with the same RelativeTargetName also carry the client’s IP address.

Step 5: Size the log and plan retention

File share auditing is only useful if the event still exists when someone notices the file is gone, which is often days later.

• Set the Security log size in the same GPO: Computer Configuration » Policies » Administrative Templates » Windows Components » Event Log Service » Security » "Specify the maximum log file size (KB)". File servers commonly use 1 to 4 GB.
• To keep older events on disk, enable “Control Event Log behavior when the log file reaches its maximum size” together with “Back up log automatically when full” in the same node. Full logs are archived as Archive-Security-*.evtx files in %SystemRoot%\System32\winevt\Logs; plan disk space and cleanup for them.
• Better still, forward 4663, 4660 and 4670 to a collector or SIEM, where retention and search do not depend on the file server.

Performance

A file share auditing setup based on a delete-only SACL adds little load: events are written only when the DELETE right is used. Auditing read access or enabling Detailed File Share success on a busy server can generate thousands of events per minute, which fills the log quickly and costs CPU and disk I/O. Start with deletes and permission changes, measure the event rate for a week, and extend only where you have a clear need.

Get the file back: Previous Versions and backup

File share auditing tells you who; it does not restore anything. Shadow copies give users and the service desk a fast restore path.

1. On the file server, open the data volume’s Properties » Shadow Copies tab, select the volume and click Enable. The default schedule creates copies at 7:00 and 12:00 on weekdays; adjust it under Settings » Schedule. Store the shadow copies on a separate volume if possible.
2. To restore, open the parent folder over the share, choose Properties » Previous Versions, pick a version from before the deletion and click Open to copy the file out, or Restore to put the folder back.
3. List existing copies with vssadmin list shadows /for=D:.

Shadow copies live on the same server and are not a backup. Keep a real backup (Windows Server Backup, your backup product or a cloud service) for anything older than your shadow copy retention.

Alternatives and additions

• File Server Resource Manager (Install-WindowsFeature FS-Resource-Manager -IncludeManagementTools) adds quotas, file screens that block file types, and storage reports. It does not log deletions, but file screens are a useful early warning against ransomware file extensions.
• Third-party file auditing tools read the same events and present them in reports. They still need the audit policy and SACLs described here.

Troubleshooting

Symptom	Likely cause	Fix
No 4663 events after a test delete	No SACL on the folder, or the policy is not applied	Check (Get-Acl -Audit).Audit and auditpol /get /subcategory:"File System"
Policy shows “No Auditing” despite the GPO	Legacy “Audit object access” setting overrides subcategories	Enable the “Force audit policy subcategory settings” option
Thousands of 4663 events per hour	SACL audits read or write access, or Everyone with Full Control	Limit the SACL to Delete and Delete subfolders and files
4663 found, but file still exists elsewhere	The file was renamed or moved, which also uses DELETE	Look for a 4660 with the same Handle ID; search the share for the name
Event already overwritten	Security log too small	Increase the log size, archive or forward events

Test file share auditing on every file server after you set it up, and again after migrations or new shares: create, rename and delete a test file, and confirm your script finds each step.

File share auditing at a glance

Official documentation: Audit File System, 4663(S): An attempt was made to access an object, Audit Detailed File Share.

Related guides: File server share vs NTFS permissions and ABE · AD audit policy: logons, account changes, lockouts · DFS Namespaces and Replication: Reliable File Server Setup.

Frequently asked questions

Maintenance record

This guide changes servers, data or security settings, so we re-check it against current versions on a fixed schedule. Take a backup or snapshot before you start.

Maintained by

srvScripts editorial team

Supported versions

Windows Server 2019, 2022 and 2025 file servers (NTFS or ReFS)

Last full review

3 Oct 2026

Next review

1 Apr 2027

Sources

learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-10/security/threat-protection/auditing/audit-file-system
learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-10/security/threat-protection/auditing/event-4663
learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-10/security/threat-protection/auditing/audit-detailed-file-share