Why Does a NAS Share Show Old Files After the Folder Was Replaced?
A NAS share can show old files when the client or share service still points to cached directory state or the previous path.
Replacing a folder on the NAS does not guarantee that every SMB session, application, mount, reverse path, or namespace immediately switches to the new directory tree. The server may still export the old path, the replacement may have landed beneath a different mount, or the client may retain directory metadata, file information, open handles, or a cached referral. The safest diagnosis compares the filesystem view, the active share target, and a completely fresh client session before any cache setting is changed.
Confirm Which Layer Still Shows the Old Directory Tree
Compare the affected SMB client with the NAS shell, the NAS web file manager, and a second client that has not opened the share recently. Record one filename that should have disappeared and one new filename that should be visible.
If the NAS shell and web file manager also show the old tree, the problem is below SMB: the replacement happened in the wrong directory, an expected mount is missing, or another dataset is covering the path. IBM notes that SMB change notifications depend on how changes reach the file service, so one stale client does not by itself prove the server data is old.
Do not refresh the same file browser repeatedly and treat that as a new test. A meaningful comparison uses another client process, another user session, or a direct local filesystem view that does not reuse the same SMB metadata.
Verify the Active Share Target After the Folder Replacement
Inspect the server’s share configuration and resolve the exported path to its real filesystem object. Check bind mounts, symbolic links, dataset mountpoints, container volume mappings, and whether the replacement folder was created before or after a storage mount became active.
A common failure occurs when the administrator replaces files under an unmounted directory, then the real storage mount returns and hides that replacement. The Linux mount manual explains that mounting hides the previous directory view while the filesystem remains attached, which is why the visible path must be checked against the active mount table.
The ZimaSpace NAS data migration guide provides the adjacent verification sequence for proving that the intended source and destination paths contain the expected data before the old copy is removed.
Test SMB Directory and File Information Caches
Close every application using the share, disconnect the SMB mapping, and establish a new session. Compare the result with a second computer or a new user session that has not enumerated the directory before.
Windows SMB clients can cache directory metadata and file information for a configured lifetime. Microsoft’s file-server tuning guidance explains that directory cache lifetime controls how long metadata may remain cached when directory leases are not available.
If a fresh session immediately shows the correct tree while the old session does not, the data is not missing and the share target is probably correct. Reconnect the affected client cleanly and investigate why its session did not receive or honor the expected change notification before changing cache values globally.
Check Open Handles, Leases, and Long-Lived Applications
List active SMB sessions and open files on the NAS. Media managers, photo apps, backup tools, shell windows, indexers, and file browsers can keep directories or files open long after the visible copy operation finishes.
Close the application first, then disconnect only the affected SMB session. NetApp’s SMB documentation explains that lease oplocks preserve client cache state, so disabling leases across the entire NAS is a much larger change than resetting one stale connection.
If the old tree disappears only after a specific application closes, preserve that result and test the application again with the new folder. The corrective action belongs in its reconnect, watch, or refresh behavior rather than in the storage pool.
Rule Out DFS Referrals and Duplicate Server Names
Check whether the client reached the NAS through a direct hostname, an IP address, a DNS alias, a DFS namespace, or an old server name that now resolves elsewhere. Two paths that look similar in the file browser may terminate at different share targets.
DFS clients cache namespace and folder referrals for a defined period. DFS clients can also retain namespace and folder referrals for a period, which can temporarily send a client to an older target after a namespace change.
Compare the server identity, resolved address, share name, and final path for the working and stale sessions. Do not flush every DNS and DFS cache until you have proved that the affected client is reaching a different target.
Compare a Fresh Direct Path With the Normal User Path
Open the share once by the normal hostname and once by the verified direct server address from a clean client session. Use this only as a discriminator, not as a permanent replacement for a managed hostname.
If the direct path shows the new tree while the normal name shows the old one, focus on aliases, referrals, saved credentials, or a second NAS using the same name. Debian’s mount.cifs path model shows why the exact server/share target and local mountpoint must be compared rather than relying on a familiar display name.
Also compare the file count and one file hash from the local NAS path and the SMB path. A matching old file confirms path or cache selection; a different file with the same name points toward incomplete replacement, duplicate folders, or application-generated content.
Repair the Smallest Fault and Verify It Survives Reboot
Correct the share target when it exports the wrong folder, restore the missing mount when the path is covered incorrectly, reconnect the stale client session when only one client is affected, or update the DFS target when the namespace still references the old location.
Avoid changing SMB cache lifetimes, disabling leases, or recreating the share unless a controlled test proves that layer is responsible. Samba’s active session and lock view supports checking the affected connection before applying a server-wide change.
The issue is resolved when the NAS shell, web file manager, fresh SMB session, and normal client path all show the same folder contents after service restart and host reboot. Keep the old folder offline but intact until that verification passes and no application continues writing to it.
Recommended products
Support & Tips
More to Read
Why Does a Docker Volume Restore Recreate File Contents but Drop Extended Attributes?
A volume-restore diagnosis covering xattr inventory, tar and Rsync options, namespaces, destination support, privileges, labels, app metadata, and tests.
Why Does a Running Container Keep Its Old Memory Limit After the Compose File Changes?
A memory-limit diagnosis covering live cgroups, restart versus recreation, Compose fields, hard and soft limits, parent scopes, swap, and runtime heaps.
Why Does Restarting a Reverse Proxy Invalidate Every Session for One Self-Hosted App?
A session-loss diagnosis covering restart scope, cookie ownership, secret rotation, cache-backed sessions, sticky routing, auth gateways, and recovery.
