SMB folder looks stale over VPN? Check Offline Files

You connect the VPN, open the mapped drive, and the folder is missing a file the server clearly has. The instinct is to blame the tunnel, the DNS or Samba permissions. In many cases the connection is fine and Explorer is showing a cached copy of the share. Offline Files can serve that copy even while the VPN is up, because the share, not the tunnel, decides whether the view is live. The fix starts with proving which one you are looking at.

The myth: a VPN icon means the share is live

The VPN icon reports that a tunnel exists to the endpoint. It says nothing about whether a particular SMB share is reachable, whether Explorer has transitioned that share back to online mode, or whether a synchronization failure left an older copy in place. It also does not tell you which server a DFS path selected.

Offline Files keeps a local copy of redirected or pinned shares so they remain available when the server is unreachable. When the share returns, the client is supposed to switch back and synchronize. A slow-link policy can decide the connection is still too slow and keep the cached view, and a pending conflict can do the same even on a fast link.

That is why the symptom looks selective: one folder is stale, another opens correctly, and a third cannot open at all. Those are three different states, and only the first one is the cache story this article is about. Name the state before choosing a repair.

Prove which target Explorer is reading

Start with the exact UNC path rather than the drive letter. A mapped drive can point at a different share than the one you think, and a DFS path can refer to another server entirely. Reading the mapping shows the saved target and its status:

Get-SmbMapping | Select-Object LocalPath, RemotePath, Status
Get-SmbConnection
net use

Open the UNC path directly in a new Explorer window and compare it with the mapped drive. If the direct path shows the current file and the mapped drive does not, the mapping is part of the problem, not the cache.

Then confirm the file exists for the intended user. An administrator listing on the server proves existence, not that the ordinary SMB user has the same access, so check with the account that actually uses the share. Different credentials produce different views for reasons that have nothing to do with caching. Existence, access and visibility are three separate checks.

Read the sync state before clearing anything

Sync Center, where the feature is available, reports whether the share is working offline, whether the last synchronization failed and whether conflicts are waiting. Those three states lead to different repairs, and clearing the cache while a conflict is pending can discard local work.

Look for local edits that have not reached the server before you disable caching, unpin the share or delete the offline copy. A file that exists only in the cache is not a stale view; it is unsynchronized data, and it needs to be preserved through the approved process first. A cache with pending edits is not safe to delete.

Once the local work is safe, use the supported online transition and synchronization, then compare the listing again. Opening a second Explorer window does not force a refresh, because both windows can read the same local cache.

Repair the share state instead of deleting the feature

If the share stays offline because of slow-link policy, adjust the policy for that share or network rather than turning Offline Files off for every user. If synchronization keeps failing, fix the failure and resolve the conflicts; a working sync is what makes the cached copy current again. Change the smallest policy that covers the share. A global change trades one user's stale view for everyone's lost offline access.

For shares that should never be cached, the server can send a per-share hint. Samba exposes it as a share parameter, and the value for a share that must stay online-only is:

csc policy = disable

The Samba parameter reference defines the allowed values and their meaning. Apply the setting through the share manager that actually generates the configuration, especially on a NAS, and remember that the hint does not repair data already cached on a client.

After any policy change, verify that the client reconnects and that the expected file appears. A restarted service is not evidence that a pending local edit was uploaded, so check the file, not only the connection state.

When the cause is not Offline Files

If the UNC path is confirmed online and a fresh listing still differs, the cache is not the explanation. Check share and filesystem permissions, access-based enumeration and the server that a DFS referral actually selected. Each of those can hide a folder without any local copy being involved.

A share that never connects needs routing and service-filter evidence, not a cache check. Port 445 blocked over the tunnel, a DNS name resolving to the wrong address or a firewall rule that allows ping but not SMB all produce a failure before caching matters.

The test that separates the families is simple: a folder that exists on the server, is visible to the right user, and still does not appear online points at policy or enumeration; a folder that appears with old content points at the cache. Diagnose the family before changing a setting.