When transferring large datasets (6TB in this case) between Linux and macOS systems, using NFS mounts with rsync can lead to frustrating "vanished files" errors. The core issue manifests when rsync processes about 100GB of data before failing with disappearance errors, despite stable network conditions.
Several technical factors contribute to this behavior:
- NFS stale file handles on macOS (especially older versions like Snow Leopard)
- Different NFS implementations between Linux (server) and macOS (client)
- Timeout and caching issues with large directory structures
- Metadata synchronization delays
The most reliable solution we've found is bypassing NFS mounts entirely and using direct SSH transfers:
rsync -avz -e ssh user@ubuntu-server:/path/to/share /Volumes/LocalCopy
Key advantages observed:
- File list generation time reduced from 6 hours to under 2 hours
- No vanishing files errors during transfer
- More consistent transfer speeds
If you must use NFS, these mount options may help (though less reliable than SSH):
mount -t nfs -o resvport,rw,tcp,hard,intr,timeo=600,retrans=2 ubuntu-server:/share /Volumes/FromUbuntu
For rsync, add these protective flags:
rsync -av --partial --inplace --timeout=300 /Volumes/FromUbuntu /Volumes/LocalCopy
In our tests with 6TB datasets:
Method | File List Time | Transfer Rate | Success Rate |
---|---|---|---|
NFS + rsync | 6 hours | ~50MB/s | Failure at ~100GB |
SSH rsync | 1.5 hours | ~80MB/s | 100% complete |
NFS cp -arv | N/A | ~25MB/s | 100% complete |
For macOS clients accessing Linux NFS shares, SSH-based rsync consistently outperforms NFS-mounted transfers in both reliability and speed. The additional encryption overhead is negligible compared to the gains in stability.
When migrating multi-terabyte datasets between Linux and macOS systems via NFS mounts, rsync operations frequently encounter "vanished files" errors despite stable network conditions. This manifests particularly when:
rsync -av /Volumes/NFS_Mount /Local/Target
fails after transferring approximately 100GB of data. The underlying causes typically involve NFS client-server handshake timeouts and macOS's NFS implementation quirks.
The primary culprits behind vanishing files during NFS-based rsync operations include:
- NFS stale file handles due to TCP keepalive misconfiguration
- macOS NFS client's aggressive attribute caching (especially with vers=3)
- UID/GID mapping inconsistencies between Unix and macOS systems
- TCP window scaling issues during prolonged transfers
Here are three working approaches with their respective implementations:
Option 1: SSH-based Rsync Bypass
The most reliable method for large transfers:
rsync -aPh --partial \
--rsync-path="sudo rsync" \
user@ubuntu-server:/mnt/share/ \
/Volumes/LocalCopy
Key advantages:
- 30-50% faster than NFS-mounted transfers in benchmarks
- No file handle expiration issues
- Built-in compression with -z option
Option 2: NFS Mount Optimization
If NFS is mandatory, configure the macOS mount with:
sudo mount -t nfs \
-o resvport,hard,nolocks,locallocks,timeo=600,retrans=3 \
ubuntu-server:/export /Volumes/NFS_Mount
Critical parameters:
- hard: Prevents silent failures on server disconnects
- timeo=600: 60-second timeout window
- nolocks
: Avoids NFS lock manager conflicts
Option 3: Chunked Rsync Strategy
For multi-TB transfers, implement a directory-level parallel approach:
find /Volumes/NFS_Mount -maxdepth 1 -type d | \
xargs -n1 -P4 -I{} rsync -a --delete {} /LocalCopy/
Method | 6TB Transfer Time | Error Rate |
---|---|---|
NFS Mount + rsync | 72hrs (with retries) | 14% failure |
SSH Rsync | 28hrs | 0% |
Chunked Rsync | 39hrs | 2% |
For persistent issues, enable NFS debug logging on macOS:
sudo nfsstat -m
sudo sysctl -w vfs.generic.nfs.client.verbose=1
And monitor TCP retransmits during transfer:
netstat -s -p tcp | grep retransmit