Preventing Conflicts
The best way to manage conflicts is to design your sync architecture so they rarely occur. This lesson covers the most effective prevention strategies.
Conflicts happen when multiple writers edit the same file while disconnected. Eliminate either the "multiple writers" or the "disconnected" condition and you eliminate conflicts.
Prevention Strategy 1: Use Folder Types Correctly
The most powerful conflict prevention tool is the folder type. If only one node can write to a folder, conflicts are impossible by definition.
| Architecture | Conflict Risk | Pattern |
|---|---|---|
| All nodes: Send & Receive | High | Avoid for write-heavy folders |
| One node: Send Only; others: Receive Only | Zero | Master-source pattern |
| One node: Send & Receive; others: Receive Only | Zero | Read replicas |
Example: A team wiki where only the server edits content, and laptops only read:
Server (Send Only) ---wiki content---> Laptop A (Receive Only)
---> Laptop B (Receive Only)
No conflicts possible because only the server writes.
Prevention Strategy 2: Ensure Continuous Connectivity
Conflicts only form during offline periods. For production servers that should always be in sync:
- Ensure Syncthing services auto-start and stay running (
systemdwithRestart=on-failure). - Use a VPN mesh (WireGuard, Tailscale) to guarantee connectivity between nodes even across NATs.
- Use the Syncthing Relay fallback so nodes stay connected even without direct routing.
Check for nodes that go offline frequently:
- GUI → Device card → shows Last Seen timestamp.
- A device that was last seen days ago is a conflict risk.
Prevention Strategy 3: Avoid Simultaneous Edits
For human-edited content (documents, configs), establish a write-locking convention:
- Use applications that do file-level locking (most editors using temp file patterns, e.g., Vim's
.swp). Add these temp files to.stignore. - For structured databases or SQLite files: never sync the live
.dbfile. Instead, sync an exported dump or use Syncthing only when the app is stopped.
Never sync live SQLite databases or any file that is held open and written to by a running application. SQLite's WAL (Write-Ahead Log) pattern creates partial writes that Syncthing will see as mid-write states and sync into a corrupted state on peers.
# Add these to .stignore for WordPress / PHP applications
*.db-wal
*.db-shm
*.tmp
.~lock.* # LibreOffice lock files
~$*.docx # Microsoft Office temp files
Prevention Strategy 4: Sync Clocksclocks with NTP
The conflict winner is determined by file modification time. Clock drift between two devices can cause the wrong version to win.
# Check current time synchronization status
timedatectl status
# Expected output
# NTP service: active
# System clock synchronized: yes
# If NTP is not active, enable it
sudo timedatectl set-ntp true
# Verify which NTP server is used
chronyc tracking # for chrony
ntpq -p # for ntpd
Acceptable clock drift: < 1 second. Most modern systems with NTP active stay within milliseconds.
Prevention Strategy 5: Use application-level collaboration
For collaborative document editing, use a collaboration-native tool instead of syncing raw files:
| Tool Type | Example | Syncthing Role |
|---|---|---|
| Collaborative editor | Notion, HedgeDoc | None — collaboration is native |
| Version-controlled text | Git + Markdown | Sync the .git repo, or just use Git natively |
| Structured data | PostgreSQL | Never sync live DB; use pg_dump + sync the dump |
Syncthing is best suited for binary assets, static files, media libraries, and folders where only one device writes at a time.
Hands-On: Audit Your Conflict Risk
# Count existing conflict files — high numbers = architectural problem
find ~/Sync -name "*.sync-conflict-*" | wc -l
# Find the most conflict-prone files
find ~/Sync -name "*.sync-conflict-*" -printf '%f\n' \
| sed 's/.sync-conflict-.*$//' | sort | uniq -c | sort -rn | head -10
# Expected output (high risk example):
# 12 report.docx
# 8 notes.txt
Address the top conflict-prone files first — they reveal architectural misuse.