SharePoint migration manager File Share agent to migrate local drive did not preserve the permissions

Question

SharePoint migration manager File Share agent to migrate local drive did not preserve the permissions

john john Pter 1,590

I used the SharePoint admin center, migration manager File Share agent to migrate local drive, but many root folders had this permission settings, so they did not get any user or group to access it :-

User's image

so this mean no one can access the migrate folders, except sharepoint site admin . although i define to preserve the File Permissions

User's image

any advice?

Thanks

0 comments

2 answers

Your answer

Answer 1

Kai-L 20,635 Microsoft External Staff Moderator

Dear john,

From my research, when file share permissions are preserved and the library itself is selected as the destination, the permissions of the source root folder replace the library's existing permissions. If those source permissions could not be mapped to Microsoft 365 users or groups, the library can be left with no entries, so only site admins can access it. To restore access quickly, please try the following:

Open the Knowledge library, then go to Settings > Library settings > More library settings > Permissions for this document library.
Select Delete unique permissions so the library inherits from the site again, or select Grant Permissions to add the site's Members and Visitors groups back.
Check a few migrated folders with Check Permissions to confirm your users have access again.

For future migration tasks, I recommend:

Create a folder inside the library and select it as the destination instead of the library root.
Make sure the source users and groups are domain accounts that sync to Microsoft Entra ID, or use a user mapping file.
Run a small pilot first and confirm the permissions before migrating everything.

For reference:

File & folder permission when using SharePoint Migration Tool - Migrate to Microsoft 365

Customize permissions for a SharePoint list or library | Microsoft Support

I hope this helps. Looking forward to your reply.

If the answer is helpful, please click "Yes" and kindly upvote it. If you have extra questions about this answer, please click "Comment".

Note: Please follow the steps in the forum documentation to enable e-mail notifications if you want to receive the related email notification for this thread.

john john Pter 1,590 Reputation points

2026-10-22T20:39:13.81+00:00

@Kai-L thanks for the reply, but i do not want to have all root folders inside a new folder, can i just create this temp folder, move the folders back to the library root after the migration completed? but to preserve the permission ? is this possible?
Kai-L 20,635 Reputation points Microsoft External Staff Moderator

2026-10-22T21:40:57.8866667+00:00
Dear john,

Thank you for following up. I ran a quick test, and a folder with its own (unique) permissions kept them after being moved from a subfolder to the root of the same library so this approach can work. However, any folder that only inherited its permissions in the source will inherit from the temporary folder after migration. Once moved to the library root, it will inherit from the library instead, which currently has no users or groups. Before moving everything, I recommend testing with a small sample:

Migrate a few folders into the temporary folder.

Open a migrated folder's permissions page and check whether it shows This folder has unique permissions or This folder inherits permissions from its parent.

Move the folder to the library root, then check its permissions again to confirm users still have access.

If some folders only inherit, you can either give the library the correct permissions before moving them, or break inheritance on those folders and assign permissions before the move.

I hope this helps. If the results are different from what you expect, feel free to share what you see and we can look into it further.
Kai-L 20,635 Reputation points Microsoft External Staff Moderator

2026-10-23T20:00:44.7+00:00

Dear john,

It has been a while and I am writing to see how things are going with this issue. If there’s anything else I can assist you with or if you need further clarification, please don’t hesitate to let me know, I’m here to help. Looking forward to hearing from you. Wishing you a great day ahead!

Answer 2

Create a folder inside the destination document library and migrate the file-share root into that folder, because Migration Manager does not migrate source root-folder permissions when the document library itself is selected as the destination.^1^

Correct the migration

In the destination SharePoint document library, create a new folder, such as MigratedData.
In SharePoint admin center → Migration → Migration Manager, create a new migration task.
Select the same local/file-share source.
For the destination, select the newly created MigratedData folder—not the document library root.
Keep Preserve file share permissions enabled.
Under the task’s user settings, use either:
- Microsoft Entra lookup, which maps source identities automatically; or
- A user mapping file for identities that cannot be resolved automatically.^2^
Run a pilot and inspect Manage Access on the new destination folder and representative child folders before migrating the remaining data.

An existing task cannot be redirected to a different destination after its initial migration, so addressing the library-root exception requires a new task.^3^

After validating the new copy, either direct users to it or move it into the intended information architecture. Avoid deleting the existing copy until permissions and content have been compared.

Verify which source permissions are eligible

The setting does not preserve every kind of Windows permission:

Users and groups must be synchronized or otherwise mapped to Microsoft Entra ID.
Only NTFS permissions exposed through Windows File Explorer—or NTFS-equivalent permissions exposed over SMB—are migrated.
Permissions granted only at the share level are not migrated.
Advanced NTFS permissions, auditing settings, and explicit deny entries are not preserved.
The most restrictive applicable share or NTFS permission determines the resulting SharePoint access level.^4^^5^

Before rerunning, check the source folder’s Properties → Security tab—not only Properties → Sharing. Confirm that every required source user and group has a corresponding Microsoft Entra identity. Unresolved identities can leave migrated content without the expected role assignments.

Repair content already migrated

A normal delta sync will not necessarily repair permissions by itself. Migration Manager updates permissions during delta sync only when the corresponding file is transferred. A permission-only source change does not alter the file’s modified timestamp, so the default incremental mode may skip it.^3^

For child content whose destination is otherwise correct:

Open the task’s Project settings → Advanced.
Set file-transfer behavior to Migrate all files and overwrite any existing ones at the destination.
Run delta sync.
Recheck representative folder and file permissions.

This is slower and overwrites destination files, including destination-side content changes, so preserve or reconcile any changes users made after migration. It also does not overcome the document-library-root exception; use the new-folder/new-task approach for that issue.

The screenshot states that the folder inherits from its parent. Therefore, its effective access is determined by the parent even though the current folder’s permissions view lists no direct assignments. Use Check Permissions for a representative user to verify effective access rather than relying only on the empty list.

References