Rsync copies from scratch on mounted NAS drives because the filesystem lacks reliable timestamp or inode metadata, forcing rsync to compare file sizes and modification times which may appear mismatched. This typically occurs with CIFS/SMB mounts where attribute support is limited or misconfigured. The fix involves verifying mount options, ensuring consistent client-server time synchronization, and using the --size-only flag as a diagnostic step to isolate timestamp issues.
Understanding Why Rsync Skips Incremental Updates
Rsync relies on two primary pieces of metadata to determine if a file has changed: the modification time (mtime) and the file size. When you run rsync against a local directory, it can quickly check these attributes. However, when dealing with network-mounted storage like a Network Attached Storage (NAS) device, the underlying protocol often fails to provide accurate or consistent metadata.
The most common culprit is the Common Internet File System (CIFS), also known as SMB. By default, many Linux distributions mount CIFS shares with options that do not preserve Unix-style timestamps accurately. If the server reports a timestamp in seconds but the client expects nanoseconds, or if the timezone settings differ between the client machine and the NAS, rsync sees every file as "new" or "modified." Additionally, some NAS implementations do not support the full set of POSIX file attributes required for efficient incremental transfers. This leads to the frustrating behavior where rsync appears to ignore existing files and re-transfers everything from scratch, consuming bandwidth and time unnecessarily.
Another factor is the difference between NFSv3 and NFSv4. While NFS generally handles metadata better than CIFS, version differences can still cause inconsistencies. If your NAS exports an older NFS version, timestamp resolution might be lower, leading to false positives in change detection. It is crucial to understand that this is rarely a bug in rsync itself, but rather a limitation in how the remote filesystem exposes data to the local system.
Verifying Timestamp Accuracy
Before changing rsync commands, you must confirm that the timestamps on the mounted drive are actually incorrect. You can do this by creating a test file locally and copying it to the mount point, then checking its properties. Use thestat command on both the source and destination files. Look specifically at the Modify field. If the times differ by more than one second, or if the timezone offset is wrong, rsync will always see a discrepancy.
You can also use the ls -l command to view the modification times. Compare the output before and after a copy operation. If the time updates correctly upon write, the issue lies in how rsync reads them during comparison. If the time does not update or shows garbage values, the mount configuration needs adjustment. This diagnostic step helps distinguish between a rsync configuration error and a fundamental filesystem metadata failure.
Configuring Mount Options for Metadata Support
The first line of defense is to ensure your mount options allow for proper timestamp handling. For CIFS mounts, thevers=2.1 or vers=3.0 parameter is critical. Older versions like vers=1.0 have poor support for modern timestamp features. Furthermore, adding nobrl can sometimes improve performance, but it does not directly fix timestamp issues. Instead, focus on dir_mode and file_mode to ensure permissions are handled consistently, though this is secondary to time sync.
For NFS mounts, ensure you are using NFSv4 if supported by your NAS. NFSv4 provides better atomicity and timestamp consistency compared to NFSv3. Check your /etc/fstab or mount command. If you are using automounts, verify that the daemon is passing the correct version flags. Incorrect version negotiation is a frequent source of silent failures where rsync falls back to less efficient protocols.
If you cannot change the NAS export settings, you might try adding actimeo=0 to your CIFS mount options. This forces the kernel to fetch fresh attributes from the server for every access, which can help if stale cache data is causing mismatches. However, this comes with a performance penalty. It is a trade-off between speed and accuracy. In many cases, simply upgrading the CIFS version resolves the core timestamp drift without needing aggressive caching policies.
Adjusting Rsync Commands for Network Instability
If mount options alone do not solve the problem, you can adjust the rsync command to bypass strict timestamp checking. The--size-only flag tells rsync to only compare file sizes, ignoring modification times entirely. This is useful if you trust that any size change indicates a real update. However, be cautious: if you edit a file without changing its size (rare but possible with some editors), rsync will skip it. Use this only for diagnostic purposes or if you know your workflow changes file sizes reliably.
A more robust approach is to use the --checksum option (-c). This forces rsync to calculate a hash of the entire file content rather than relying on metadata. While this guarantees correctness, it is significantly slower because it requires reading the entire file. For large datasets, this can negate the benefits of incremental backups. Use -c only for small files or critical data where integrity is paramount over speed.
Another powerful tool is the --ignore-times flag, though it is rarely used in production. It effectively disables all timestamp checks, treating every file as new unless combined with other filters. A better alternative is to use --modify-window. By default, rsync considers two files identical if their timestamps are within one second of each other. On slow networks or with imprecise clocks, increasing this window to 5 or 10 seconds can prevent unnecessary transfers. For example, --modify-window=10 allows for minor clock drift.
Synchronizing System Clocks
Regardless of the flags you use, clock synchronization is non-negotiable for reliable rsync operations. Ensure that both your client machine and the NAS device are synchronized to the same NTP server. Even a few minutes of drift can cause massive false-positive detections. Usechronyd or systemd-timesyncd on your Linux client to maintain accurate time. Check the NAS documentation for its own time synchronization settings. Many enterprise NAS devices allow you to configure an NTP server directly in the admin panel. Aligning these clocks eliminates the most common cause of "copy from scratch" behavior.
Troubleshooting Specific Scenarios
Sometimes the issue is not timestamps but inode numbers. Some older or poorly implemented filesystems do not support stable inodes across reboots or remounts. If rsync is configured to use inodes (which it does by default for hard links), this can cause confusion. While rsync primarily uses mtime/size, certain link-related options can trigger inode checks. Disabling hard link creation with--no-links can help isolate this issue.
If you are moving data between different operating systems, such as Windows to Linux, be aware that Windows uses a different timestamp resolution (100-nanosecond intervals) compared to Linux (seconds or nanoseconds). This mismatch can lead to rounding errors. Using the --modify-window flag becomes even more important in cross-platform scenarios. Always test with a small subset of files first to validate your configuration before running full backups.
For those experiencing hangs or extreme slowness alongside the copy-from-scratch issue, refer to our guide on fixing FFmpeg transcode issues on CIFS mounts, as similar network stack problems can affect various tools. Additionally, if you are dealing with sparse files that grow unexpectedly after transfer, check out our article on shrinking sparse files in Linux to manage disk space efficiently.
Frequently Asked Questions
Why does rsync copy files even if they haven't changed?
This usually happens because the modification times reported by the network share do not match the local cache or the source exactly. Network protocols like CIFS often have lower precision or different timezone interpretations than local ext4 or xfs filesystems. Verifying the timestamps with stat confirms if this is the root cause.
Is the --size-only flag safe to use for backups?
--size-only is safe only if you are confident that no files are modified without changing their size. It ignores timestamps completely, so if you overwrite a file with identical content and size, rsync will skip it. It is best used for diagnostics to isolate timestamp issues rather than as a permanent backup strategy.
How do I fix timestamp drift on a CIFS mount?
You can mitigate drift by ensuring both client and server use NTP synchronization. Additionally, adding actimeo=0 to your mount options forces fresh attribute retrieval, reducing stale cache effects. Upgrading the CIFS version to 2.1 or higher in your mount command also improves timestamp handling capabilities.
What is the difference between rsync on NFS vs CIFS?
NFS generally offers better metadata consistency and faster attribute checks than CIFS, especially with NFSv4. CIFS can suffer from latency in attribute retrieval and stricter permission mappings that interfere with rsync's delta algorithm. If possible, prefer NFS for rsync targets to minimize overhead and metadata discrepancies.
Can I force rsync to use checksums instead of timestamps?
Yes, using the --checksum or -c flag forces rsync to compute a hash of the file contents. This ensures accuracy regardless of metadata errors but is much slower as it requires reading the entire file. Use this sparingly for critical data or small files where speed is less important than absolute integrity.