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?
- Same issue happening to me. Shared folder in OneDrive, selected Anyone with the link can edit, unchecked allow editing and put an expiration date to 6/1/2021. This morning received 5 email from users outside our organization, all of them saying the link is asking them to login. After reading this thread, I see how cached credentials in their browsers could cause an issue since it is supposed to be accessed "anonymously". Having said that, how do we fix this? asking external users to use Incognito mode in browsers, although it works, does not seem to be the most elegant solution, specially when we are talking about hundreds of users accessing these folders. I don't want to suggest my staff to use Dropdbox, please help find a solution!
I have a personal One Drive account I sometimes upload files I want to share with others to. I will direct the system to allow users to view files only. This is a consistent behavior I evoke. What I have found is that other end users which have a Microsoft 365 account constantly have this issue when attempting to access the links I send them. What I discovered, and I am greatly surprised MS has NOT corrected this yet, is the browser used by the end user has loaded into cookies or cache the USERS status as a MS 365 user, and then immediately directs the browser to request credentials. What I also discovered is that IF the end user invokes the link using a browser which has NOT had the opportunity to save cookies or the critical date into cache, the problem does not happen. I personally have discovered if I clear cookies and cache data from my default browser, the problem does not appear. Clearly one user below has discovered that MS first looks at the user access status condition, BEFORE looking at the link access status requirements (which would be totally open).
I would have holed that MS would have corrected this since it's been an issue since at least 2017. I HAVE NOT verified if the MS EDGE browser exhibits this behavior. The situation may be corrected in that software since it's under MS control.
Bill_Hawkins wrote Sept 19, 2022:
What I also discovered is that IF the end user invokes the link using a browser which has NOT had the opportunity to save cookies or the critical date into cache, the problem does not happen. I personally have discovered if I clear cookies and cache data from my default browser, the problem does not appear.
For the reasons you give, using an Incognito/Private window to open the link also works around the problem.
tom_tulinsky We send newsletters to 2,000 people, most of whom wouldn't have a clue what an incognito window is, so that wouldn't work for us.
- bump, has anyone found a fix for this issue? anyone from microsoft care chime in?
- And another, it's still an issue and I guess we'll all be dead and buried before they even accept we aren't just imagining it.
- 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.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.
- Hi 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.
- Hey 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.
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.
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.
- StephenRice
Microsoft
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
- StephenRice
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 RiceSenior Program Manager, OneDrive
- 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. My organization is having a similar issue. I work at a university in our online school. We use OneDrive to host all of our curriculum files and we exclusively use Anyone With the Link Can View links to link course files into our LMS. We are running about 300 courses and about 1000 individual course sections each year, with thousands of files shared from our OneDrive into those courses.
We are sporadically getting links that have been set as Anyone Can View prompting users to sign in or getting error messages as some others have stated already. Just last night I had a student submit an issue that a file was giving this error and it did for me as well. But when I got into the office this morning to troubleshoot further, the file link was working properly.
When I access the files through my LMS Administrator account (which has our institutional OneDrive linked to it), I can access the file no problem. But when I test in Incognito Mode or in another browser that does not have my credentials saved, I'm getting the request access or error message.
This is the first forum I have found that has discussed a similar issue.
- If you go into where the file is stored, and click the file then manage access on it, and see the anyone link, copy it, and check it vs. the link you have published, do they match?
ChrisWebbTech they do not in the files that I have just spot checked.
The links that have been generated to share in our LMS are significantly longer than the ones that I'm seeing in the Manage Access tab in OneDrive. Both get me to the file when I have my credentials logged in for OneDrive, but the long form one does not when I'm in incognito mode or another browser.
The links had previously worked without issue and now some are not.
When I go to regenerate a share link, it's now giving me much shorter links from both the browser lever and file explorer level access into our OneDrive. Was there an update sometime recently in how OneDrive generates share links? I'm not an IT person, I'm just the tech person for our instructional design team so I am a bit out of my depth.
Kind of same issue:
Go into my business One Drive online, right click on a folder to share,
change "Anyone with link can edit" to "Specific people" and uncheck "allow editing.
Click apply, then in next window type in one of business email addresses of a user.
Send the link, the user receives link in email, they click on the folder link,
chrome launches and they are asked to put in user credentials right away.
The standard Microsoft poup for "remember credentials", yes, then
user gets straight into the shared folder.Every 2 days or so I get message from 2 to 3 end users that this folder has
been shared with, that One Drive is asking for credentials to login.
This is very annoying, we just don't hand out the login password to end users,
so everytime this happens I need to remote into their computer and add the credentials.No idea why this happens, it seems to be after an update and restart to the computer,
or just a power off and restart.I have gone into the credential manager and clicked on "remove" of Office and Microsoft credentials.
Still keeps happening.Computer is updated, Chrome is updated, etc.
- A data point: The problem continues to happen even though I'm using a completely new install of Windows on a completely new computer (not using same Windows-image).
