I had a really annoying experience where i think i was wrong in the order i handled the situation but i was wondering if anyone can clarify what happened for me.
A customer of us found that a Document Library on a department was set to wide in the permissions. They didnt trust the situation and decided the whole library had to be shut down and deny access to anyone except the specific employees for this department.
This department is about 5 persons big and all are syncing the complete library with the OneDrive sync tool (on-demand + W10 auto cleanup) for over months right now.
What did I do:
- Removed the security group to deny access for all users
- Within a minute or so i added the newly created sec.group to give access to these 5 users
- All local clients started piling up data in their local recycle bin as if OneDrive had an instruction to delete everything (Makes sense if your not authorized anymore)
- The data online started to disappear as well :( (In to recyclebin)
- Clients went into a loop to constantly deleting everything that other local clients were trying to delete
What i did:
- Kill the syncs
- Restore recycle bins
- Backup the old synced folder
- Started a new sync
- Merged every local file and folder
- Did a bulk restore of the online recycle bin between a period for one specific user
I think everything is recoverd properly but has anyone ever had this happened to him/her?
I can only explain this behavior in a fact that the local sync clients thought the had no permissions anymore (which they hadnt for a couple of secs), started to locally delete everything but when the permissions came back the delete request not only happend locally but also online.
Lesson #1, Less syncing locally
Lesson #2, Always check if syncing is used and make sure the permissions are correctly set before removing everyone else
You messed up by applying a security group. If it was explicit permission for the five first you would have been ok. Security group membership has always had a lag when it comes to group membership and the logged in user that can take quiet awhile before it updates for that logged in user on that resource.
But good job making use of file restore and getting it back under control. That looked like a scary mess