📁 Recipe · SharePoint & OneDrive
Replicate Synology NAS Data to a SharePoint Site with Cloud Sync
Use Synology DSM's native Cloud Sync package to push, pull, or bidirectionally sync NAS folders with a SharePoint Online document library
Complexity
Intermediate
Impact
storage + collaboration + hybrid-cloud + data-replication
Context
Why This Matters
Many organizations use a Synology NAS as primary on-premises storage but want specific folders — project files, departmental shares, archive data — to be continuously replicated to a SharePoint Online site. This gives users cloud access, enables collaboration through the Microsoft 365 stack, and provides an off-site copy for resilience.
Synology DSM ships a free package called Cloud Sync that connects natively to Microsoft SharePoint Online. It supports one-way (upload-only), one-way (download-only), or bidirectional synchronization on a schedule or in real time. This recipe walks through configuring Cloud Sync against a SharePoint site and highlights the pitfalls (filename restrictions, path length, permissions) that commonly break the first sync attempt.
When to use this recipe
- You want NAS folders mirrored into a SharePoint document library for cloud access.
- You need an off-site replica of NAS content that fits inside your existing M365 tenant.
- You're implementing a hybrid workflow where some users edit on the NAS (SMB) and others edit in SharePoint/Teams.
When not to use this recipe
- You want to back up SharePoint to your NAS — use Active Backup for Microsoft 365 instead (opposite direction).
- You need a tamper-resistant, versioned backup with retention — use Hyper Backup targeting object storage (S3/Azure Blob), not SharePoint.
Expected Outcomes
After completing this recipe you will have:
- The Cloud Sync package installed on your Synology NAS (DSM 6.1 or later).
- An authenticated connection from DSM to your Microsoft 365 tenant scoped to a specific SharePoint site.
- A configured sync task that maps a local NAS folder to a SharePoint document library with your chosen sync direction.
- Understanding of the filename, path-length, and permission limitations that affect SharePoint sync.
- A monitoring workflow — Cloud Sync logs and error reporting — so failed files are visible.
Risks & Considerations
Data and compliance risks
- Permissions do not replicate. NAS ACLs (SMB/AFP permissions) are not converted to SharePoint permissions. Anyone with access to the target library can read synced content. Review SharePoint site membership before the first sync.
- Sensitive data may leave on-prem. Uploading to SharePoint moves data into Microsoft's cloud — verify this is allowed by your data residency / classification policy.
- Bidirectional sync can cause deletion loops. If a user deletes a file in SharePoint and bidirectional sync is enabled, it will also be removed from the NAS. Start with Upload local changes only unless you specifically need two-way editing.
Technical gotchas
- Filename restrictions: SharePoint rejects names containing
* : < > ? / \ |and names likeCON,PRN,AUX. These files will be logged as errors and skipped. - Path length: SharePoint's full URL path limit is ~400 characters. Deeply nested NAS folders will fail partway through.
- File size: SharePoint caps single files at 250 GB. Disk images, VM files, and large archives may not sync.
- Throttling: Microsoft 365 throttles Graph/SharePoint traffic. Large initial syncs can take days and trigger temporary 429s — Cloud Sync will back off and retry.
- Token expiry: The OAuth token used by Cloud Sync can expire if the admin account's password is rotated or MFA policies change. Use a dedicated service account where possible.
Required Permissions
| Permission | Why It's Needed |
|---|---|
| Microsoft 365 account with access to the target SharePoint site | Cloud Sync authenticates via OAuth using this account; it must have at least Edit permission on the destination document library. |
| Site Owner on the SharePoint site (recommended) | Required to create/select the target document library and approve the OAuth consent on first connection. |
| DSM administrator on the Synology NAS | Needed to install the Cloud Sync package from Package Center and to create sync tasks. |
| Tenant admin consent (if organizational policy requires it) | Some tenants block third-party OAuth apps by default; a Global Admin may need to approve the Synology Cloud Sync app the first time it's used. |
The fastest way to get this done: just ask Dex. Copy the prompt below and paste it into your Dex conversation.
For IT Admins
Paste into Dex Pro
For End Users
How an employee would ask Dex for help
Configure Synology Cloud Sync to a SharePoint site
Step 1 — Install the Cloud Sync package
- Sign in to DSM as an administrator.
- Open .
- Search for
Cloud Syncand click Install. Wait for installation to complete, then click Open.
Step 2 — Prepare the SharePoint destination
- In a browser, sign in to Microsoft 365 Admin Center or go directly to the target SharePoint site.
- Create (or identify) the document library that will receive the files, e.g.
Documents/NAS-Replica. - Verify the signing-in account has at least Edit permission on that library.
Step 3 — Create the Cloud Sync task
- In Cloud Sync, click the + (Create) button in the left sidebar.
- From the provider list choose Microsoft SharePoint Online and click Next.
- A browser window opens — sign in with the Microsoft 365 account that has access to the target site and click Accept on the permissions prompt.
- Back in DSM, the Task Settings dialog appears. Fill in:
- Connection name: a friendly label, e.g.
SP-ProjectsSync. - Site: select the SharePoint site from the drop-down.
- Local path: browse to the NAS folder to replicate, e.g.
/volume1/projects. - Remote path: select the target library/folder, e.g.
Documents/NAS-Replica. - Sync direction: choose one:
- Bidirectional — changes on either side propagate.
- Upload local changes only — recommended for replication to cloud.
- Download remote changes only — mirrors SharePoint down to NAS.
- Data Encryption (optional): if enabled, files are encrypted client-side before upload — but they will only be usable through Cloud Sync and won't be readable in SharePoint. Leave OFF for normal replication.
- Connection name: a friendly label, e.g.
- Click Next, review the Advanced settings (scheduling, file-filter by extension/size, traffic control) and click Apply.
Step 4 — Monitor the initial sync
- The new task appears in Cloud Sync with a status of Syncing.
- Click the task and open the Log tab to watch file transfers.
- Errors (unsupported characters, paths too long, files too large) appear in red — export the log if needed and remediate.
- Once the queue clears, status becomes Up to date.
Step 5 — Verify in SharePoint
- Open the target document library in a browser and confirm files are present with correct timestamps.
- Spot-check a few files to ensure content is intact.
- Review SharePoint site Permissions and adjust sharing as needed — remember NAS ACLs do not propagate.
REST API approach
Not fully applicable for this recipe. Synology Cloud Sync is configured through DSM's GUI or its local synopkg/Cloud Sync CLI — there is no public Synology REST API for creating Cloud Sync tasks. Likewise, Cloud Sync itself uses the Microsoft Graph / SharePoint REST APIs under the hood; you don't invoke them directly.
If you want to replicate NAS content to SharePoint without Cloud Sync, the supported API-driven alternative is to upload files directly via the Microsoft Graph API:
PUThttps://graph.microsoft.com/v1.0/sites/{site-id}/drives/{drive-id}/root:/{path}:/content— small files (< 4 MB).POSThttps://graph.microsoft.com/v1.0/sites/{site-id}/drives/{drive-id}/root:/{path}:/createUploadSession— resumable upload for larger files.
This is a full custom integration (auth, change detection, retry, delta tracking) and is out of scope for this recipe. If you need API-level upload, use the script approach below or build on Graph directly.
Scripted approach — push a NAS folder to SharePoint via PowerShell
If you'd rather not use Cloud Sync (for example, you need a one-time migration or an ad-hoc push from a Windows jump box that has the NAS mounted), you can upload files directly to SharePoint with PnP PowerShell. The script below walks a local/UNC path and uploads each file into a target document library, preserving subfolder structure.
Prerequisites
- PowerShell 7+ on a Windows or macOS host with network access to the NAS share.
- PnP PowerShell module:
Install-Module PnP.PowerShell -Scope CurrentUser. - An M365 account with Edit rights on the target library (or an app registration with
Sites.ReadWrite.All). - The NAS folder mounted or accessible via UNC path, e.g.
\\synology01\projects.
How it works
- Connects to the target SharePoint site interactively (device-login).
- Recursively enumerates files under the source path.
- For each file, ensures the corresponding SharePoint folder exists, then uploads with
Add-PnPFile. - Logs successes and failures to a CSV for review.
The script is idempotent — rerunning it will overwrite files that already exist at the destination with the newer local copy (based on -Force). It does not delete files in SharePoint that no longer exist locally; that would require a delta/compare step.
Next steps