Modern Attachments - Cannot set perms

[Mike Tilson]

Since updating my Office 2016 bits to 1709 Build 8528.2139 I am unable to attach/set permissions on a file in Outlook (Desktop) from my OneDrive for Business site. My Colleague also has the same issue with the same build. The error that I receive is in the attached screenshot and says: "An error occurred while updating permissions for 'Document.docx'. Retry | Dismiss" This worked fine before upgrading the Office bits. I tested on a VM running 1708 Build 8431.2079 and it still works as expected. It also works fine in Outlook Web. As a work around, I can click the drop down for the file and set permissions then click retry and it works.  I first reported this problem to MS Premier support on 10/17/17 but have not been provided a resolution.  I have since updated my Office bits to 1710 (Build 8625.2121)  and the issue persists.  I found someone having a similar issue here - https://stackoverflow.com/questions/46725044/outlook-spo-email-attachment-permission-error-with-acti... Is anyone else experiencing this issue?

[#2]

Out of curiosity, if you dismiss the warning, are permissions set correctly anyway in ODfB site?

[#3]

It sent the email, user could see the attachment listed in the email but did not apply any permissions for the user.

[#4]

This relates to the "Direct" setting for the OneDrive for Business default sharing links.  It works fine if you switch to Internal.  I was told by MS PMs at Ignite that it must be set on direct for the default sharing permission to be "Recipients can edit" rather than "Organization can edit."

[#5]

Have you verified directly on the ODfB site that no permissions were applied?

I am asking because I have seen sometimes that warning, but nevertheless the permissions were correctly applied...

[#6]

"Direct" means that no additional permissions are applied while creating the link, hence only users that already have the correct permissions will be able to access the item.

"Internal" means that everyone in the tenant will be able to access the item using the copied link.

[#7]

I verified that no new permissions were applied to the file on my OD4B site.  There were also no anonymous links added (Which I would expect if it gave every org can edit permissions).

[#8]

The wording is misleading and doesn't behave as described.  If I have direct selected then the default permission for modern attachments in OWA is "Recipient's can edit" and it works as expected.  If I change that to Internal the default permission behavior in both OWA and Outlook is "Everyone in the org can edit."  I talked with several MS PMs while in Orlando at Ignite and have been emailing them since about how to properly change the default behavior for modern attachments, Direct is the setting they had me choose.  For this Outlook issue they advised opening a Premier case, I wasn't getting an answer from Premier quick enough so that is why I decided to share here.

[#9]

Adding @Stephen Rice

[#10]

Hi @Mike Tilson,

Thanks for reporting this here. You are correct that setting the default link to "direct" should cause the modern/cloud attachment to default to "Recipients can edit". Let me look into this and see if we can figure out what's going on. Thanks!

Stephen Rice

[#11]

This issue still exists. I have updated to v 1710 (Build 8625.2127) and now I don't even have the option in Outlook to share with the organization although that option still exists and functions correctly in OWA.

 

I took a newly imaged Surface laptop and installed Office software directly from Office 365 with version 1710 (8625.2121).  I can reproduce the error on the fresh imaged PC with that Office version on a different tenant than our production tenant.

When I first installed Office on this machine it had the deferred bits and the modern attachments worked fine but broke after the update to the latest bits.

[#12]

@Stephen Rice any updates on this? We are seeing this issue as well. Ours started showing up after we changed the default at the tenant level to be 'Specific People' instead of 'People in <company name>'.

This is making all of our users think modern attachments are broken, and they are reverting to attaching files the old way which is very much not what we want!

[#13]

Hi @David Rosenthal,

We are still investigating internally with the Outlook team. Thanks,

Stephen Rice

OneDrive Program Manager II

[#14]

Adding a bit more info: it's not just ODfB, but SPO as a whole. At least, that is what we are seeing. Got some cranky users (just so happens, I am included in that group). Our current workaround is 'use the browser-based Outlook.'
Small hitch: it doesn't even attempt to look for attachments in all the different places in SPO, just ODfB. But that's a feature request for another team.

[#15]

Our organization is having the same exact issue. Looking forward to a response.

[#16]

@Stephen Rice Did you get any response from Outlook team on this?

[#17]

We are seeing this same behavior in our environment as well.

[#18]

Hello,

Our 10,000+ employee organization where everyone has either the G-3 and G-5 license is experiencing this as well.  This work beautifully just last week.

Jhason

[#19]

Our organization is seeing this also. We've identified the following workaround: After the error message appears, use the dropdown menu on the attached document and choose either of the Change Permissions commands (recipients can edit or recipients can view). Then click Retry next to the error message, and the attachment succeeds.

[#20 · Accepted solution]

This issue is resolved with build 1711 8730.2175.