Fix ERROR_NOT_SAME_DEVICE (0x11) on Windows

When does this error show up?

You're dragging a folder from your C: drive to an external USB drive—maybe a Seagate Backup Plus or a SanDisk SSD. Suddenly, Windows throws ERROR_NOT_SAME_DEVICE (0x00000011): "The system cannot move the file to a different disk drive." I've seen this most often when people try to move (cut+paste) a large project folder or an entire user profile between internal and external drives. The error is infuriating because the same drag operation works fine within the same drive.

What's really going on?

Under the hood, Windows treats file moves within a single drive as a metadata update—the file's data stays put, just the directory entry changes. Across drives, a move requires an actual copy-then-delete sequence. Some apps (and even File Explorer itself) try to short-circuit this by calling MoveFile with the wrong flags. The result? That 0x00000011 error. Bottom line: the OS is telling you "I can't safely rename this across volumes, so I'm stopping."

Fix it: two reliable methods

Method 1: Copy, then delete (the no-brainer)

Open File Explorer to both the source and destination drives.
Select the file or folder on the source drive.
Press Ctrl+C to copy (don't cut).
Navigate to the destination drive and press Ctrl+V to paste.
Once copied successfully, go back to the source and delete it manually (Shift+Delete for permanent removal).

This avoids the move operation entirely. Yes, it's two steps. But it never triggers that error.

Method 2: Robocopy (best for bulk moves)

If you're moving hundreds of files or an entire folder tree, Robocopy is faster and handles errors gracefully. Here's the command:

robocopy C:\source\folder D:\destination\folder /MOVE /E

Breakdown:

/MOVE — moves files and deletes them from the source after copying.
/E — includes subdirectories, even empty ones.

Run this from an elevated Command Prompt (right-click Start > Command Prompt (Admin)). Robocopy will log any failures, and it won't choke on the cross-device issue.

What if it still fails?

Three things to check:

Drive is full? If the destination doesn't have enough free space, moves may abort. Right-click the destination drive and check Properties.
File in use? Any locked file (like an open document or a system file) will block the move. Use Sysinternals Handle or locksmith to find what's holding it.
Permissions? Make sure your user has write access to both drives. On external drives formatted as exFAT or FAT32, permissions are usually wide open. On NTFS, right-click the destination folder > Properties > Security tab.

If none of that helps, reboot and try again. Windows sometimes holds stale locks that a restart clears.

That error tripped me up the first time too. Now you know the workaround—copy first, then delete. Or just let Robocopy handle the heavy lifting.