SharePoint Users Can’t Rename Documents – Access Denied

A recent client had a requirement that certain users were NOT allowed to delete files – but that they would be able to add, edit, etc.

The solution that was put in place involved the following steps :

  • Create a new user role – Contribute Without Delete (within SharePoint)
  • Copy the “Contribute” role
  • Un-check the ability to Delete
  • Add users to this role/group – within SharePoint

This solution works well – and people can’t delete – there is no ‘icon’ on the Ribbon or Context Menu.

BUT – and this is where the problem arises – people are getting errors.

  • User-A is within Contribute Without Delete
  • Uploads a document to a library
  • Metadata screen is shown


  • User changes the document name (or via Edit Properties)
  • Click OK – and BOOM – Access Denied !
  • This problem does NOT occur for other users – only those within the Contribute Without Delete role/group.


WHY ??

When a file is renamed in SharePoint, it is actually DELETED and ADDED with the new name.

As such, any users who do not have ‘delete’ permissions will get an Access Denied error – as shown.

This is the same as the Windows File System – within Windows Explorer – ie. consistent behaviour.


Quite simply, the best approach is to NOT use the Contribute Without Delete role/group.

The discussion I’ve had with some colleagues has some merit :

  • If a person is able to upload/edit, why NOT allow Delete
  • If they accidentally delete, it goes into their own Recycle Bin
  • If they empty it, it goes into the Site Collection Recycle Bin
  • If a person should not be able to delete a file, perhaps have an area where they have READ ONLY permission – and can’t do any edits, ie. no renaming, etc.

It’s certainly an interesting scenario, eh ?

Rename = Delete + Add

I’ll have to talk it over with my client – and work out what they want to do !

5 thoughts on “SharePoint Users Can’t Rename Documents – Access Denied

  1. Petro Margaritis November 2, 2012 / 4:09 am

    Hey Chris,

    As of late I’ve also been experiencing this very same behavior 🙂

    The scenario in which this happens to me is when an event receiver hooked up to the ItemCheckedIn event is fired. This particular event receiver gets the metadata filled in the form and uses it to rename the file, which is actioned via the MoveTo() method as this occurs post the file being checked in.

    It seems that any rename/move action in SharePoint constitutes as a Delete + Add operation!

    Maybe the only way to get around this while enforcing the no delete policy would be to implement the SPSecurity.RunWithElevatedPrivileges() method in my above event receiver? :/

    What do you think?


  2. SharePoint-Stinks April 24, 2013 / 7:26 pm

    If a person is able to upload/edit, why NOT allow Delete… Because with sensitive documents you want to keep an accurate and complete chain of events. That chain is broken when the document is moved to the recycle bin. A version history is kept when its simply modified. What’s the point of the having a “contribute no delete” if you really can’t contribute?


  3. Zane D. June 7, 2013 / 4:37 pm

    has anyone tried a workflow using an impersonation step to change the name field? Just curious…


  4. Dan May 2, 2014 / 6:05 pm

    I’m glad to have found your post. I would not have guessed that SharePoint was deleting an item during renaming.


  5. vin pathak May 28, 2014 / 1:40 am

    still the same in SharepointOnline 2013


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s