o365 SharePoint Online and File Sync Limitations

SharePoint Online syncs through the same OneDrive sync client as a personal OneDrive account, so a lot of the numbers overlap — for storage quotas, sharing controls, and version history, see OneDrive Cloud and Sync Limitations. This post covers the piece that’s specific to SharePoint document libraries: file and folder naming rules, what actually gets blocked from syncing, and the sync client mechanics that don’t show up until a library gets large or messy.

In this post: Invalid characters and reserved names · File types that won’t sync · The 260-character path nuance · Unique permissions slow sync down too · How many accounts can actually sync at once? · The 1 million item expansion · Related reading

Invalid characters and reserved names

The characters that will block a file or folder from syncing: " * : < > ? / \ |, plus leading or trailing spaces in a name. Two characters, # and %, used to be blocked outright but are now allowed by default on most tenants — an admin can still disable them, so a sync failure involving one of those two is worth checking against the tenant’s actual setting rather than assuming it’s a hard rule everywhere.

A less obvious source of sync failures: certain names are reserved regardless of what characters they contain — .lock, CON, PRN, AUX, NUL, COM0 through COM9, LPT0 through LPT9, _vti_, desktop.ini, and anything starting with ~$. Most of these are leftover Windows/DOS reserved device names, which is exactly why they surface unpredictably — a file legitimately named “com9-report.docx” syncs fine, but a folder literally named “COM9” doesn’t, and the resulting error rarely makes that distinction obvious.

File types that won’t sync

Two separate mechanisms block file types, worth telling apart when troubleshooting: the sync app itself never syncs .tmp, .ini, or .lnk files, full stop, regardless of tenant configuration — these are treated as local/transient by design, not organizational policy. Separately, a tenant admin can block additional file types tenant-wide (commonly executables and other security-risk types), which is a configurable list that varies by organization rather than a fixed set. A file that fails to sync with no obvious naming or path problem is worth checking against both of these before assuming it’s a bug. The admin-side block list is set with Set-SPOTenantSyncClientRestriction -ExcludedFileExtensions "ext1;ext2" — and worth knowing if you’re troubleshooting someone else’s blocked file: anything already synced to their device before the extension got blocked stays there and keeps syncing down, it just stops accepting uploads of new changes back up.

SharePoint’s own path-length limit is 400 characters, but the sync client running on a machine without long-path support enforces Windows’ older 260-character MAX_PATH constraint instead — a real gap between what the service allows and what actually syncs.

The 260-character path nuance

SharePoint Online’s own documented path-length ceiling is 400 characters, full site URL and folder hierarchy included. But that’s the service-side limit, not necessarily what the sync client on a given machine actually honors — the OneDrive for Business sync client enforces the older Windows MAX_PATH constraint of 260 characters on any machine that hasn’t opted into Windows’ long-path support. In practice, that means a deeply nested library can upload and browse fine through the browser, sitting comfortably under 400 characters, while the exact same folder structure fails to sync on a workstation that’s never had long paths enabled — a genuinely confusing mismatch if you’re only checking against the number SharePoint itself documents.

Unique permissions slow sync down too

A library-design decision that shows up as a sync problem, not just a permissions one: SharePoint supports up to 50,000 unique permission scopes on items within a single list or library, but the recommended practical ceiling for good performance is 5,000. Past that, load times and sync reliability both degrade, and it’s not just a UI slowdown — a user’s unique permission entry counts toward that total even if they only have access to a handful of documents in an otherwise large library. A library that’s accumulated hundreds of individually-broken-permission folders over time is a common, avoidable cause of a sync client that’s noticeably slower than a similarly-sized library with clean, inherited permissions.

How many accounts can actually sync at once?

Worth knowing for anyone syncing libraries from more than one organization on the same device: a single device supports syncing one personal OneDrive account plus up to nine separate OneDrive for work or school accounts concurrently. That ceiling matters more than it used to now that syncing individual SharePoint libraries (not just a personal OneDrive) is common — someone syncing several project libraries from the same tenant is still just using one of those nine account slots, but syncing libraries across several different client tenants can genuinely hit the limit. On macOS the constraint is tighter still: only a single business account from one organization can be actively syncing at a time.

The 1 million item expansion

The 300,000-item sync ceiling referenced elsewhere is already changing: Microsoft began rolling out expanded OneDrive sync support for up to 1 million items per device on Windows, in public preview starting in April 2026 — a genuinely large jump aimed at organizations with libraries that were bumping into the old ceiling. Devices that don’t meet the requirements for the expanded support stay on the existing 300,000-item behavior with no change, so this isn’t a blanket increase yet — worth checking current rollout status and device eligibility before planning around the higher number as if it’s already universal.

OneDrive Cloud and Sync Limitations — storage, sharing, and version-history limits this post doesn’t repeat.

Most sync failures trace back to one of these — an invalid character, a reserved name, a path that’s fine by SharePoint’s own rules but not the sync client’s — rather than an actual bug, and checking against the specific limit involved is usually faster than assuming the tool is broken.