Cloud sync can say complete while files are missing because the status usually means the client has no remaining work under its current rules, not that every file on a home NAS has a matching usable copy in the cloud. The fastest diagnosis is to compare both inventories, then check task scope, exclusions, permissions, placeholder state, path compatibility, conflicts, and deletion history before forcing another sync.
What Does โCompleteโ Actually Confirm?
A completion badge is evaluated against the sync engine's selected roots, filters, error policy, and current database. It may not count files that were excluded before transfer, rejected by the destination, represented only as placeholders, or moved into a conflict path. A troubleshooting guide for missing files after a completed cloud sync separates job completion from inventory completeness.
On a ZimaSpace home server, first record the exact local root, remote root, sync direction, account, and task name. Two tasks with similar labels can point at different NAS folders or cloud directories, and a green status from the wrong task proves nothing about the missing path.
Identify Which Inventory Is Actually Missing Files
Check the file in three places: the source folder on the NAS, the cloud provider's web interface, and any desktop or mobile sync client. A client-side absence does not prove the cloud object is gone. One Nextcloud case describes folders that remained on the server while disappearing from one client, which was corrected by rebuilding that client's folder relationship.
Create a short table with relative path, size, modification time, and location state. Classify each item as NAS-only, cloud-only, visible on the web but not hydrated locally, conflict-renamed, or missing everywhere. Different states require different repairs.
Check Task Scope, Filters, and Size Rules
A task can be healthy and still ignore content outside its selection. Review included roots, excluded folders, filename patterns, maximum file size, hidden-file policy, symbolic-link policy, and direction. Reports of Cloud Sync showing โup to dateโ while the intended content never transfers show why the configured path and task database must be checked before assuming a network failure.
For a family NAS, generated thumbnails, application databases, recycle bins, Docker data, and hidden configuration folders should not be included automatically. The important requirement is that exclusions are intentional and documented, not that every filesystem object is copied.
Separate Placeholder Entries From Fully Available File Data
Some cloud clients show a filename and size without storing the complete contents on that device. An odrive support explanation notes that placeholder files may contain no usable data outside the managed sync folder. Copying such entries into a NAS ingest folder can create apparent files that cannot be opened or hashed as normal content.
Test by opening or explicitly downloading one affected item from the cloud interface. Confirm that its size becomes real on disk and that a checksum can be calculated. Do not count icons or directory entries as protected copies.
Check Filename, Path, and Destination Compatibility
A Linux-based NAS can store names that a cloud service, Windows client, or portable target rejects. Unsupported characters, reserved names, excessive path depth, trailing spaces, and Unicode normalization can cause skips. An interoperability reference lists filename and complete-path restrictions that vary by access method.
Search the detailed job log for skipped, invalid, unsupported, too long, not permitted, and cannot create. Export the problem paths before renaming anything so applications and household users can be told which references will change.
Review Conflict Copies and Deletion Propagation
When two devices edit a file before seeing each other's change, a sync tool may create a conflict copy, choose one version, or move content into a recovery area. Conflict symptoms include device-name suffixes, duplicate folders, and files present on the cloud web interface but missing on one computer. A practical analysis of duplicates and missing files caused by sync conflicts shows why conflict locations must be inventoried before cleanup.
Two-way sync also propagates deletions. Check cloud recycle bins, version history, NAS snapshots, and conflict folders before running a reset or re-link operation. A new sync from an already incomplete side can make the incomplete state authoritative.
Compare Counts, Sizes, and Hashes Instead of Trusting the Badge
Generate recursive inventories from the selected NAS root and cloud destination. Compare relative paths first, then sizes, and finally checksums for important files that both systems can read. Counts alone can hide one missing file and one unexpected duplicate.
This is the same principle used to detect a backup job that is silently incomplete: completion is an event, while completeness is a separately tested property.
Use a Low-Risk Recovery Sequence
- Pause two-way sync on all participating devices.
- Export logs, task settings, and file inventories.
- Copy unique NAS-only and cloud-only files into separate quarantine folders.
- Recover deleted or conflicted versions before relinking the task.
- Correct scope, permissions, path names, or placeholder handling.
- Run a dry comparison or one-way test on a small folder.
- Resume the full task only after both test inventories match.
| Observed State | Likely Cause | Next Check |
|---|---|---|
| NAS file exists; cloud file absent | Filter, permission, path, or upload error | Task scope and detailed transfer log |
| Cloud web file exists; desktop file absent | Client exclusion, placeholder, or stale database | Web download and client folder relationship |
| File has a conflict suffix | Concurrent edits or stale client state | Compare both versions before deleting either |
| File is absent on both active sides | Deletion propagation or cleanup | Cloud history, NAS snapshots, and recycle bins |
FAQ
Does cloud sync count as a backup?
Not by itself. Two-way sync can copy accidental deletion, corruption, or ransomware changes. Keep independent versions or backups outside the writable sync relationship.
Should hidden files always be synchronized?
No. Some are disposable caches or system metadata, while others contain application configuration. Decide by restore value rather than visibility.
How can you prove both sides are complete?
Compare normalized relative paths, sizes, and selected checksums, then restore and open representative files from the cloud side.
Final Takeaway
Cloud sync can be complete according to its configured rules while a home NAS and cloud destination still contain different usable files. Diagnose the exact missing location, verify scope and exclusions, distinguish placeholders from content, inspect conflicts and deletions, and compare inventories before resetting the task.
Support & Tips
More to Read

Can Plex Share a GPU With Another Docker Container?
Plex and another container can often access the same GPU, but you must test driver support, device mapping, video-engine load, memory, and recovery behavior.

How to Tell Whether a Plex Error Comes From the Client or Server
Reproduce the same item on another client, compare the session path, then collect server evidence only after scope tells you where the failure actually...

How to Configure Plex Cache and Transcode Temporary Storage
Protect persistent Plex state while placing transcode temp files on suitable local storage, then verify cleanup, free space, and restart behavior.

