Synology Drive ShareSync Not Syncing All Files? Trace One Missing File
Synology Drive ShareSync not syncing files even when logs look clear? Trace one missing file through the source, Drive catalog, sync rules and destination.
If Synology Drive ShareSync is not syncing all files, trace one missing file before rebuilding the task. Check where it exists, whether Drive includes it, which sync rules apply and where it should arrive. A clear-looking log is not enough: Synology explicitly notes that ShareSync does not display unsynced events.
This guide addresses a selective problem: some folders or files appear at the other NAS, while particular expected files do not. If the full dataset is still arriving slowly, use the ShareSync speed diagnostic. If the task is new and comparing an existing dataset, the initial-seeding guide covers that separate situation.
Confirm that this is Drive ShareSync
Open the application running the job. Synology Drive ShareSync is the NAS-to-NAS application installed with Drive Server. DSM’s Shared Folder Sync is a separate one-way service under Control Panel. A Windows or Mac running Drive Client is a third case.
Use the ShareSync help for the NAS job. Do not apply a desktop-only file-attribute fix or a Shared Folder Sync setting simply because a search result calls all three “folder sync.” The NAS replication guide maps the wider choices if you are unsure which job was configured.
For the steps below, “source” means the NAS where the expected saved file exists, and “destination” means the NAS where it is missing. That description follows the file’s intended journey; it need not match which NAS the ShareSync interface calls local or remote.
Make one file into a traceable case
Record the NAS names, DSM and Drive Server versions, task direction, exact source path, expected destination path and the time you checked. Pick an ordinary saved file whose absence matters. Also identify a nearby file that arrived successfully.
For example, a completed Exports/final.mov and an absent Exports/captions.srt give you a useful comparison: both are under the same project, but their extensions and selected subfolders may be treated differently. These are example paths, not proof that either type is excluded by default.
Compare the actual intended files, not just folder totals. A folder can exist at the destination while only part of its contents is eligible for synchronization.
| Observation for the missing file | Check next | What the observation establishes |
|---|---|---|
| Present in source File Station, absent from the source Drive file list | Team Folder inclusion, supported path and Drive indexing | File Station visibility alone does not establish Drive eligibility |
| Present in source Drive, absent only from selected destination subfolders | Folder selection, filters and direction | The file is visible to Drive; task scope still needs checking |
| Ordinary files arrive, but content beneath a mounted folder does not | Whether that path crosses a local mount point | A visible folder is not necessarily a supported ShareSync source |
| The file exists at the destination, but a user cannot see or open it | Exact destination path and that user’s access | Delivery and user access are different checks |
The table narrows the next investigation; it does not identify a universal bug. Preserve the observations so a later change can be assessed against the same file.
Check eligibility in the actual NAS task
The menu names below follow Synology’s DSM 7.4 help. Match the labels and supported rules to your installed version.
In ShareSync, select the server and open Synced folders. Select the enabled task and choose Edit. Inspect Folder and File filter: confirm that the containing subfolder is selected and that extension or size rules include the intended file. In Drive Admin Console, also open Settings → User Sync Profiles and edit the relevant profile. If the connection account appears under Applied User, check that profile’s File Filter rules too.
In the export example, suppose Drive lists Exports/captions.srt, but the task selects only .mov files. The video can arrive while the caption stays outside the task’s scope. If captions are required, have the administrator include the supported .srt type in the rule that excluded it, while preserving unrelated exclusions. Then check the original caption at the intended destination. This is a filter example, not a claim that ShareSync excludes subtitles by default.
The current ShareSync documentation lists additional exclusions, including temporary/link file types and names beginning with a tilde. It also states that files beneath a locally mounted folder are not synchronized. A file visible through a mounted remote share therefore needs a different eligibility check from a file stored directly in the selected local folder.
Use the NAS-specific rules for your installed version. Do not rename a production application’s working files merely to evade an exclusion, or remove attributes indiscriminately. Check what the file does and whether the application offers a supported saved export.
Then confirm the required direction and permissions, using the local/remote names shown by ShareSync. If the connection account has read-only access to the remote shared folder, Synology documents download-only synchronization: changes on the local NAS will not upload. Check that account’s access on the remote shared folder if you need the reverse direction. A two-way requirement needs the appropriate write access; waiting longer will not change a read-only account’s permissions.
Separate the Drive catalog from the filesystem
Open File Station on the source NAS and locate the exact saved file. Next, look for that same path in Synology Drive using an account with appropriate access.
If the folder is not enabled as a Team Folder, correct the intended setup before treating it as a transport failure. If the file is supported and the folder is enabled but the two views disagree, follow Synology’s Drive and File Station inconsistency procedure.
That procedure has an administrator rescan Team Folders to reindex Drive’s file list, using a one-time DSM Task Scheduler task. Follow the current official instructions for the command and progress check; avoid scheduling the rescan to repeat. In the reported result, Total events in queue files reaching 0 indicates the rescan is complete. Then check the original path in Drive and at the destination again. A drained rescan queue alone does not establish that the missing file was delivered.
The distinction matters because copying bytes across the WAN is downstream of deciding which file Drive knows about. Changing router rules will not explain a source file that is absent from Drive’s own file list.
On the destination, use an authorized administrator view to distinguish “not delivered” from “delivered somewhere else” or “not visible to this user.” Do not broaden everybody’s permissions as a diagnostic shortcut.
Verify one correction without disturbing the evidence
After identifying a supported cause, change only the relevant rule or setting. If an administrator approves a control file, place a small saved sync-probe.txt in the same intended subfolder and confirm that the current task rules allow it. Observe both the new control and the original missing file.
For a suspected extension filter, use an approved control of the same supported file type as the missing file where possible. A .txt control arriving does not establish that .srt files are allowed. Keep the path and relevant rules comparable so the result answers the question you are investigating.
A successful new control proves that a new eligible file can arrive through that path. It does not prove every older file has been reconciled. If new files arrive but an eligible old file still does not, record that distinction and retain the task history for support.
Avoid moving the entire production tree out of the sync root and back in, unlinking the connection, or deleting the database as the first experiment. Synology’s ShareSync help says database deletion removes previous local task history and settings while leaving the local files. That is a state-changing operation, not a harmless refresh.
The useful completion condition is specific: the original expected file exists at the correct destination, its saved content is correct, and the intended user can use it. Folder counts or an empty error list do not replace those checks.
Give support a case they can reproduce
If the eligible file remains missing, prepare a small set of affected paths alongside a successful comparison file, versions, direction, relevant rule settings and observation times. Generate the supported DSM/Drive logs and send them only through your approved support channel; logs and paths can reveal private project information.
A report such as “this source file is in File Station and Drive, is included by these rules, and is absent at this destination after a new control file arrived” gives support a clearer starting point than “ShareSync says everything is fine.”
Keep that file-level case intact. It tells you which layer still needs an answer without discarding the task’s history.
Frequently asked questions
Can ShareSync show no errors while some files are missing?
Yes. Synology’s troubleshooting note says Drive ShareSync does not display unsynced events. A log without an entry for a missing file is not proof that the file was eligible or transferred. Check its actual path, rules and destination.
Why can I see a file in File Station but not in Synology Drive?
File Station visibility and the Drive file list are different observations. Confirm the file is in an enabled Team Folder and supported for synchronization. If those checks pass, use Synology’s file-list inconsistency procedure rather than assuming the WAN failed.
Should I delete the ShareSync database to fix missing files?
Do not start there. Synology documents that deleting the local database removes previous task history and settings while leaving local file data. Preserve the task configuration and missing-file evidence, and investigate the supported cause first.