Microsoft OneDrive is widely used for syncing documents across devices, but on macOS, it can silently fail to sync certain files if they violate Windows filesystem rules — like overly long paths or invalid characters. This creates frustrating experiences for end users who don’t know why files aren’t syncing.
To address this issue, I created a script — check_onedrive_paths.zsh — which detects common pathing issues and logs them to a file for JAMF or local review.
🔍 What the Script Does
This Zsh-based script is designed to scan a user’s OneDrive directory and:
- 🚫 Detect filenames with Windows-incompatible characters (like
*,:,?,|, etc.) - 📏 Identify file paths exceeding the maximum path length (400 characters)
- 🔠 Flag individual filenames that exceed macOS filesystem length limits (255 characters)
- 🪄 Optionally shorten long filenames automatically to prevent sync issues
A log file is written to /Users/Shared/onedrive_path_check.log and displayed at the end of the run for JAMF integration.
📁 How It Works
- Defines Limitations:
- Max path length: 400
- Max filename length: 255
- Invalid characters defined as a pattern:
[*:<>?/\\|"]
-
Looks Up the Logged-In User: Uses
stat -f %Su /dev/consoleto find the current user and determine their OneDrive directory path. - Recursively Scans Files:
Uses
findto inspect all files in the OneDrive directory and:- Reports invalid characters
- Logs overly long paths
- Shortens names if the
shorten_filename()function is triggered
- Outputs a Log: The log summarizes every issue found, making it easy for IT to take action.
🛠 Example Output
OneDrive Path Check - Mon Jul 14 10:23:45 EDT 2025
Invalid characters: /Users/jon/Library/CloudStorage/OneDrive/file:backup.docx
Path too long (405 chars): /Users/jon/Library/CloudStorage/OneDrive/very/deep/nested/folder/structure/that/keeps/going/on/and/on...
Filename too long (280 chars): /Users/jon/Library/CloudStorage/OneDrive/photos/this_is_a_very_very_very_very_long_filename_that_should_probably_be_shortened.jpg
⚠️ Why This Matters
Microsoft OneDrive follows stricter pathing and filename rules due to its underlying Windows-based architecture. macOS doesn’t naturally enforce these, so users can create files that OneDrive won’t sync — with no clear error message.
This script provides an automated way to detect and optionally fix these issues, ideal for use in:
- JAMF Pro policies
- IT onboarding scripts
- Scheduled maintenance routines
🔄 Customization
You’ll want to modify this section of the script to match your OneDrive setup:
ONEDRIVE_FOLDER_NAME=""
Replace with your folder name (e.g., "OneDrive - CompanyName").
You can also tune the limits or logging path to suit your environment.
📎 Get the Script
Keep your users syncing smoothly — and OneDrive compliant — by proactively checking for path issues!
Ready to take your Apple IT skills and consulting career to the next level?
I’m opening up free mentorship slots to help you navigate certifications, real-world challenges, and starting your own independent consulting business.
Let’s connect and grow together — Sign up here
AI Usage Transparency Report
AI Era · Written during widespread use of AI tools
AI Signal Composition
Score: 0.16 · Low AI Influence
Summary
Microsoft OneDrive is widely used for syncing documents across devices, but on macOS, it can silently fail to sync certain files if they violate Windows filesystem rules — like overly long paths or invalid characters. This creates frustrating experiences for end users who don’t know why files aren’t syncing.
Related Posts
Understanding GitHub Actions Before You Let Them Run
New to GitHub Actions? Learn what they are, where they come from, how AI uses them, and the review process I follow before trusting third-party Actions in production.
Audit Jamf API Roles Before They Become Forgotten Access
A read-only Jamf Pro API role audit script that reports role privilege reach, write-capable access, review priority, and API client inventory without changing Jamf.
Opening the Ollama Black Box: Understanding the Trust Boundary Behind Local AI
Installing Ollama is easy. Understanding the trust boundary behind a local AI service is what determines whether it belongs in an automation workflow.
Your Vibe-Coded App Still Needs a Trustworthy Release Path
Why vibe-coded apps still need release discipline: code signing, notarization, checksums, and GitHub artifact attestations all support integrity and user trust.
Secure Storage Isn't Enough: Using Secrets Safely in Admin Automation
Secret managers protect stored credentials. They don't automatically protect how your automation uses them. Here's the review process I use before workflows reach production.
What I Check Before I Trust a Homebrew Formula or Cask
Homebrew gives Mac admins a useful first-pass inspection workflow before trusting a formula or cask: check the source, checksum, version, tap state, availability, and upstream maintenance story.
Adobe in Jamf: To Package or Not to Package
A Jamf Pro workflow for deciding when Adobe software should be deployed as a manual Adobe package and when the Jamf App Catalog path is the better fit.
When a Local AI Tool Belongs in My Workflow and When It Stays in the Lab
Running AI locally on a Mac has become a real part of my workflow, but only once I stopped treating local models like general-purpose answers and started treating them like constrained components inside a system I can still inspect.
Discovering Mole: A Command Line Utility for Mac Cleaning
Caches pile up, apps leave behind junk, and disk space slowly disappears. While there are plenty of GUI tools out there, most of them either lack transparency or feel overly bloated.
Scoring AI Influence in Jekyll Posts with Local LLMs
There’s a moment that kind of sneaks up on you when you’ve been writing for a while, especially if you’ve started using AI tools regularly. You stop asking whether AI was used at all, and instead start wondering how much it actually shaped what you’re reading. That shift is subtle, but once you notice it, you can’t really unsee it.