Why Does Cloud Sync Say Complete When Files Are Missing From a Home NAS?

Eva Wong is the Technical Writer and resident tinkerer at ZimaSpace. A lifelong geek with a passion for homelabs and open-source software, she specializes in translating complex technical concepts into accessible, hands-on guides. Eva believes that self-hosting should be fun, not intimidating. Through her tutorials, she empowers the community to demystify hardware setups, from building their first NAS to mastering Docker containers.

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

  1. Pause two-way sync on all participating devices.
  2. Export logs, task settings, and file inventories.
  3. Copy unique NAS-only and cloud-only files into separate quarantine folders.
  4. Recover deleted or conflicted versions before relinking the task.
  5. Correct scope, permissions, path names, or placeholder handling.
  6. Run a dry comparison or one-way test on a small folder.
  7. 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

Get More Builds Like This

Stay in the Loop

Get updates from Zima - new products, exclusive deals, and real builds from the community.

Stay in the Loop preferences

We respect your inbox. Unsubscribe anytime.