TLDR: if Outlook claims it can't open a file due to permissions, or Explorer stalls mid-copy with an "interrupted action" dialog, and the file is clearly right there, check the path length before anything else. Neither error mentions path length. Windows has a legacy 260-character limit, and OneDrive/SharePoint layer their own separate limits on top. The LongPathsEnabled registry fix that turns up first in any search helps, but on its own it doesn't resolve either case below. Shortening the path itself does.
Two errors that give you no reason to suspect the path
First one, from Outlook, trying to open an attachment saved into a synced OneDrive folder:
We can’t open ‘C:\Users\J Smith\Client Dropbox\J Smith\salesforce documents (3) (1)\Oppor…’. It’s possible the file is already open, or you don’t have permission to open it.
To check your permissions, right-click the file folder, then click Properties.
The file wasn’t open anywhere else, and permissions were fine. Checking Properties, as the dialog itself suggests, tells you nothing, because the file is only unreachable at the exact length its full path happens to be.
Second, in Explorer, copying a batch of subcontractor collateral warranty redlines within a OneDrive-synced SharePoint library:
1 Interrupted Action
The source and destination file names are the same.
That message is actively misleading. The source and destination filenames were not the same, they were two different documents in a folder several levels deep under 1. Live Deals\Project Site A\Legals\Subcontractor CWs\CW Redlines\. Explorer’s error picker seems to fall back to “names must match” as a guess when the real cause, the combined path exceeding the limit, isn’t one of the messages it knows how to surface.
Neither error says anything about path length, which is exactly why this one wastes so much time: everything about the message points a user toward permissions or a duplicate filename, and both are red herrings.
Why this happens, and why one registry key won’t fully solve it
Windows has a legacy limit of 260 characters for a full file path (MAX_PATH), a holdover from MS-DOS. Search either error above and you’ll quickly find the fix everyone recommends: set LongPathsEnabled to 1 at
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\FileSystem
which raises the ceiling to roughly 32,767 characters for apps that support it. Worth doing, but it comes with two catches that matter here.
First, it needs the app itself to opt in via its manifest (longPathAware), and Explorer’s support for it is inconsistent: users can generally browse and open files past 260 characters once it’s set, but still can’t reliably create or copy new files that push a path over the limit, which is exactly the “interrupted action” case above.
Second, and this is the one that actually bit both cases here: OneDrive and SharePoint enforce their own limits, separate from Windows. A synced OneDrive path is capped around 400 decoded characters, individual file and folder names at 255 characters, and the sync client itself at roughly 520 characters for sync root plus relative path combined. LongPathsEnabled doesn’t touch any of that. A deal room structure like the CW Redlines example, deal name, a Legals sub-folder, a Subcontractor CWs sub-folder, a CW Redlines sub-folder, then a filename that repeats the full counterparty name in every document, blows past OneDrive’s own ceiling long before Windows’ 260-character limit even becomes the binding constraint.
Fix your folder hierarchy
In order of what to try:
1. Shorten the sync root first. The single highest-impact change is cutting the fixed prefix every synced file inherits. A path like C:\Users\J Smith\Client Dropbox\J Smith\ eats a large chunk of the budget before a single deal folder is even named. Moving the sync location, or renaming the top-level library folders in SharePoint (which cascades to everyone syncing it), removes that overhead from every file at once rather than one at a time.
2. Flatten or rename the deepest folders and filenames. For both cases above, the fastest real fix, and what actually got the files reachable again, is trimming the deepest, most repetitive segments. Long, fully-spelled-out counterparty names repeated in both the folder path and every filename inside it are the single biggest offender; shortening those recovers the most characters per edit.
3. Enable LongPathsEnabled as a supporting measure, not the fix. Still worth setting fleet-wide, since it removes a class of failures in Explorer and other apps that do support it, and there’s no downside to leaving it on. Just don’t expect it to resolve a path that’s already over OneDrive’s own limit, because it won’t.
4. Push it fleet-wide. If one client’s folder structure triggers this, every user syncing that same library will hit it eventually, so this is a provisioning-time policy, not a one-off registry edit. If you’re running an RMM, push the registry key as a scripted deployment across the fleet. On Intune, deliver the same value as a configuration profile (Settings Catalog, or a custom OMA-URI policy against the same registry path) assigned to a device group. Either way, set it once for every managed endpoint rather than waiting for the next user to hit it.
The lesson for anyone structuring a SharePoint library from scratch: keep top-level folder names short and push detail into file metadata and views instead of ever-deeper nesting, and don’t repeat the full deal or client name in both the folder path and every filename beneath it. It’s a lot cheaper to design around the limit than to rename a live deal room three years in.