Moving Files NTFS Permissions: What Changes and Why

When a file or folder is moved within the same NTFS volume, its permissions (the ACL) travel with it unchanged. When a file is copied, or moved to a different volume, it inherits permissions from the destination folder. That single rule explains most cases of “permissions mysteriously changed” after a move. The symptom is usually an access denied error on a file that was accessible before, or a file that suddenly grants access to users it should not. The fix depends on which of the two operations actually happened, so the first step is to determine whether the file was copied or moved, and whether the destination is on the same volume.

How NTFS permissions are evaluated

Before changing anything, understand how Windows decides whether a user can access a file. The effective permission is the sum of all Allow entries minus all Deny entries in the file’s ACL, evaluated against the user’s group memberships. Deny entries override Allow entries. If a file has no explicit ACL, it inherits from its parent folder. When a file is copied or moved across volumes, it gets a fresh ACL from the destination folder’s inheritance. When moved within the same volume, the ACL is untouched.

This is why moving a file from C:\Users\alice\Documents to C:\Users\bob\Shared on the same drive keeps Alice’s permissions, and Bob’s users may not get access. Conversely, moving the same file to a different drive (say D:\Backup) makes it inherit from D:\Backup, which may grant Everyone full control or restrict to Administrators, depending on that folder’s settings.

The rule: copy vs move

Note: A “move” performed by dragging from one folder to another on the same drive is a true move. Dragging to a different drive performs a copy, then deletes the source. The same applies to cut-and-paste across drives. Always check whether the source still exists.

Diagnose what happened

First, confirm the operation. If the original file is still present, it was a copy. If it is gone, it was a move. Then check the destination volume: open File Explorer, right-click the destination folder, select Properties, and look at the drive letter. If the drive letter is the same as the source, it is the same volume. If different, it is cross-volume.

Next, inspect the actual ACL on the file. Open an elevated Command Prompt (Run as administrator) and use icacls to list permissions:

icacls "C:\path\to\file.txt"

The output shows the ACL entries. If the file has no explicit entries and inherits from the parent, you will see (I) markers. If it has explicit entries, they are listed without (I). Compare this to the source file’s ACL if it still exists.

If the file is on a FAT32 or exFAT volume, icacls will report that the file system does not support permissions. In that case, the fix is to move the file to an NTFS volume.

Fix: restore intended permissions

The repair depends on what you want the file’s permissions to be. There are two common scenarios: the file lost permissions it should have, or it gained permissions it should not have.

Scenario A: File lost permissions (access denied)

If the file was copied or moved across volumes and now denies access, the intended permissions are likely those of the source folder. To restore them, copy the file back to the source folder, then move it again using a method that preserves permissions. The only built-in way to preserve permissions during a copy or cross-volume move is to use robocopy with the /COPYALL flag, which copies the ACL along with the data. This is not a move; it copies the file and its permissions to the destination, and you can then delete the source manually.

robocopy "C:\source" "D:\destination" "file.txt" /COPYALL

This command copies file.txt from C:\source to D:\destination, including all file information (permissions, timestamps, owner). After confirming the copy is correct, delete the source file. If the destination already has a file with the same name, robocopy will overwrite it; use /XO to skip if the destination is newer, or /XN to skip if older. The output shows a summary: Files : 1 means one file copied, Dirs : 0 means no directories. If the copy fails, check the destination folder’s permissions.

If the file is on the same volume but lost permissions due to a copy-paste, you can also use icacls to copy the ACL from the source. First, save the source ACL to a file, then apply it to the destination:

icacls "C:\source\file.txt" /save "C:\temp\acl.txt" /t

This saves the ACL of file.txt to acl.txt. The /t flag applies to subdirectories; for a single file, it is harmless but unnecessary. Then apply the saved ACL to the destination:

icacls "D:\destination\file.txt" /restore "C:\temp\acl.txt"

This restores the saved ACL to the destination file. Note that this replaces the entire ACL, so use it only when you are certain the source ACL is what you want.

Scenario B: File gained permissions (too open)

If the file now grants access to users who should not have it, the cause is inheritance from a permissive destination folder. To fix this, you can either move the file to a more restrictive folder, or disable inheritance and set explicit permissions. To disable inheritance on the file and copy the inherited permissions as explicit entries:

icacls "C:\path\to\file.txt" /inheritance:d

This removes inherited permissions and converts them to explicit entries. Then remove any unwanted entries. For example, to remove the Everyone group:

icacls "C:\path\to\file.txt" /remove:g "Everyone"

The /remove:g flag removes a specific group. To remove a user, use /remove:u. After this, the file has only the permissions you explicitly set. If you want to re-enable inheritance later, use /inheritance:e.

If the file is in a system folder and you are tempted to take ownership to fix access, do not. Taking ownership of system folders or files can break Windows updates and services, and the problem often outlasts the one you solved. The correct approach is to restore the default permissions using the built-in icacls command with the %windir% paths, but only if you are certain the ACLs were modified. For system files, the safer fix is to run System File Checker:

sfc /scannow

This scans protected system files and replaces corrupted ones with the correct version, which also resets their permissions. If sfc finds issues, run dism to repair the system image:

dism /online /cleanup-image /restorehealth

These commands do not touch user data, but they may take a long time. Do not use them for a non-system file.

What people get wrong

A natural mistake is to assume that moving a file always changes its permissions. In reality, a same-volume move preserves the ACL, so if you see a change, the operation was likely a copy or a cross-volume move. Another common error is to take ownership of a file or folder to fix access, especially in system directories. Taking ownership of C:\Windows\System32 or its subfolders can cause boot failures and security issues, and it is rarely the right fix. The correct diagnosis is to check whether the file was copied or moved, and to use icacls to inspect the actual ACL. Another misconception is that permissions are stored with the file on any file system; FAT32 and exFAT do not support NTFS ACLs, so moving a file to such a volume strips all permissions, and the file becomes accessible to anyone with physical access. This is not a permission problem; it is a file system limitation.

Preventing the problem

To avoid permission changes when moving files, use robocopy with /COPYALL for any copy or cross-volume move that must preserve permissions. For same-volume moves, a simple drag-and-drop is fine. If you are moving files between user profiles, consider using the built-in Move-Item cmdlet in PowerShell, which performs a true move and preserves permissions when the destination is on the same volume. For cross-volume moves, use robocopy and then delete the source. Always verify the ACL after the move with icacls.

Summary of commands

These commands are built into Windows and require an elevated Command Prompt. They do not modify data unless you specify a file that contains data; icacls changes only permissions, not content.