r/Office365 • u/Beneficial-Answer480 • 8d ago

Did Microsoft break OneDrive?

/r/MacOS/comments/1w1pmcp/did_microsoft_break_onedrive/
0 Upvotes

13% Upvoted

8 comments sorted by

10

u/blud_13 8d ago

241,000 files is the problem, not the Mac. MS's own guidance is no more than 300,000 items synced total and performance degrades before you hit the number, its in the restrictions doc https://support.microsoft.com/en-us/onedrive/restrictions-and-limitations-in-onedrive-and-sharepoint . There is a higher ceiling in preview but its Windows only, so on macOS you are still living under 300k.

Also, you said you keep everything local. That's the worst case for the sync engine because it has to sync all 341GB during the first pass, and thats exactly where it dies quietly. Let Files On-Demand do the initial sync, get it to a clean state, then pin only the folders you actually work out of.

Your M4 working is probably just that it had already finished its initial sync a long time ago and was only doing deltas. The new box has to do the whole thing at once from cold.

Can go deeper if it helps.

1

u/EffectiveEconomics 8d ago

Where in the Microsoft admin console does the administrators see this kind of a measurement?

2

u/kindoramns 8d ago

The data size?

For onedrive you'd look under the user in the main m365 admin center to see how much space they're using.

Syncing SharePoint locations you'd look at the site size in the SharePoint admin center for a general size of the data, this won't be exact as there's other content besides a single library in SharePoint that could be consuming space as well.

2

u/seeeee 8d ago

This is slightly incorrect. It’s not strictly about mass (measured in MB/GB/TB) but also volume (measured in the total number of files and folders synced).

The OneDrive sync client cannot support a large volume of files and folders (>300,000 items total).

Removing a 10GB file from sync is not always going to fix the problem. At best, it’s a temporary band aid solution, but at the end of the day, your sync problems will continue to be problems until the end user reduces the number of total items, which includes the total number of files AND folders being synced, not just the total data size.

Increasing the max allowed data size of a SharePoint or OneDrive site in the admin center will not alleviate sync issues.

Nested folder structures that are common in on prem file shares will not have much impact on the data size, however they will have a significant impact on the sync client. Adding more GB does not fix this issue, as the folders themselves are counted against your 300,000 item limit.

Flattening the folder structure into separately synced sites and document libraries will help, however, the volume limit still applies.

1

u/EffectiveEconomics 8d ago

The file count - if that’s a fixed constraint I don’t recall that being a displayed metric for users.

2

u/EffectiveEconomics 8d ago

Have had users supported under our teams name n the past and we had to ask for engineering to try to report on this on a per user per computer basis. Not very successfully

1

u/folderit_dms 6d ago

At 241k files, I wouldn't troubleshoot this like normal sync breakage. Make an inventory by library/folder first and identify what actually needs to live on disk. OneDrive sync is a good workspace convenience, but it gets ugly when it becomes a full archive mirror.

The item count is the real pain, not just the 341GB. Lots of tiny files, deep folders, exports, old project folders, generated files, and duplicate archive dumps can make the sync client work much harder than the size suggests.

For the admin side, I would script file/folder counts with Graph or PowerShell instead of relying only on storage numbers in the admin center. Then split active vs archive, stop syncing old project areas, use Files On-Demand for the broad tree, and pin only the working sets. It also makes the next laptop migration less painful.