Prevent deletion of SharePoint files

[ashmelburnian]

We had a situation where an end user accidentally deleted thousands for files under a SharePoint document library via OneDrive.

The document library itself is accessible to everyone within the company.

Is it possible to prevent users from deleting files within a document library and all subfolders?

All users currently have "Edit" permissions allowing users to add, update and delete all items. There doesn't appear to be a permission level that allows all this except for delete.

[#2]

Hi @ashmelburnian,

I don't believe that is possible with out of the box permissions.

Is an additional document library with read only permissions reasonable?

I hope this helps.

Norm

[#3 · Accepted solution]

You need to create a new permission role and assign that to users. Go to the SharePoint site permissions, it's under advanced on the home page. Add a role and select just the permissions the user needs and not delete. Now go to library and change the user group permissions to that new role.

[#4]

@Alan Marshall~ Thanks for pointing that out. I forgot that was possible.

@ashmelburnian ~ Sorry if I led you astray.

[#5]

@Alan MarshallThanks for your help, much appreciated.

The setting is under Site settings > Site permissions > Permission levels.

[#6]

@Alan Marshall 

Great tip.  Noticed one drawback though.  The ability to rename files is linked to the Delete permission.  When you remove the Delete permission, the user can't rename files anymore either.

[#7]

That should only require edit rights as it's a property. Maybe someone at Microsoft can confirm this.

[#8]

@Alan Marshall 

Sure, with the Edit right, you can edit the file or modify its metadata no problem.  However, by renaming it, it seems the system must delete one version to re-create the new version with the new name.  This must be done with the Delete right.

There has been some discussion on that:

https://sharepoint.stackexchange.com/questions/255781/permission-level-which-doesnt-allow-renaming-f...

Forced me to do a few acrobatics in my application cause I wanted to prevent users from deleting their files (and those contributed by others) but also allow them to rename the file.

R.

[#9]

@Alan Marshall 

I agree but users always need to delete the files, you just need to train them also you are able to recover all the files after deletion. 

[#10]

@ashmelburnian  I'm not seeing the Manage options on our SharePoint sites.  We are on a Government Tenant, so I'm wondering if that feature just isn't available yet or if it is something we can add to the menu.  

[#11]

You are right. I used Views to prevent users from deleting files from others. The ability to recover after deleting a file is also reassuring. Thanks.

[#12]

@ashmelburnian I am also facing this same issue in that I'd like to prevent users from deleting files.  However, it also seems to prevent their being able to move files. 

Could someone please confirm for me those two are also related.  Also, what else might be affected if you do not allow delete? 

Anyone know of a User Voice to vote for this option.  It seems to be a frequent request -- to prevent delete but allow other options. 

Thank you in advance for your help, everyone! 

[#13]

@ashmelburnian 

I am not an Admin of our SharePoint instance, but I do have the ability to create sub sites. I can’t create my own unique permissions either. I have to work within the defaults I’m provided. I also don’t want the Users deleting their folders on which they can Contribute as all the permissions on the folder go with the folder and it’s a headache to fix - maybe even detrimental depending on what files are lost and the retention policies in place. The “can’t be done” answer is less appealing to me than a slightly tedious solution that works.

One option to consider trying - that works for me - is to:

1.) Place a tiny txt file in the Member (User) [or Group folder] and then as Owner “Do not share” the txt file so it is only visible to the Owner. In other words, the Owner has Full Control on the txt file, and no one else has any access - therefore they don’t even see it in their folder on which they have Contribute permission. Then

2.) Right-click on the txt file as Owner and “Check out” the file.

It’s a bit of a hack, but if the Member with Contribute rights tries to delete the folder either intentionally or by accident (even when appearing empty) they will be told the folder has a file checked out for editing and they can not delete the folder. 

If you have sub folders within the folder you wish retained, then placing this _.txt or do_not_delete.txt file in the sub folder will prevent easy deletion of both the sub folder and (all enclosing) folder(s). The Member’s file actions (i.e., create, rename, delete, etc.) on their own files are otherwise unaffected as only the txt file’s access is impacted.

The obvious downside is this ”fix” takes clicks within each User “Contribute” folder, but depending on the number of Users and folders the Owner has within the site, it may be worth the time spent and help you rest easier knowing the folder‘s aren't easily deleted.

If you have Admin control over the site I imagine you should be able to come up with a better way (i.e., faster and less tedious way) to achieve the same outcome.

[#14]

@Jeff_Nowak_Purdue_U_FW Hi, I liked your solution to this problem albeit, as you said, rather tedious to implement. The main problem would be remembering to insert the text file in every newly created folder.

I'm interested to know whether you found another solution?

Regards, George

[#15]

@Cindy Zalme 

A bit of time has passed since this question, however in my experience the granular 'delete' permission is related to the following actions someone might want to do:

• Delete,
• Rename, and
• Move

NB: as aforementioned by others in this post

When I implemented a delete restriction in document library where I wanted more control I created a workflow to be manually run which allowed someone to provide the new name of the file. It then renamed the file using a specific account that had elevated rights to the library.

That was implemented on-premise and I am yet to re-create this online, however I imagine the logic would work the same.

Hope this helps.

[#16]

@collabrius That sounds very helpful for my situation, provided its works online.

Would it be possible to use the same/similar method for moving a file when delete permission is off.

[#17]

@GS_Gordon 

That's a very good question. Moving files is on my radar as a function I need to test for two reasons:

- I like maintaining a single version of the truth, and

- in some environments people keep everything regardless of being deleted, which adds to total capacity

Will let you know how I get on. Once working I will test it with the custom permission level.

Cheers @collabrius 

[#18]

@collabriushave you had any success?  Our situation is similar but part of our process is to tag metadata on the status of the file (draft, final, archive, etc.) so I'm wondering if is possible to allow deletion based on status - drafts can be deleted, others may not. 

We are going to work on several options and my add our findings to this thread.

Best of luck.

[#19]

Thanks for the creative work-around for those of us in desperate need of a solution. This is something that SHOULD be an included feature on a tool that is promoted as a solution for businesses to use for their document management needs. Your 'half-way' implementation mentality is getting old Microsoft and you are pushing customers to competitors.

[#20]

Hi Jilian,
I had the same problem. Not sure if this actually fixed but I added myself to the individual site as an additional admin and the referenced Permissions levels tab appeared after 15 minutes or so. Go figure.