Fix 0X00000845: Invalid Op on Redirected Network Path

When you'll see this error

You're copying a large file to a mapped network drive, or maybe you're trying to delete a folder that's actually a junction point on a file server. Mid-operation, Windows throws 0X00000845 with the message "The operation is invalid on a redirected resource." The exact wording varies, but the code stays the same. I've seen this most often on Windows 10 and Windows Server 2016+ when someone maps a drive to a DFS (Distributed File System) namespace or a share that itself points to another share on the same machine. The trigger is usually a file operation that the redirector (the SMB client) can't handle locally — like renaming a file across the redirection boundary or using a local-only API on a path that's been redirected.

What's actually happening here

The error code 0X00000845 maps to NERR_RedirectedPath (error 2117 in the NETERR range). That's a network-specific error, not a generic Win32 one. The reason it appears is that the path you're operating on isn't a real local filesystem path — it's a redirected resource. In SMB terms, a redirect happens when a share on a server points to another share, or when you access a DFS link that resolves to a different server or path. Windows tries to be smart and cache metadata, but certain operations — like changing file attributes, using ReplaceFile, or doing a rename that crosses the redirection point — require a handle that the redirector can't provide. So the OS bails with this error instead of corrupting anything. It's not a permission problem, not a disk full problem. It's a design limitation in how the SMB redirector handles redirected paths.

Another common scenario: you're using a local admin tool (like an installer or a backup utility) that calls CreateFile with FILE_FLAG_BACKUP_SEMANTICS on a path that resolves to a redirected share. The redirector sees the flag and knows it can't honor it over the wire, so it returns this error.

How to fix it

The fix isn't a registry tweak or a service restart. It's about changing how you access the resource or what operation you're performing.

Stop using the mapped drive for the single failing operation. Try the same operation using the full UNC path (\\server\share\folder\file) instead of Z:\folder\file. This bypasses any local drive mapping weirdness and forces the redirector to handle the path directly. Often that's all you need.
If you're using DFS, connect to the actual server share instead of the DFS namespace. Find the real target with dfsutil diag or Get-SmbConnection in PowerShell. For example, if your mapped drive points to \\yourdomain\dfsroot\project, but the actual server is \\fileserver1\project, map a new drive directly to \\fileserver1\project. The DFS path adds a redirect layer, and some operations trip over it.
Check whether the destination share is itself a redirected folder. On the server, if the share points to a folder that's a junction or a symlink (e.g., C:\Shares\Public is a symbolic link to D:\Data\Public), then you're hitting a redirect at the server side. Change the share target to the real, final path. Log onto the server, open Computer Management, go to Shared Folders, and note the Path column. If it contains a junction, unshare and re-share the actual folder.
Run the operation from a local context. If you're trying to move files from a local drive to the network share, first copy to a temp folder on the server, then move it within the server's local filesystem. This avoids the redirector entirely for the final step.
If it's a backup or sync tool, exclude the redirected paths. Tools like Robocopy with the /B flag fail with this error because backup semantics aren't supported on redirected resources. Drop the /B flag and use /COPY:DAT instead, or map the drive with net use /user:... //server/share and use the UNC path in Robocopy without the mapped letter.

What to check if it still fails

If you've switched to a direct UNC path and the error persists, the problem might be deeper. First, verify you're actually hitting the expected server — a DNS or NetBIOS name might loop you back through a DFS referral. Use nslookup server and ping server to confirm the IP. If the server is a cluster or behind a load balancer, you might be redirected to a node where the share doesn't exist in the same way. In that case, the fix is to use a cluster role's network name instead of a node name.

Second, check the SMB dialect. Windows 10 and Server 2019 support SMB 3.1.1, but if you're connecting to an older server that's forced to SMB 1.0 (which you really shouldn't do anyway), redirected paths behave erratically. Disable SMB1 on the server via Disable-WindowsOptionalFeature -Online -FeatureName SMB1Protocol and reboot. That clears up a bunch of weird errors, including this one in some cases.

Last, test with a different client. If the operation works from another machine, the problem is local to your client's SMB redirector stack. Reset the network stack with netsh winsock reset and netsh int ip reset, then reboot. It's rare, but a corrupted LSP (Layered Service Provider) can break path resolution and cause this exact error on a single machine.

In my experience, step 1 and step 3 fix 90% of these. The rest are server-side misconfigurations or legacy SMB remnants. Skip the registry hacks — they don't apply here.