Move a File Without Carrying Broken Permissions: Practical Checklist for SharePoint Owners

As a SharePoint site owner, you have likely experienced the frustration of moving a file only to find that its permissions changed unexpectedly. Users lose access, or worse, the wrong people can view sensitive content. This happens because SharePoint applies specific permission inheritance rules when files are moved between locations. This article explains exactly why broken permissions occur during file moves and provides a practical, step-by-step checklist to maintain the correct permissions every time.

We cover the root cause: how SharePoint handles permission inheritance when moving versus copying files. You will learn the three key decisions you must make before any move operation. We also list the most common mistakes site owners make and how to avoid them. By the end, you will be able to move files without carrying broken permissions.

Why Moving a File Can Break Permissions

SharePoint organizes content in a hierarchy: site collection, site, library, folder, and file. Each level can either inherit permissions from its parent or have unique permissions. When you move a file, SharePoint evaluates the permission settings of both the source and destination locations.

The core rule is simple: if both the source and destination inherit permissions from the same parent, the file keeps its original permissions after the move. If the destination has unique permissions, the file loses its original permissions and adopts the unique permissions of the destination. If the source has unique permissions and the destination inherits, the file keeps its unique permissions but they become orphaned — no longer linked to any parent.

Permission Inheritance: The Technical Mechanism

Every SharePoint object has a property called RoleAssignments. When permissions are inherited, this property is empty because the effective permissions come from the parent. When permissions are unique, the object stores its own RoleAssignments list. The Move operation does not recalculate RoleAssignments. It simply detaches the file from the source and attaches it to the destination. If the destination has unique permissions, SharePoint automatically removes the file’s inherited RoleAssignments and applies the destination’s unique ones. This is the moment permissions break.

The Difference Between Move and Copy

Copying a file always creates a new set of permissions at the destination. The copy inherits permissions from the destination’s parent. The original file remains unchanged. Moving a file, by contrast, transfers the existing permission assignment. This is why copies rarely cause permission problems, while moves are the leading cause of broken access.

Checklist: Move a File Without Breaking Permissions

Follow this checklist before every file move operation. Each step addresses a specific permission risk.

1. Determine the inheritance type of the source location
   Go to the library or folder where the file currently resides. Select the gear icon > Site permissions > Check permissions. Enter the name of a user or group. Review the output: if it shows Permissions inherited from parent, the source has inherited permissions. If it shows Unique permissions, the source has unique permissions. Write this down.
2. Determine the inheritance type of the destination location
   Navigate to the destination library or folder. Repeat the same Check permissions process. Identify whether the destination inherits permissions or has unique permissions. Compare this with the source type.
3. Choose the correct move method based on the inheritance match
   If both source and destination inherit from the same parent, use the Move To command in the SharePoint browser. Select the file, click the ellipsis (…), choose Move To, and select the destination. This preserves all original permissions. If the source or destination has unique permissions, do NOT use Move To. Instead, use Copy To and then manually adjust permissions at the destination.
4. If using Copy To, restore unique permissions manually
   After copying, go to the destination location. Select the copied file, click the ellipsis, choose Manage access, and then Advanced permissions settings. Click Stop inheriting permissions. Then add the specific users or groups that need access. This step is required because Copy To always inherits from the destination.
5. Test access before announcing the move
   Use the Check permissions tool on the moved file. Enter the names of three key users: the file owner, a reader, and an editor. Confirm each user has the expected permission level. If any user has incorrect access, edit the unique permissions on the file directly.
6. Document the move in a change log
   Create a simple SharePoint list or Excel file to record the file name, original location, new location, date, and permission inheritance types. This log helps you identify patterns. If permissions break again, you can trace the exact move that caused it.

Common Mistakes That Carry Broken Permissions

Even experienced site owners make these errors. Recognizing them helps you avoid the same pitfalls.

Using Drag-and-Drop in File Explorer or OneDrive Sync

Drag-and-drop in File Explorer or OneDrive sync does not use the SharePoint Move To command. These tools treat the operation as a copy followed by a delete. The copy inherits permissions from the destination, and the original is deleted. The result is that the file ends up with the destination’s permissions, not the original permissions. Always use the browser-based Move To command for permission-sensitive moves.

Moving a File That Has Unique Permissions to a Library That Also Has Unique Permissions

When both source and destination have unique permissions, the Move operation merges the two sets. The file loses its original unique permissions and takes on the destination’s unique permissions. Users who had access at the source may lose access. To avoid this, first break inheritance on the destination folder and set the exact permissions you want. Then move the file.

Moving a File from a Subsite to a Different Site Collection

Cross-site collection moves always break permissions because each site collection has its own permission hierarchy. SharePoint does not preserve permissions across site collections. The only way to maintain access is to copy the file and then manually assign permissions at the destination. Never use Move To for cross-site collection operations.

Move vs Copy: When to Use Each Method

Item	Move To	Copy To
Permission preservation	Preserves original permissions if inheritance matches	Always inherits from destination
Best use case	Same site collection, same inheritance type	Cross-site collection or different inheritance types
Risk of broken permissions	Low when conditions are met	None, but requires manual permission setup
File metadata retained	Yes, including version history	Yes, but version history is lost

Use Move To when both locations inherit from the same parent. Use Copy To when the inheritance types differ or when moving across site collections. After a copy, always verify and adjust permissions manually.

You now have a clear checklist to move files without carrying broken permissions. Start by checking the inheritance type of both source and destination using the Check permissions tool. Use the Move To command only when both locations share the same parent. For all other scenarios, use Copy To and then manually set unique permissions on the destination. As an advanced tip, create a SharePoint list to log every file move. Over time, this log will reveal which patterns cause permission issues in your environment.