Syncthing not syncing with an online peer requires checks at both the device and folder levels. Confirm the intended devices share the same folder, let scanning finish, inspect local errors, and verify one file's contents rather than relying on the connection indicator.

Key Takeaways:

A connected device does not prove the intended folder is shared and writable on both ends.

Scanning, local file errors, discovery, and transfer connections are separate stages.

A relay is a supported connection path, not evidence of a broken installation.

Judge recovery by matching file contents on the two devices and the observed connection type.

Why is Syncthing not syncing even when a device is online?

A device connection and a folder's synchronization state answer different questions. You may have a reachable peer while the intended folder is not shared, paused, scanning, or unable to write files locally. The official FAQ describes folder troubleshooting and explains why synchronization should not be treated as an independent backup.［1］

Use the table before changing discovery or firewall settings. If several unrelated applications also fail, begin with the device and application troubleshooting branches. Otherwise, record the exact peer, folder ID, and error in this Syncthing task.

Observation	Investigate first	Evidence needed to move on
Peer is connected but target folder is absent	Sharing and matching folder ID	Intended folder is accepted on both devices
Folder reports scanning	Local indexing progress	Scan finishes and reports the expected file
Folder reports a local error	Storage, permissions, marker, or path	Actual local failure is resolved safely
Peer is disconnected	Device ID, discovery, and allowed addresses	Intended peer establishes an authorized connection
Relay connects but files remain out of sync	Folder state and file-level errors	The identified file is delivered and readable

Step 1: Do both devices share the intended folder?

Open each device's local Syncthing interface through its normal protected access method. Compare the device IDs with the pair you intend to synchronize, using your own records or a trusted channel.

Check the folder ID on both devices and confirm that the folder is shared with the intended peer at both ends. Local labels and filesystem paths can differ, so compare the actual folder identity rather than assuming similarly named directories are the same relationship. Inspect any pending sharing invitation without accepting an unrelated folder.

Review whether the device or folder is paused and whether the local folder type intentionally limits what it sends or receives. Do not change a deliberate send-only or receive-only arrangement simply to make status look symmetrical. Ask the folder owner what behavior is intended before altering the configuration.

How should you protect existing versions?

Stop editing files in the affected folder and copy valuable local work into an independent backup location. Keep any conflicting versions and open the backups to verify their contents. Syncthing propagates changes and deletions, so a second synchronized device does not automatically protect you from an accidental edit.［1］

Do not remove and re-add the folder, rename the directory, or reset its database as an initial connection test. Those actions change reconciliation conditions and may affect which files appear new.

Step 2: Has scanning finished, or is a local error blocking progress?

Read the folder status on each device separately. If one is scanning a newly added or changed tree, wait for that work to finish and observe whether the status advances. A scan enumerates local content; repeatedly changing networks does not fix a scanner that cannot read the filesystem.

Check the displayed local file errors, free disk space, and accessibility of the configured path. A folder on removable storage must actually be mounted at the expected location. Confirm read and write permission appropriate to the folder's intended role without granting broad access to the entire drive.

The official FAQ discusses the folder marker, normally .stfolder, and warns about file-cleaning tools that remove it. A missing marker can indicate a missing or unhealthy folder, so do not create it blindly before confirming that the correct storage is present. Otherwise you can hide the reason the safety check stopped the task.［1］

What if only a few items remain out of sync?

Inspect the listed filenames and reasons. A locked file, excluded path, permission failure, or conflict needs file-level handling even if the peer connection is healthy. Keep the diagnostic attached to those items; do not rebuild every folder because one file failed.

For notes stored in a folder, distinguish this setup from the service discussed in the Obsidian Sync connection guide. Syncthing is a separate synchronization mechanism, and success here does not diagnose or repair Obsidian's hosted service. Avoid placing multiple synchronization systems over the same working tree during testing.

Step 3: What does the Syncthing relay connection tell you?

Inspect the remote device's connection details and note whether the active link is direct or relayed. A Syncthing relay connection carries traffic when a direct path is unavailable; the official relay guide explains that file contents remain encrypted end to end and that relay throughput can vary. A relay is not a reason to reinstall the application.［2］

Discovery helps devices find addresses, while the transfer connection carries synchronization data. Successfully discovering a peer is therefore different from delivering a file. Conversely, a functioning relay connection can be enough for transfer even when a direct link is unavailable.

If the Syncthing device disconnected status appears, verify that the remote computer is awake and its Syncthing process is running. Confirm that both ends are allowed to use the configured discovery and relay services. Organization firewalls or device-management policies may require administrator approval rather than user-side workarounds.

Should you force a direct connection?

No direct connection is required merely to diagnose whether synchronization works. Record the current link type and evaluate actual file progress. The FAQ notes that Windows network profiles can affect direct connectivity, but that does not authorize marking an untrusted public network as private.［1］

On Windows, compare the system proxy configuration with the organization's requirements if other internet access differs. Do not assume a browser's proxy setting governs every Syncthing connection. Leave required security controls enabled and report blocked protocols to the responsible network owner.

Step 4: Can an approved public path deliver the same test file?

Enter this branch only when folder sharing, scanning, and local storage are ready and the evidence points toward public discovery or relay reachability. If the intended peer is reachable only on an enterprise private network, retain its approved access method. A public consumer VPN does not provide membership in that network.

Create a small nonconfidential test file with a unique name in the shared folder on one device. Give it distinctive contents and allow the local scan to notice it. Keep the sender, receiver, device IDs, folder ID, client versions, and file unchanged while you record the baseline result.

For a permitted public-path test, connect AethoVPN on the supported computer whose discovery or relay access is failing. Use the official Windows installer or the .deb package on Debian/Ubuntu x64; Mac requires the official setup guide, a VPN client, and Pro or Premium. Enable global mode, select an available nearby location, and allow Syncthing to reconnect before observing that same file's transfer.

Use a connection check with an application-level result and return to both Syncthing interfaces. Record the actual connection type after the change. Then inspect the receiver's file and compare its contents with the sender; do not substitute a changed public IP or a reachable website for this evidence.

This route comparison cannot repair a wrong folder ID, ignored file, disk error, or sharing rejection. It does not promise port forwarding, LAN pass-through, or a NAT direct connection; a different route may still use a relay or may perform worse. If you need to test the permitted public-relay branch, start the three-day Pro trial; new users receive it once.

How do you keep the comparison interpretable?

Change the route on only the endpoint being investigated. Connecting both computers at once adds another variable, while changing folders or creating a second test file makes the comparison less precise. Record which endpoint changed and restore its original route when the test is complete.

If the connection succeeds but the file remains blocked, stop changing routes and revisit the local or folder-specific error. If the file succeeds, describe the result as path-dependent evidence for this task. It does not prove that discovery was the sole cause or that direct connections will become available.

Step 5: Do the two devices contain the same completed version?

Require the test file to appear in the intended receiving folder, with the contents you created on the sender. Open both copies with an appropriate local application. Compare size and contents, and note any file-level error or conflict rather than relying only on a device's connected label.

For a real document, close editing applications during the verification and make sure you are comparing the same saved revision. Modification times alone are not sufficient because devices and filesystems can represent them differently. Preserve conflict copies until you have chosen the correct work deliberately.

Escalate when policies block approved discovery or relay use, both permitted paths fail, or local repair would involve resetting a folder. Send version, failure time, redacted device and folder details, scanning state, file errors, connection type, and same-file outcomes through a trusted support channel. Do not share API keys, private folder contents, or pairing invitations publicly.

Summary

Confirm device identity, folder sharing, and intended send/receive behavior first.
Separate local scanning and filesystem errors from discovery and connection failures.
Accept a working relay as a valid path, and record what connection was actually used.
Verify identical file contents at both ends before declaring synchronization recovered.

FAQ

Why is a connected device not enough to prove synchronization?

The peer can be online while a particular folder is unshared, paused, scanning, or blocked by local errors. Check the intended folder and the identified file at both ends instead of relying on the device indicator.

Must the local folder paths match on both computers?

No. Local paths and labels can differ, but the devices must share the intended folder identity and accept that relationship. Compare the folder ID and peer sharing configuration without remapping valuable work unnecessarily.

Can a VPN speed up the initial scan?

A route change does not repair local enumeration, disk access, or permission failures. Let the scan finish or investigate its explicit local error before testing public discovery or relay reachability.

Is using a relay a failure that needs fixing?

No. Relaying is a supported way to connect when a direct path is unavailable. Evaluate actual file progress and contents, recognizing that relay performance varies and a direct connection is not guaranteed.

Should I recreate a missing folder marker immediately?

First verify that the correct storage is mounted and the configured path is healthy. Blindly recreating the marker can conceal an unavailable folder; preserve current data and follow the relevant administrator or official troubleshooting guidance.

What counts as a successful same-file test?

The receiver must obtain the identified file with contents matching the sender's saved copy, and the connection type should be recorded. Device connectivity or website access alone does not establish delivery.

Can I use Syncthing as my only backup?

No. Synchronization propagates changes and deletions, so keep independent backups for work you cannot lose. Preserve conflicting versions and use a deliberate recovery process rather than deleting copies to obtain a clean status.

Sources

Syncthing — FAQ — https://docs.syncthing.net/users/faq.html
Syncthing — Relaying — https://docs.syncthing.net/users/relaying.html

Sources checked 7 October 2026.

Syncthing Not Syncing: Check Devices and Connections