Files shared with Anyone sometimes prompt users to request acccess to the file

[Emily Mason]

My company is experiencing an intermittent problem where sometimes a OneDrive for Business file shared with the setting "Anyone with this link can edit" prompts the user the file is being shared with to request access. If the user tries to open the file a second time, they can then access the file without requesting access. We're wondering why that access request prompt sometimes happens and how to prevent it. It doesn't happen consistently, so we're having trouble reproducing and troubleshooting it. Has anyone seen this before and know how to fix it?

[#2]

So the times I used to see this was because users would get a link. Then end up copying the URL instead. Or they would access a file then copy the URL and send it on to someone else which isn’t the same as a share link and would lead to request access.

Also would have people already be logged into a different Microsoft account in browser cache before clicking the link but your using anon links so that shouldn’t be the issue.

[#3]

Thanks for these ideas, Chris. I don't think this is happening because of copying the URL since the link always works when the user tries it a second time. Users have experienced the issue when they use the attach file option in Outlook to share a copy of a file from OneDrive, and by using the share feature in OneDrive.

[#4]

Are the share links only to direct files or to folders usually, do you know by chance? Usually the only reason you would get request access is because you are authenticated and something on the screen is rendering that it isn't liking. There used to be a bug on Guest Teams sharepoint sites where you would get Access request after the screen loaded because it was trying to render photos that the guest account couldn't read from somewhere else in the tenant.

But because it's random it makes it rather odd. Usually first time is because your not authenticated and SSO kicks in then try again and it works. Hence why there might be something odd requiring authentication of the page to happen.

I guess one thing to check, when it works check the name in the top right, is it anonymous when it does, and the users name when it gives access requests? Or vice versa? might be something to keep an eye out for to give some clues.

[#5]

Thanks Chris. I believe this has always been happening with links to files. That's a good thought that it is has something to do with authentication. I'll try to keep an eye out for what name is listed when I catch it happening again.

[#6]

Hi @Emily Mason,

This does sound like an authentication issue as Chris described. If by chance you can get a fiddler trace of the access prompt, do let me know so we can take a look. Also see if this ever repros in an incognito browser as that should work no matter what. Thanks!

Stephen Rice

OneDrive Program Manager II

[#7]

Thanks, Stephen. I'll give the fiddler trace and incognito browser a try if I can ever catch this happening. The trouble is it's difficult to reproduce the issue because by the time I hear about someone experiencing the issue the link works for them the second time around. Thanks for the suggestions.

[#8]

@Emily Mason, totally understand :) Thanks for your feedback!

Stephen Rice

OneDrive Program Manager II

[#9]

Did anyone ever figure out what was causing this behavior? I realize this thread is a year-plus old at this point, but we are experiencing this same issue in our tenant. We have published links to OneDrive files on our website using "anyone with the link" permissions. Occasionally, a user will click a link to one of those files and immediately be prompted to request access. This generates an email to the Group owners asking us to approve or reject the request. The link in the automated email sometimes identifies the actual file in question, but other times the link incorrectly points to the root level of the Group. I have corresponded with enough of these users after the fact to verify that they were not trying to access the root folder - in every case, they clicked a link to a specific file via our website. First step on our end was to make sure that those links were correct. We have tested them in 'fresh' browsers and incognito windows. They work for us. There seems to be no logic to when the link will work properly and when it will display an access challenge. Here are a few scenarios that actually took place. All of these users clicked a valid link on our website as their first step:

1. User tried three times in a row to download a file. Each time, an automated email was generated. He ended up calling our Service Desk and finding a workaround that did not require the file, so it's unclear if he ever would have been able to download successfully. 
2. User successfully downloaded a file. She then came back a few days later and tried to download the same file using the exact same web link. This time she was prompted to request access. I contacted her the following day and asked her to try again, and the link worked.
3. User received an access request. I happened to see the automated email within a few minutes and reached out to her to get some more details. As part of troubleshooting, I had her try the link again, and it worked.
4. User received an access request, restarted her browser, and the link worked.

We haven't submitted a ticket for this yet because we can't find any way to reliably replicate the behavior. This is the first thread I've found that seems to describe the same issue, so I'm hoping someone has figured out how to make it go away and just didn't update the thread with their workaround :).

[#10]

My gut tells me it's something to do with people having Azure AD tokens in their browsers causing it. Of the users getting the access requests, are they guests / have accounts (search e-mail) in your tenant for other things?

I know SharePoint and OneDrive like to mark known authenticated users as "viewers" and things like that, and if it recognizes a user based on local token / cookie in the browsers from AD auth. it's gonna try to access that and cause the access request. Not sure from a technical standpoint / code that gets figured out, but my gut tells me that is where the issue might lie based on how I see some of these sharing links working. Hopefully Stephen still see's responses here and might be able to shed some light.

[#11]

We're experiencing the same issue\symptoms that Emily reported but with SharePoint, not surprising because of the since OneDrive\SharePoint integration.  

Intermittent problem where sometimes a SharePoint file shared with the setting "Anyone with this link can edit or view" prompts the user to request access to the file. If the user clicks on the shared link a second time, they can then access the file without requesting access.

If the user submits the Access Request, the SharePoint site owner does receive a email to Approve\Reject the request. However, if the user clicks on the link the second time (without the SharePoint Owner approving the request), the user gains access to the file. Approval is not needed and this only happens to some users.

We're trying a custom message for the Access Requests so as to set expectations and to try the link again, but that isn't a fix. We're looking to see whether others have experienced these issues with SharePoint and whether a fix has been found or options to better manage the situation. 

[#12]

Hi folks,

As a matter of fact I do still show up around here :)

Let me kick off a thread with some folks internally to see if we can take a guess as to what's going on. My gut is that Chris is correct and the service is latching on to some cached credentials but as you all know, it's tough to nail it down when it doesn't reproduce regularly. If anyone does manage to snag either a trace of this happening or a correlation ID on a request where it occurred, please shoot me a PM. Thanks!

Stephen Rice

Senior Program Manager, OneDrive

[#13]

Hi all,

Unfortunately, we're still not able to identify a root cause here from our side. If anyone here happens to have this issue reproduce, please send me a PM. If we know the link that was used, the organization that experienced it, and the rough timeframe when this occurred, we should be able to pull out some logs on our side to help understand what is going on here. Thanks!

Stephen Rice

Senior Program Manager, OneDrive

[#14]

Any available follow up here ? I am running into the exact issue with users logged in through the browser being promoted to request access to a shared with everyone link. It is not consistant and just as described a simple re-opening of the link and they are in

[#15]

Haven’t read the full threat here but wanted to share that we are seeing a similar behaviour in ODFB in W10 file explorer. We have not done a lot of research yet. But to me, it seems to be a bug that cause the incorrect link type to be generated after you select “anyone with the link” and click “copy link”. The first time you get the link after selecting anyone, it is a link requiring sign in, but if you go back to Share and click “manage access” you will find that an “anyone” link was in fact created and you can copy it from there. Pasting those two links next to each other, we found that they are clearly different. Maybe it has something to do with which link type is default on tenant level. We do not have “anyone” links as default, in fact we are limiting access to those links via a security group so the bug might be related to that.
Anyhow, for us this is quite clearly a bug, at least in the W10 file explorer UI, where the “anyone” selection is not respected when it generates the link and copies it automatically, but it does generate the correct link in the background which can be found under “manage access”.

Hope this makes sense and helps the troubleshooting.

[#16]

Hi @DUrban11,

We are still looking into this on our side. Out of curiosity, are all the folks who are in this thread & have seen this issue occur in a multi-geo organization? Thanks!

Stephen Rice

Senior Program Manager, OneDrive

[#17]

Thanks for looking at this. We are not in multi-geo (yet)

[#18]

@Stephen Rice 

I've had this happen a few times.  It's all internal, people within our organization.  The link is to a file directly but it has also happened to a shared folder in OneDrive.  

The complication is if it is sent to 10 people it may for for 9 of them.  There is no consistency when it works or who it works for. 

We are not multi-geo.  All within the Greater Toronto Area but working from home during quarantine. 

[#19]

Thanks for confirming @thatashgirl!

We are still investigating this one internally. Thanks!

Stephen Rice

Senior Program Manager, OneDrive

[#20]

Good afternoon@Stephen Rice

I hope your well, has there been any update on this please?

Regards