Forum Discussion
Files shared with Anyone sometimes prompt users to request acccess to the file
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?
115 Replies
- omalleyOITCopper Contributor
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:
- 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.
- 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.
- 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.
- 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 :).
- 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.
- 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.- lucas_aguiarCopper ContributorHi everyone, hi StephenRice. I'm having the same problem. In my case, I need to use the URLs so that an external program will download the images and update as product pictures on marketplaces. The issue seems pretty random, though. Some photos will be accessible, while others will require a login. I tested uploading the URLs to two different webisites (400 pics in total). Some of them will be available at one site, other will be available at another... There isn't a consistency.
- lucas_aguiarCopper ContributorHey again. Sorry if I'm being such a noob 😄
But I kinda figured out how to solve my problem. The thing is that if I copied the URL from my computer (my onedrive user) and another person tried to upload it through their computer (another user), the marketplace wouldn't be able to download the photo, promping an access request. If I, who copied the URL, tried to upload it, the marketplace would access the picture just fine.
In fact, two URLs from the same picture are different (one that I copied from my user, and the other that other person copied, using a different user). Didn't know that could happen. I hope it helps.
- Emily MasonCopper Contributor
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.
- 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.