Permissions after Moving Files in Teams/SharePoint
Understand what’s happening – do it right – and avoid incorrect permissions
6th December 2025 / Ejner Jensen
Background
When you copy a file/folder with Teams/SharePoint’s “Copy to” function, you can always be sure, that it inherits the permissions at the destination – and you never end up with broken inheritance of permissions at the destination.
Unfortunately, this is not always the case when using the “Move to” function – sometimes permissions and broken inheritances are also moved from the source to the destination!
It’s a bit complicated – and there are a lot of different combinations – so there’s (understandably) a lot of confusion on the internet about this functionality. It’s also rare that all combinations are covered. This means, that if you ask Copilot or Gemini, they’ll give varying answers – which are unfortunately often wrong.
This is what I will try to remedy with this article.
After reading the article, I hope you understand, how “Move to” works and can avoid incorrect permissions, when moving files and folders.
Note: Although I have tested many different scenarios, there may be additional special cases!
Broken inheritance of permission
If you don’t know what “broken inheritance” of permissions is, read about it in:
Get in control of file permissions in Teams/SharePoint.
Exceptions
Here are the exceptions to inheriting permissions at the destination when moving.
See also the drawing below.
Within the same site
When you move a file – or a folder with content – to another folder/library on the same site – the permissions on each item move along. It can be one of these two options:
- The information that the element inherits from the parent level
– and then there are no problems - The unique permissions of the element
– and then it can get complicated
In other words:
- All elements with broken inheritance on the source will also have broken inheritance at the destination!
Note: This also applies, if the elements are located in a folder, where inheritance is not broken!
To another site
If you move one file to another site – and the file has direct unique permissions – you will be given the option to choose whether the sharing permissions should be moved along – but note, the broken inheritance on the file will move along!

Note: Does not apply to folders! …or moving multiple files at once!
Note: Does not apply to permissions for SharePoint groups – these are always inherited at the destination!
In practice this happens, when you move a file to another site and have chosen to move sharing permissions along:
- The file is moved to the destination
- The file inherits the permissions at the destination
- The inheritance is broken
- The sharing permissions from the source are assigned at the destination
– except for those for SharePoint groups.
Overview – with examples
Examples
Examples of moving within the same site:
- You have a file – for example, a press release – that only a few people have initially been given access to read (the file has been given unique permissions).
After it becomes public, you move the file to a folder that everyone has access to, where they can see all published press releases.
It just doesn’t work – because the limited reading rights move along with the file!
Here you have to copy the file instead (but then you have two versions of the file!)
– or delete unique permissions before or after the move.
In the drawing: Moving File A to Folder 3. - You have a file in a confidential folder, where the file inherits permissions from the folder.
At some point, you move the file to another folder – and think it is still confidential – but it is not!
In this case, the file inherits the permissions at the destination.
In the drawing: Moving File B to Folder 3. - You move a folder where inheritance is not broken – and it inherits the permissions at the destination just fine. But in the folder there was a file with a share link – and it will keep the permissions from the source and break the inheritance at the destination!
In the drawing: Moving Folder 1 to Folder 3. File A retains permissions from the source!
Subsequent consequences
You may not immediately realise if something goes wrong, when you move a file or folder to another location.
Incorrect permissions are discovered later
It is often only later that you discover, that too few – or too many – people have access to a file/folder. When it is discovered, you may not connect it to the previous move – and then you can get really confused – and perhaps worried about the permissions on the site.
Broken inheritance
If you later change the permissions for the website, this will in some cases not affect the files/folders where the inheritance is broken. You can read more about this in the article:
Final notes
I have only tested copying/moving in SharePoint, where I have used the 3-dot menu functions “Copy to” and “Move to”. And I have not tested from OneDrive – but I think it will work like moving to another site.
And then a recommendation from the Internet that I will support, even though I haven’t tested it:
Important: Always use the SharePoint/OneDrive web interface “Move to” and “Copy to” functions described in this article. Avoid using File Explorer or the OneDrive sync client to move files, as these methods can remove crucial metadata, create sync conflicts during collaborative editing, fail to transfer hidden files, cause versioning issues, and bypass SharePoint’s built-in safeguards.
Finally, some of the sources that Google Gemini and Copilot found on the topic:
- Tested SharePoint folder moves – the permission behavior is absolutely wild
- SharePoint online – Does copying or moving folder/files retain the permissions?
- M365: Moving or Copying Files in SharePoint and OneDrive
Note: I do not 100% guarantee, that I have included all scenarios!
Leave a comment if you have experienced something different – or have questions
