Somebody sends a file to a client and the client gets told the link has been disabled. The administrator checks the tenant, sees external sharing is permitted, and concludes something is wrong with the link itself. The link is almost always fine.
The stricter of the two settings applies
External sharing is configured at the organisation level and again at the site level. To share externally from any site, it has to be permitted at the organisation level, and individual sites can then be restricted further. Where the two disagree, the more restrictive value is what applies.
So confirming the tenant permits sharing establishes only that sharing is possible somewhere. The site holding the file is what decides. Three things follow from that, and they cover most of these tickets.
- A site can be locked down independently, often deliberately, because it holds material that should not leave the organisation.
- A new site does not automatically carry the organisation's permissive setting, so a recently created site can be stricter than the tenant without anybody having changed anything.
- OneDrive sharing is settled separately and can be the same as the SharePoint setting or stricter, never looser, which is why a file shared from somebody's OneDrive can fail where the same file in a site would not.
A link that used to work and now does not
A separate cause with the same symptom, and the one worth knowing if the link is old. As of June 2024, invitations issued through the legacy SharePoint invitation manager stopped granting access. Links from that era do not work and cannot be repaired at the recipient's end. The file has to be shared again to generate a valid invitation.
Beyond that, an anonymous link may simply have reached the end of its life if link expiry is configured, and a recipient's domain may be on a blocked list even where sharing is otherwise permitted. Both produce the same message, and both are settled by looking at the sharing configuration rather than the link.