Fix 0X0000094C Error: Source Path Cannot Be a Directory

What's This Error About?

I know this error is infuriating — you're trying to copy something, and Windows says The source path cannot be a NERR_SourceIsDir directory with code 0X0000094C. It usually happens when you're using robocopy, xcopy, or even dragging a folder to a network share that expects a single file. The system thinks you're handing it a directory but it wants a file. Here's the fix.

Fix 1: The 30-Second Fix — Check Your Syntax

Most of the time, this error is a typo or a misunderstanding of how the command works. Let me guess: you ran something like:

robocopy C:\Users\You\Documents \\Server\Share\file.txt

That's the problem. Robocopy expects the source and destination to be folders, not files. The error 0X0000094C fires because you gave it a file path on the destination side. The real fix: make sure both source and destination are directory paths.

Do this instead:

robocopy C:\Users\You\Documents \\Server\Share\Documents

If you only want to copy a single file into a folder, use copy or xcopy with the file:

copy C:\Users\You\Documents\report.txt \\Server\Share

That's it. I've seen this trip up people who are used to Linux cp — different syntax. Check your command and retry. If that doesn't fix it, move on.

Fix 2: The 5-Minute Fix — Use xcopy with /I or /E

If the first fix didn't work, you might need to force the copy to treat the source as a directory. xcopy is more forgiving than robocopy in this case. Run:

xcopy C:\Users\You\Documents \\Server\Share /E /I

The /I flag tells xcopy that the destination is a directory (even if it doesn't exist yet). The /E copies all subdirectories, including empty ones. If you don't want empty dirs, use /S instead.

Real-world trigger: I had a user who got this error trying to back up their project folder to a NAS. They used robocopy C:\Project \\NAS\Backup and got 0X0000094C. The NAS share didn't have a Backup folder yet. Adding /I to xcopy solved it instantly.

If xcopy still throws the error, check if the destination path has a trailing backslash — that can confuse old commands. Use:

xcopy C:\Users\You\Documents \\Server\Share\ /E /I

Note the trailing backslash on the destination. That's a subtle trick that matters more than you'd think.

Fix 3: The 15+ Minute Fix — Registry or Network Share Permissions

If you're still stuck, this error can be caused by a misconfigured network share or a corrupted registry entry. This is rare but happens when the share itself is set to reject directory creation.

Step 1: Check Share Permissions

On the server hosting the share, open Computer Management → Shared Folders → Shares. Right-click your share and go to Properties. Under Share Permissions, make sure Everyone (or the relevant user) has Change and Read permissions. If it's read-only, you can't create subdirectories.

Also check Security (NTFS permissions) on the actual folder. The user needs Write and Modify permissions. A common mistake: share permissions are wide open, but NTFS permissions lock you down.

Step 2: Registry Fix (If You're Brave)

In some older Windows 10 builds (pre-20H2), a bug in the LanmanWorkstation service could cause this error. The fix is a registry tweak:

1. Press Win + R, type regedit, hit Enter.
2. Navigate to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanWorkstation\Parameters
3. Look for RequireSecuritySignature. If it's set to 1, change it to 0.
4. Also check EnablePlainTextPassword — set it to 1 if it doesn't exist (create a DWORD).
5. Reboot the machine.

Warning: Lowering security signature requirements is a tradeoff. Only do this on a trusted network. I had to use this fix on a customer's Windows 10 1809 machine that refused to copy folders to an old NAS.

Step 3: Use PowerShell as a Last Resort

If all else fails, bypass the error entirely with PowerShell's Copy-Item:

Copy-Item -Path "C:\Users\You\Documents" -Destination "\\Server\Share\Documents" -Recurse

PowerShell handles directories and files more intuitively than cmd. The -Recurse flag copies everything. If this works, the issue is with your old-school command syntax, not your system. But if it fails, check the share permissions again — you've got a network or permission issue.

When to Give Up and Reboot

If none of these work, reboot both machines (source and target). I've seen network caching cause phantom directory errors. A reboot flushes the SMB cache. If it's still broken, the share itself might be corrupted — create a new share on the server side and try again.

You got this. The fix is usually fix #1 or #2. Don't overthink it.