Network folder refresh problems are one of the most common complaints in Windows file-sharing environments. When someone creates, renames, or deletes a file on an SMB share, the change may not show up in another user's File Explorer for several seconds or even minutes, even though the file is fully accessible through its direct UNC path. The cause is almost always caching: the SMB client keeps a short-lived cache of directory listings and file metadata to cut network round-trips, and the Windows Offline Files feature can keep its own local copy of a share's contents. This guide walks through the verified fixes in order of impact, starting with disabling the SMB client metadata cache, then addressing Offline Files on the share and on the client. Each method targets a specific caching layer, so you can apply only what your environment needs rather than turning everything off at once.
Before you start
What you will learn
- How to stop network shared folders from showing stale contents by disabling SMB client-side metadata caching and Offline Files, using PowerShell, the registry, and Group Policy.
- When new, renamed, or deleted files do not appear promptly in File Explorer, users assume data is missing or duplicate work, which erodes trust in shared drives and disrupts collaboration.
Requirements
- You need an elevated (Administrator) session on the affected client computer, and, for the share-side steps, administrative access to the file server hosting the SMB share. The Group Policy method additionally requires rights to edit a GPO that targets the affected computers.
- Windows 10 or Windows 11 clients connecting to an SMB share hosted on Windows Server 2019/2022/2025 or a compatible NAS. PowerShell 5.1 or later with the built-in SmbShare module.
- Local Administrator on the client computer
- Administrator on the file server
- Group Policy edit rights (domain-wide method only)
Good to know
- The core PowerShell fix takes about two minutes; server-side and Group Policy steps take longer.
- Verified against current Microsoft Learn SMB documentation, July 2026.
Quick answer
The fastest fix is to disable the SMB client's metadata cache. In an elevated PowerShell window, set the three cache lifetimes to zero and restart the Workstation service. If files are still stale, the share is caching offline copies, so set the share's caching mode to None on the server and turn off Offline Files on the client.
PowerShell (Admin) > Set-SmbClientConfigurationSet-SmbClientConfiguration -DirectoryCacheLifetime 0 -FileInfoCacheLifetime 0 -FileNotFoundCacheLifetime 0 -Confirm:$falseStep-by-step tutorial
5 stepsConfirm the problem is caching, not permissions or replication
Rule out other causes before changing anything, so you apply the right fix.
Start > Terminal (Admin)Open an elevated PowerShell window (right-click Start and choose Terminal (Admin) or Windows PowerShell (Admin)). First confirm the file really exists on the server by opening it through its full UNC path, for example \\FileServer\Share\newfile.txt, even though it is not visible in the folder view. Then read the current SMB client cache settings:
If the file opens by UNC path but does not appear in the folder listing, and the cache lifetimes are non-zero, caching is the cause. If the file cannot be opened by UNC path at all, stop: the issue is permissions, replication (DFS), or connectivity, not caching, and the rest of this guide will not help.
Get-SmbClientConfiguration | Select-Object DirectoryCacheLifetime, FileInfoCacheLifetime, FileNotFoundCacheLifetimeThe exact default lifetimes differ between Windows builds, so record whatever values your machine reports before changing them. This step changes nothing, so it is safe to run on production machines.
Disable SMB client metadata caching with PowerShell
Force the SMB client to stop holding stale directory and file metadata.
PowerShell (Admin)In the same elevated PowerShell window, set the three client-side cache lifetimes to zero:
Then restart the Workstation service so the change takes effect without a reboot:
Finally, confirm the new values are in place. This is the primary fix for immediate refresh problems and resolves most cases on its own.
Set-SmbClientConfiguration -DirectoryCacheLifetime 0 -FileInfoCacheLifetime 0 -FileNotFoundCacheLifetime 0 -Confirm:$false
Restart-Service -Name lanmanworkstation -Force
Get-SmbClientConfiguration | Select-Object DirectoryCacheLifetime, FileInfoCacheLifetime, FileNotFoundCacheLifetimeRestarting lanmanworkstation may briefly drop mapped drives; save open work on network files first. -Confirm:$false suppresses the per-property confirmation prompt. These are client-side settings and take effect only on the machine where you run them.
Apply the same cache settings in the registry (for GPO or legacy clients)
Persist the cache-disable values where PowerShell is not available or when deploying by Group Policy Preferences.
regedit > HKLM\SYSTEM\CurrentControlSet\Services\LanmanWorkstation\ParametersThe cmdlet in the previous step writes to the registry under the client service key, LanmanWorkstation, not the server key. If you prefer to set the values directly (for older clients without the cmdlet, or to package them for Group Policy Preferences), create three DWORD values under:
HKLM\SYSTEM\CurrentControlSet\Services\LanmanWorkstation\Parameters
Add DirectoryCacheLifetime, FileInfoCacheLifetime, and FileNotFoundCacheLifetime as REG_DWORD and set each to 0, then reboot. You can do this from PowerShell as well:
$p = 'HKLM:\SYSTEM\CurrentControlSet\Services\LanmanWorkstation\Parameters'
New-ItemProperty -Path $p -Name DirectoryCacheLifetime -Value 0 -PropertyType DWORD -Force | Out-Null
New-ItemProperty -Path $p -Name FileInfoCacheLifetime -Value 0 -PropertyType DWORD -Force | Out-Null
New-ItemProperty -Path $p -Name FileNotFoundCacheLifetime -Value 0 -PropertyType DWORD -Force | Out-NullThis is the key correction to watch for: the cache-lifetime values belong under LanmanWorkstation (the SMB client / Workstation service). The LanmanServer key is the SMB Server service and setting these values there has no effect on client-side refresh. Registry edits require a reboot to apply reliably.
Turn off Offline Files on the client (Sync Center or Group Policy)
Remove the client-side Offline Files cache so File Explorer always reads live folder contents.
Computer Configuration > Policies > Administrative Templates > Network > Offline FilesFor a single machine, open Control Panel > Sync Center > Manage offline files, click Disable offline files, and reboot when prompted.
For multiple computers in a domain, use Group Policy: in the Group Policy Management Console, edit a GPO linked to the target computers and go to Computer Configuration > Policies > Administrative Templates > Network > Offline Files, then enable Allow or Disallow use of the Offline Files feature and set it to Disabled. Run gpupdate /force on a test machine and reboot.
As a scripted alternative on a standalone client, you can set the Offline Files (CSC) service start type to disabled, then reboot:
Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\CSC" -Name "Start" -Value 4Start value 4 sets the CSC (Offline Files) driver to Disabled; a reboot is required. Prefer the Sync Center or Group Policy method where possible, and reserve the registry edit for standalone machines. Disabling Offline Files removes offline access for laptops that legitimately use it.
How to Confirm Network Folders Now Refresh Instantly
To verify the fix, create or delete a file on the share from a different computer, then switch to the affected client, open the same folder, and press F5. The change should appear immediately with no delay. Re-run Get-SmbClientConfiguration | Select-Object DirectoryCacheLifetime, FileInfoCacheLifetime, FileNotFoundCacheLifetime and confirm all three values are 0. On the server, Get-SmbShare -Name "YourShareName" | Format-List CachingMode should report None. Test several operations in a row (create, rename, delete) from a second machine to be sure the behaviour is consistent, not just a one-off cache expiry that happened to line up.
- Cache lifetimes read 0, the share's CachingMode is None, and new, renamed, and deleted files appear in File Explorer immediately on F5 from every affected client.
- If files are still delayed after all three cache values are 0 and the share caching is None, another layer is involved: Offline Files may still be enabled on the client, a Group Policy Preference may be re-pushing the old values on each refresh, or you may be hitting the Windows 11 25H2 enumeration regression covered in troubleshooting.
- Directory listing cache disabled; the client re-reads the folder on every access.
- Negative cache disabled, so deleted files stop lingering in the listing.
- The share no longer allows clients to keep offline copies of its contents.
Troubleshooting
Files are still delayed after setting all three cache lifetimes to 0
Cause: The delay is coming from Offline Files rather than the metadata cache, either on the share or on the client.
Set the share's caching mode to None on the server with Set-SmbShare -Name "Share" -CachingMode None -Force, and disable Offline Files on the client through Sync Center or Group Policy. Reboot the client and re-test with F5.
Network drives become inaccessible after a registry change
Cause: The cache values were added under the wrong key (for example LanmanServer instead of LanmanWorkstation), or a value was created with the wrong type.
Confirm the DWORDs are under HKLM\SYSTEM\CurrentControlSet\Services\LanmanWorkstation\Parameters. If they are elsewhere, delete them there. If shares are still broken, remove the values you added and reboot, or run Reset-SmbClientConfiguration -Force to restore defaults, then re-apply via PowerShell.
On Windows 11 25H2, cache tuning has no effect and directory listings are slow
Cause: A known SMB directory-enumeration regression in Windows 11 25H2 causes the redirector to bypass the metadata cache at the driver layer, so the registry and cmdlet values are effectively ignored.
As a workaround until Microsoft ships a cumulative-update fix, keep affected workstations on 23H2, or mirror the heavily enumerated directory to local storage with Robocopy in a startup script and point the workload at the local copy. Open a Microsoft support case with SMB traces so the behaviour is tracked. Check for a newer cumulative update before assuming the values are wrong.
Settings revert after a reboot or every few minutes
Cause: A Group Policy Preference or Administrative Template is re-pushing the old cache or Offline Files values on each policy refresh.
Run gpresult /h report.html to find which GPO sets the values, then update or remove that policy so it matches the intended configuration. Run gpupdate /force and reboot to confirm the correct values persist.
Deleted files keep appearing in the folder listing for a while
Cause: The negative (file-not-found) cache is still active because only DirectoryCacheLifetime and FileInfoCacheLifetime were set to 0.
Set FileNotFoundCacheLifetime to 0 as well with Set-SmbClientConfiguration -FileNotFoundCacheLifetime 0 -Confirm:$false, restart the Workstation service, and re-test deleting a file from another machine.
Frequently asked questions
Why do new files take several seconds or minutes to appear in a network folder?
The SMB client caches directory listings and file metadata for a short period to reduce network traffic, and the Offline Files feature can keep a separate local copy. The file exists and opens by its full UNC path, but it does not show in the folder view until the cache expires or you disable it.
Does disabling SMB caching slow down the network?
Setting cache lifetimes to 0 makes the client query the server on every directory operation, so traffic increases slightly. On a modern LAN the impact is usually negligible; over slow or high-latency links, use a low value such as 1 to 2 seconds instead of 0.
What is the difference between client-side and share (server-side) caching?
Client-side caching is the SMB client's metadata cache (DirectoryCacheLifetime, FileInfoCacheLifetime) and the Offline Files feature on each workstation. Share-side caching is the share's CachingMode on the server, which decides whether clients may keep offline copies. Both can cause stale listings, and client-side caching is the more common culprit.
Which registry key controls these SMB cache settings?
They live under HKLM\SYSTEM\CurrentControlSet\Services\LanmanWorkstation\Parameters, the SMB client (Workstation) service. They do not belong under LanmanServer, which is the SMB Server service and does not control client-side folder refresh.
Can I roll this out to many computers with Group Policy?
Yes. Deploy the LanmanWorkstation\Parameters DWORD values as a Group Policy Preferences registry item, and control Offline Files through Computer Configuration > Administrative Templates > Network > Offline Files. Apply to a pilot OU first, then expand.
Do I need to reboot for the change to take effect?
For the PowerShell cmdlet, restarting the lanmanworkstation service is usually enough. Direct registry edits and disabling the Offline Files (CSC) service require a full reboot to apply reliably.
