Worth a direct correction before anything else: the “one work or school account per device” limit that gets repeated for OneDrive sync is genuinely outdated — current OneDrive sync supports one personal account plus up to nine work or school accounts simultaneously on the same Windows device (macOS is more restrictive, limited to one business account per organization at a time, though multiple different organizations still work). This post already covers the file-size and file-count numbers correctly elsewhere on this site (see the Related Reading below for those); it stays specifically on what those two posts don’t cover — the corrected multi-account limit, what actually blocks a file from syncing due to required metadata, and how conflicts really get resolved once they happen.
In this post: Multi-account syncing: the real current limit · Required metadata columns block sync silently · How sync conflicts actually get resolved · Monitoring sync health as an admin · When would you actually use this? · Related reading
Multi-account syncing: the real current limit
Worth knowing this directly, since the old “one account at a time” advice leads people to unlink and relink accounts unnecessarily: on Windows, the OneDrive sync app currently supports one personal account plus up to nine separate work or school accounts running simultaneously, each with its own dedicated local sync folder — files from different tenants don’t merge into a single library, but there’s no need to sign out of one organization to sync another. macOS is the platform with a genuine current restriction: only one business account per organization can sync at a time there, though accounts from different organizations still coexist. Worth checking which platform a report of “can’t sync a second work account” is actually coming from before assuming it’s the same limitation — what’s a real constraint on macOS is not a constraint on Windows at all.
A library with a required metadata column doesn’t reject the sync outright — the file syncs down fine, but any edit made offline fails to sync back up until the required field is filled in through the browser, a genuinely confusing failure mode for anyone who doesn’t already know to expect it.
Required metadata columns block sync silently
Worth knowing this specific mechanism before it causes a confusing support ticket: a document library with a required column (a metadata field marked mandatory) syncs existing files down to a device without issue, but a new file created or edited locally, then synced back up, gets stuck rather than failing cleanly — OneDrive can’t write the file back into a library position that requires a value it has no way to supply from the local sync client. The fix isn’t on the sync side at all; it’s filling in the required field through the browser or the desktop Office app (both of which can prompt for it), not something PowerShell or the sync client itself can resolve. Worth checking a library for required columns before recommending it as a sync target for offline-heavy work, since this specific failure mode only shows up once someone actually hits it.
How sync conflicts actually get resolved
Worth knowing what actually happens rather than assuming SharePoint silently merges conflicting offline edits: when the same file is changed offline by two people (or on two devices under one account) and both versions sync back, OneDrive doesn’t attempt a content merge for anything other than co-authoring-aware Office file types being edited live. For a genuine offline conflict, it creates a second file with the device name or username appended to the filename, leaving both versions present rather than picking one and discarding the other. This is deliberately conservative — no data is silently lost — but it does mean “conflicting copy” files accumulating in a library is a sign of a real offline-editing pattern worth addressing (moving that team toward co-authoring in the browser or Teams, covered in the Best Practices for File Sharing content on this site) rather than something to just periodically clean up without changing the underlying habit.
Monitoring sync health as an admin
The OneDrive admin center’s Sync section (part of the SharePoint admin center) surfaces device-level sync errors — failed uploads, out-of-date client versions, and paused sync states — across the tenant without needing to ask each user individually what their sync icon looks like. For scripted checks, `Set-SPOTenantSyncClientRestriction` remains the real, current cmdlet for the admin-configurable block list (specific file types or domains blocked from syncing tenant-wide), distinct from the file types the sync client itself never syncs regardless of policy (`.tmp`, `.ini`, `.lnk`, and similar) — worth confirming which category a “file won’t sync” report actually falls into before troubleshooting the wrong layer.
When would you actually use this?
- A user reports being unable to sync a second work account — check the platform first; it’s a real limitation on macOS specifically, not on Windows.
- Files sync down but edits won’t sync back up on a specific library — check for a required metadata column before assuming a broader sync failure.
- “Conflicting copy” files are accumulating in a heavily offline-edited library — treat it as a signal to move that workflow toward co-authoring, not just a cleanup task.
- Troubleshooting a tenant-wide sync complaint — the OneDrive admin center’s Sync section gives a faster, centralized view than asking each affected user to describe their local sync state.
Related reading
- OneDrive Cloud and Sync Limitations — the file-size, file-count, and version-history numbers this post assumes.
- o365 SharePoint Online and File Sync Limitations — naming rules, blocked file types, and the 260-vs-400-character path nuance.
- File Sharing Best Practices — where the co-authoring alternative to heavy offline editing is covered in full.
The numbers that usually get quoted for SharePoint sync — file size, file count, path length — are covered elsewhere on this site and worth reading alongside this one, not instead of it. What’s worth taking from here specifically: the multi-account limit most people repeat is stricter than what actually ships today, a required metadata column is a genuinely silent way to block a sync-back, and a pile of “conflicting copy” files is a symptom worth addressing at the workflow level, not just cleaning up after the fact.
App Catalog Authentication Automation Backup Compliance Content Type CSS Flows Google Javascript Limitations List Metadata MFA Microsoft Node NodeJs O365 OneDrive Permissions PnP PnPJS Policy PowerApps Power Automate PowerAutomate PowerPlatform PowerShell React ReactJs Rest API Rest Endpoint Security Send an HTTP Request to SharePoint SharePoint SharePoint List SharePoint Modern SharePoint Online SPFX SPO Sync Tags Teams Termstore Versioning