Syncthing on KnightLi Blog

How to Manage Multiple Devices and Folders in Syncthing: Topology, Naming, and Versioning

Sun, 31 May 2026 12:23:55 +0800

Syncthing Series

Once Syncthing has many devices and many folders, it can quickly become messy if you do not plan ahead. The typical setup is a phone, tablet, laptop, desktop, and NAS all syncing at once, while folders contain photos, work documents, code projects, chat backups, and ebooks. Every device may modify files, every folder may be shared, and eventually it becomes hard to tell where a file came from and where it will sync next.

To keep Syncthing stable, the core is not installing more clients, but building a management model:

Use a star topology.
Standardize folder IDs and paths.
Use introducers for device relationships.
Separate backups from two-way sync by data direction.
Enable versioning on the central node.
Filter temporary files with ignore patterns.

Topology: Avoid Full Mesh, Prefer Star

Syncthing is a P2P architecture, but that does not mean every device should pair with every other device.

If 5 devices are fully connected, you need to maintain 10 device relationships. When you add a new folder, you also need to accept it, set paths, and confirm sharing across multiple devices. The more devices you have, the higher the management cost.

A star topology is usually better.

Choose one always-on, spacious, and stable device as the hub:

NAS
Synology
soft router
mini PC
a computer that stays on 24/7

All other devices pair only with the hub:

Phone ----\
Tablet ----\
Laptop ---- NAS
Desktop ---/

The phone does not directly add the laptop, and the laptop does not directly add the desktop. If the phone needs to sync photos to a computer, it syncs to the NAS first, then the NAS syncs them to the computer.

This has several benefits:

New devices only need to pair with the NAS.
Folder relationships are managed centrally on the NAS.
The NAS can handle version retention consistently.
When edge devices go offline, the NAS still acts as a buffer.

The tradeoff is that the NAS becomes more important. It should run reliably and have its own backup.

Folder ID Matters More Than the Folder Label

In Syncthing, the real identifier for a synchronized folder is the Folder ID, not the label you see in the UI.

The label is just a display name and may differ across devices. The Folder ID is what determines whether folders on different devices belong to the same sync group.

When creating a folder on the first device, specify a clean ID manually.

For example:

notes-main
work-docs
backup-pixel-photos
backup-iphone-photos
media-ebooks
code-projects

Avoid random generated IDs or long-term-unfriendly names such as test, sync, and new-folder.

A simple naming rule is enough:

Two-way sync: notes-main, work-docs
Phone backups: backup-pixel-photos, backup-iphone-photos
Media distribution: media-ebooks, media-music
Code directories: code-projects

Later, when other devices receive a shared folder, the Folder ID tells you immediately what the folder is for.

Keep Hub Paths Organized

On the NAS or central computer, create one dedicated Syncthing root directory.

For example:

/volume1/Syncthing/
├── Phone_Backup/
│   ├── iPhone15_DCIM/
│   └── Pixel7_DCIM/
├── Work/
│   ├── Office_Docs/
│   └── Coding_Projects/
├── Notes/
│   └── Main_Notes/
└── Media/
    └── eBooks/

Do not scatter sync folders across the system. Scattered paths may feel convenient at first, but they become difficult to maintain.

Recommended rules:

Put all Syncthing-managed folders under one root directory.
Separate phone backups, work documents, and media files into clear sections.
Let folder names reflect purpose, not temporary device state.
Do not use system directories or download caches as long-term sync folders.

If Syncthing runs in Docker, also pay attention to the mapping between host paths and container paths.

For example, the host path:

`1`	`/volume1/Syncthing/Phone_Backup/iPhone15_DCIM`

may be mounted inside the container as:

`1`	`/var/syncthing/Phone_Backup/iPhone15_DCIM`

The path entered in the Web UI is the container path, not the host path.

Introducers: Reduce Multi-device Pairing Work

Syncthing’s Introducer feature is well suited to star topologies.

The idea is to make the NAS an introducer. After that, a new device only needs to pair with the NAS. The NAS can introduce known devices and sharing relationships to the new device, reducing repeated scanning and manual adding across devices.

It works well when:

your home has multiple computers and phones;
the NAS is the long-running hub;
you often add new devices;
you want to reduce pairing work.

But do not use it casually.

Recommended practice:

Only set the NAS or main server as an introducer.
Do not set ordinary phones, tablets, or temporary computers as introducers.
After a new device joins, check which devices and folders were added automatically.
Do not bring untrusted devices into the introducer-managed network.

Introducers improve efficiency, but they also expand automatic relationships. They are best for a clear hub-based network, not a messy temporary device environment.

Separate Backups from Two-way Sync

In multi-folder management, one of the most important rules is: do not use Send & Receive for every folder.

Different folders have different data directions.

Phone Photo Backup

Phone side:

`1`	`Send Only`

NAS side:

`1`	`Receive Only`

The phone sends photos and the NAS receives them. Cleaning phone storage or organizing the NAS folder is less likely to affect the other side.

Multi-device Documents and Notes

Computer side:

`1`	`Send & Receive`

NAS side:

`1`	`Send & Receive`

Whether the phone joins this two-way sync depends on whether you truly edit these files on the phone. If the phone only reads them, consider Receive Only.

Media Distribution

NAS side:

`1`	`Send Only`

Other devices:

`1`	`Receive Only`

This is suitable for ebooks, installers, and reference material distributed from a central folder.

Backup Directories

Primary device:

`1`	`Send Only`

Backup machine:

`1`	`Receive Only`

Then combine it with versioning or snapshots on the backup side.

Enable File Versioning on the NAS

The biggest risks in multi-device sync are accidental deletion and accidental overwrite.

For example:

A computer deletes work documents by mistake.
A phone cleanup tool removes an album directory.
Two devices edit the same note at the same time.
A sync rule is misconfigured and an empty directory is synced over.

Because of this, the central node should enable file versioning.

In the NAS Syncthing Web UI:

Open the target folder settings.
Go to file versioning.
Choose a suitable versioning strategy.

A common choice is Staggered File Versioning. It keeps historical versions by time intervals, retaining older versions more sparsely over time.

You can also use simpler strategies:

Trash Can File Versioning: similar to a recycle bin.
Simple File Versioning: keeps a fixed number of versions.
Staggered File Versioning: keeps versions by time stages.

If you are not sure which to choose, a home NAS can start with Trash Can or Staggered.

Versioning is not a full backup, but it is the undo button you want in multi-device sync.

Filter Temporary Files with Ignore Patterns

When syncing code projects, document folders, or chat backups across many devices, temporary files and caches can create noise.

Common problems include:

wasting bandwidth;
generating meaningless conflicts;
creating different cache files on different operating systems;
blocking directory deletion because ignored files remain.

Add rules in the folder’s Ignore Patterns.

Common temporary files:

1
2
3

(?d).DS_Store
(?d)Thumbs.db
(?d)*~

Node / Python / Java projects:

(?d)node_modules/
(?d)__pycache__/
(?d).pytest_cache/
(?d)target/

If a code project is already managed by Git, it is usually not recommended to sync the .git directory with Syncthing. You can ignore it:

`1`	`(?d).git/`

(?d) means that if the whole directory is going to be deleted, Syncthing may delete these locally generated ignored files as well, preventing leftover cache files from blocking the deletion.

Do not make ignore rules too complex at once. Start with obvious caches and temporary files, then adjust slowly according to real conflicts.

Multi-folder Naming Examples

You can use a fixed naming scheme.

Phone photos:

1
2
3

Folder ID: backup-pixel-photos
Label: Pixel Photos
NAS Path: /volume1/Syncthing/Phone_Backup/Pixel7_DCIM

iPhone photos:

1
2
3

Folder ID: backup-iphone-photos
Label: iPhone Photos
NAS Path: /volume1/Syncthing/Phone_Backup/iPhone15_DCIM

Main notes vault:

1
2
3

Folder ID: notes-main
Label: Main Notes
NAS Path: /volume1/Syncthing/Notes/Main_Notes

Work documents:

1
2
3

Folder ID: work-docs
Label: Work Docs
NAS Path: /volume1/Syncthing/Work/Office_Docs

Ebooks:

1
2
3

Folder ID: media-ebooks
Label: eBooks
NAS Path: /volume1/Syncthing/Media/eBooks

As long as IDs, labels, and paths follow rules, multi-device setups are much easier to control.

Recommended Overall Design

If you already run Docker Syncthing on a NAS, you can design it like this:

Use the NAS as the hub.
Set the NAS as the introducer.
Pair all devices only with the NAS.
Put all sync folders under /volume1/Syncthing/.
Use phone Send Only and NAS Receive Only for photo folders.
Use Send & Receive for work documents and notes.
Use NAS Send Only and other devices Receive Only for distribution folders.
Enable versioning for important folders on the NAS.
Configure ignore rules for code and cache directories.
Back up or snapshot the NAS itself.

Once this structure is in place, adding new devices or folders simply means putting them into the existing rules. You do not need to rethink the sync relationships every time.

Summary

Syncthing gives you a lot of freedom, but the more freedom you have, the more you need rules.

For multi-device and multi-folder setups, avoid a fully connected mesh. A steadier approach is to let a NAS or always-on computer act as the hub, then standardize Folder IDs, paths, and versioning. Use folder types to distinguish backups, two-way sync, and distribution folders.

This keeps Syncthing’s P2P capability while bringing day-to-day management back to one central device. Even with many devices and many folders, the sync system will not turn into a tangle.

How to Sync iPhone Photos to a PC or NAS with Syncthing

Sun, 31 May 2026 12:21:54 +0800

Syncthing Series

Using Syncthing to sync photos on an iPhone is quite different from doing the same thing on Android.

The reason is simple: iOS is more locked down, and the official Syncthing project does not provide a first-party iOS client. To use the Syncthing protocol on an iPhone, you usually need a third-party compatible client.

There are two common choices:

Mobius Sync: a popular option with an experience close to a native app. Some features may require a paid unlock, so check the current App Store description.
FSync: a free and open-source Syncthing client for iOS.

If your goal is to sync the iPhone photo library to a PC or NAS, Mobius Sync is the more common choice. The steps below use it as the example.

Understand the Limits on iOS First

On Android, Syncthing-Fork can run for a long time through a background service, run conditions, and battery optimization exemptions. iOS does not allow third-party sync tools to run in the background without limits.

This means:

Do not expect it to sync 24/7 like a NAS.
After the app goes into the background, the sync window may be short.
For large photo batches, it is best to open the app manually and let it finish.
iCloud optimized storage may affect whether the original photo files can be read.

So on iPhone, Syncthing is better treated as a “open the app periodically to sync photos” workflow, rather than a fully invisible real-time background sync service.

Step 1: Install the Client and Grant Permissions

After installing Mobius Sync from the App Store, handle these permissions carefully the first time you open it.

Notifications

It is recommended to allow notifications. They can show sync status, connection status, and error messages.

Local Network Access

This permission is very important.

iOS separately asks whether an app may access the local network. If you deny it, the iPhone may not be able to discover your PC, NAS, or other Syncthing nodes on the LAN.

If you denied it by mistake, you can enable it again in iOS Settings.

Photo Library Access

If you want to sync photos, you must allow access to the photo library.

The recommended choice is:

`1`	`Full Access to Photos`

If you only grant limited photo access, Mobius Sync may only see the selected photos, and newly added photos may not be synced later.

Step 2: Pair the iPhone with the PC or NAS

Syncthing pairing still works by exchanging device IDs.

On the iPhone:

Open Mobius Sync.
Go to Settings.
Open Device ID.
Keep the QR code screen open.

On the PC or NAS:

Open the Syncthing Web UI.
Click Add Remote Device.
Scan the QR code on the iPhone, or enter the device ID manually.
Give the device a name, such as My-iPhone.
Save.

Return to the iPhone, wait for the connection request, and tap Accept.

At this point, the iPhone and the PC/NAS trust each other, but the photo library has not been shared yet.

Step 3: Create a Photo Sync Folder on the iPhone

iOS does not let you choose a path like /DCIM/Camera directly in the same way Android does. Mobius Sync provides special support for the system photo library, so you need to choose the photo-library folder type.

In Mobius Sync:

Switch to Folders.
Tap + in the upper-right corner.
Create a new folder.

Important fields:

Folder Type: choose Camera Roll.
Folder Label: use an easy-to-recognize name, such as iPhone_Photos.
Folder ID: you can keep the generated value, or use a stable English ID.
Folder Path: keep the default so the client can bind to the iOS photo library.

Then, in the Sharing section, select the PC or NAS you just paired.

Step 4: Set the iPhone Side to Send Only

Photo sync is usually “phone sends to NAS”, not a two-way editing workflow.

So on the iPhone side, set the folder type to:

`1`	`Send Only`

This makes the iPhone responsible for sending photos out, without accepting reverse changes from the PC or NAS.

This reduces the risk of accidental operations. For example, when organizing the backup folder on the computer, you usually do not want those changes to affect the iPhone photo library.

Still, remember that Syncthing is a sync tool, not a complete backup system. For long-term photo safety, you should also use NAS snapshots, file versioning, or an independent backup.

Step 5: Receive Photos on the PC or NAS

After saving on the iPhone, the Syncthing Web UI on the PC or NAS will show a prompt:

`1`	`Device My-iPhone wants to share folder iPhone_Photos`

Click add.

Set the storage path.

On Windows, it may look like:

`1`	`D:\Backups\iPhone_Photos`

On Linux or NAS, it may look like:

`1`	`/volume1/photos/iphone`

If Syncthing runs in Docker, enter the path inside the container. For example, if the host mount is:

`1`	`- /volume1/photos:/var/syncthing/photos`

Then in the Web UI, use:

`1`	`/var/syncthing/photos/iphone`

Set the Receiving Side to Receive Only

On the PC or NAS side, it is also recommended to set this folder type to:

`1`	`Receive Only`

This makes the receiving side accept photos from the iPhone, without syncing local changes back to the iPhone.

It is a second layer of protection:

iPhone side: Send Only
NAS side: Receive Only

Both ends are configured around one-way backup, which better matches a photo archive workflow.

The Reality of iOS Background Sync

iOS is strict about background execution. Even with correct settings, do not expect Mobius Sync to keep running silently in the background all the time.

Common behavior:

Sync speed is normal while the app is open.
It may keep syncing for a short time after going into the background.
After a while, the system may pause or limit it.
Location changes, system scheduling, or short background windows may wake it again.

The most reliable practical workflow is simple:

After taking many photos, open Mobius Sync manually.
Keep the phone awake, or avoid locking the screen too quickly.
Wait for the new photos to finish syncing.
Then close the app or lock the screen.

If you are used to doing a photo backup every few days, this approach is fairly reliable.

Avoid iCloud Optimized Storage Problems

If the iPhone has enabled:

`1`	`Optimize iPhone Storage`

iOS may keep only thumbnails locally while the original files remain in iCloud. When a third-party sync client tries to read photos, it may not be able to get the full originals, causing failed syncs, skipped items, or waits while iOS downloads the files.

The better setting for sync backup is:

`1`	`Download and Keep Originals`

The path is usually:

`1`	`Settings -> Apple ID -> iCloud -> Photos`

If the phone does not have enough storage and you must use optimized storage, you may need to open the relevant photos in the system Photos app before syncing, so the iPhone downloads the originals from iCloud first, and then start Mobius Sync.

Tips for the First Large Photo Sync

The first time you sync an iPhone photo library, there may be thousands or even tens of thousands of photos. Do not rush to finish everything in one pass.

A safer approach:

Sync a small number of photos first for testing.
Confirm the NAS path is correct.
Confirm the folder types are Send Only / Receive Only.
Confirm the receiving side will not affect the iPhone in reverse.
Then start the full sync.

During the first sync, it is best to:

Keep the iPhone plugged in.
Keep Wi-Fi stable.
Keep Mobius Sync open in the foreground.
Keep the NAS or PC online.

When the photo library is large, the sync may take a long time. That is normal.

Recommended Configuration

A stable iPhone photo sync setup looks like this:

Install Mobius Sync on the iPhone.
Allow notifications, Local Network access, and full photo library access.
Exchange device IDs between the iPhone and NAS.
Create a Camera Roll folder on the iPhone.
Set the folder label to iPhone_Photos.
Set the iPhone-side folder type to Send Only.
Set the NAS receiving path to /volume1/photos/iphone.
Set the NAS-side folder type to Receive Only.
Enable file versioning or snapshots on the NAS.
Open Mobius Sync manually every few days to complete sync.

If you rely heavily on fully automatic background photo backup, iOS will be more troublesome than Android. The system restrictions make it difficult for third-party sync tools to behave like an always-on background service.

Summary

An iPhone can join the Syncthing ecosystem through Mobius Sync or FSync, and sync photos to a PC or NAS.

The key differences on iOS are background limits and photo-library permissions. During setup, allow Local Network access and full photo access. Design the folder types around one-way backup: iPhone Send Only, NAS Receive Only. If iCloud optimized storage is enabled, also check whether the original photos are truly available locally.

For photo archiving, the most stable workflow is to open the client periodically to sync, then let the NAS handle version retention, snapshots, and long-term backup.

Using Syncthing on Android: Syncthing-Fork Setup and Photo Backup

Sun, 31 May 2026 12:17:19 +0800

Syncthing Series

On Android, there are two common ways to use Syncthing:

The original Syncthing Android client.
The community-maintained Syncthing-Fork.

Both can work for basic use. For long-term syncing of photos, notes, or documents, Syncthing-Fork is usually the better choice. It offers more practical controls for Android background behavior, battery usage, and network conditions, including Wi-Fi-only sync, selected Wi-Fi SSIDs, and running only while charging.

This article combines general Android setup with photo backup. Photo backup is one of the most common mobile Syncthing workflows, but it should not be configured like an ordinary two-way sync folder.

Why Syncthing-Fork Is Usually Better

Android actively restricts background apps. After the screen turns off, the system may suspend networking, freeze processes, or kill background services. If a sync tool does not handle this well, it may only sync while the app is open.

Syncthing-Fork is more practical for phone use because it can:

Set run conditions.
Sync only on Wi-Fi.
Sync only on selected Wi-Fi networks.
Run only while charging.
Fit Android’s background restrictions better.

This does not mean the original client is unusable. It simply means Syncthing-Fork is better tuned for long-running mobile sync.

Installation Sources

Common sources include:

Google Play
F-Droid
GitHub Releases

Choose the channel you trust. After installation, handle permissions and background settings before pairing devices.

Step 1: Grant Required Permissions

On first launch, focus on two permission areas.

Storage Permission

For file synchronization, Syncthing-Fork must be able to read and write target folders.

Recent Android versions may ask for all-files access or similar storage access. Without it, the app may only see a limited set of folders and fail to read photos, documents, or your chosen sync directory.

Recommendations:

Grant the required file access permissions.
Put sync folders under ordinary internal-storage directories.
Avoid protected system directories.

Useful examples:

1
2
3

/storage/emulated/0/SyncData
/storage/emulated/0/SyncData/Notes
/storage/emulated/0/SyncData/Photos

For camera photos, the common path is:

`1`	`/storage/emulated/0/DCIM/Camera`

Battery Optimization Allowlist

This is the most important Android-specific step.

If Syncthing-Fork is not excluded from battery optimization, Android may kill the sync process after the screen locks. The result is simple: you think it is syncing in the background, but it only moves when you open the app.

Add Syncthing-Fork to the system battery optimization allowlist. The setting name depends on the vendor:

Not optimized
Allow background running
Allow auto start
Lock in background
Allow high background power usage

Many Android vendor builds add extra background and auto-start restrictions. If sync is unstable, check both battery management and auto-start settings.

Step 2: Pair with a NAS or Computer

Syncthing pairs devices by adding each other’s device ID.

Assume the phone is device A and the NAS or computer is device B.

On the phone:

Open Syncthing-Fork.
Open the menu.
Show the device ID.
You will see a QR code and a long device ID.

On the NAS or computer:

Open the Syncthing Web GUI.
Click Add Remote Device.
Scan the phone’s QR code, or paste the phone device ID manually.
Name it clearly, such as Android-Phone or Pixel-Phone.
Save.

Back on the phone, accept the connection request.

At this point, the two devices trust each other, but no folder is synced yet.

Step 3: Receive a Folder Shared from NAS or PC

If the computer or NAS shares a folder with the phone, the phone will show a prompt.

For example:

`1`	`Device NAS wants to share folder Notes`

Add it, then choose a local path on the phone, such as:

`1`	`/storage/emulated/0/SyncData/Notes`

After saving, the phone starts downloading from the NAS or computer.

It is better to create the directory manually first so Syncthing-Fork does not place it somewhere unexpected.

If you sync Markdown notes, be careful with application configuration directories. In Obsidian, .obsidian contains workspace state, plugin settings, and cache. If Android and desktop plugins differ a lot, start by syncing only note content and attachments.

Step 4: Back Up Phone Photos to a PC or NAS

The most common phone use case is backing up photos to a NAS or computer.

Photo backup is different from normal file sync. Most people want new phone photos copied to the NAS, not phone deletions mirrored to the NAS. Treat it as one-way backup.

Recommended combination:

Phone side: Send Only
PC or NAS side: Receive Only

The phone sends photos, and the NAS receives and stores them. Add NAS-side file versioning or snapshots to reduce deletion risk.

Add the Camera Folder on the Phone

In Syncthing-Fork’s folder page:

Tap +.
Create a folder.
Use a clear label such as Pixel_Photos or Huawei_DCIM.
Choose the phone’s camera directory.
Share it with your PC or NAS.

The common Android camera path is:

`1`	`/storage/emulated/0/DCIM/Camera`

Screenshots, WeChat images, or other app images often live elsewhere. Add separate folders when needed:

1
2

/storage/emulated/0/Pictures/Screenshots
/storage/emulated/0/Pictures/WeiXin

Paths vary by Android version, vendor, and app. Confirm with a file manager first.

Set the Phone Folder to Send Only

In the phone-side folder settings, change the folder type from:

`1`	`Send & Receive`

to:

`1`	`Send Only`

This makes the phone the photo source. New photos are sent to the NAS, but NAS-side changes are not written back to the phone.

Syncthing is still a sync tool, not a complete backup system. For a safer setup, also enable NAS-side versioning, snapshots, or independent backups.

Configure the Receiver Path

After saving on the phone, the PC or NAS Web GUI will show a prompt:

`1`	`Device Pixel-Phone wants to share folder Pixel_Photos`

Add it and choose the local storage path.

On Windows:

`1`	`D:\Backups\Phone_Photos`

On Linux or NAS:

`1`	`/volume1/photos/phone`

With Docker, remember to use the container path. If the host mapping is:

`1`	`- /volume1/photos:/var/syncthing/photos`

then the Web GUI path should be:

`1`	`/var/syncthing/photos/phone`

Set the Receiver to Receive Only

On the PC or NAS, set the folder type to:

`1`	`Receive Only`

The receiver will accept photos from the phone but will not send local changes back.

This is an extra layer of protection. Even if you move, edit, or delete files on the NAS, those actions should not directly affect the originals on the phone.

Still, Receive Only is not a replacement for NAS history. Enable file versioning or snapshots on the NAS if the photos matter.

Test with a Small Set First

Do not start by syncing tens of thousands of photos.

Test first:

Put 3-5 temporary photos in the phone album.
Confirm that the PC or NAS receives them.
Add a new photo and see whether it syncs.
Delete one test photo on the phone and observe the NAS behavior.
Only then enable the full album.

Folder type and deletion behavior are easy to misunderstand. A small test avoids expensive cleanup later.

Run Conditions: Avoid Mobile Data Usage

Syncthing-Fork run conditions are very useful on Android.

At minimum, enable:

`1`	`Run only when connected to Wi-Fi`

This avoids syncing large files over 5G or 4G.

If you only want sync at home, restrict it to a specific Wi-Fi SSID. This is useful when the NAS is only reachable on your home LAN.

Charging-Only Sync

If you do not need real-time sync, enable:

`1`	`Run only while charging`

A stable workflow:

Take photos and write notes during the day.
Syncthing-Fork does not keep running constantly.
At night, return home and connect to home Wi-Fi.
Plug in the charger.
Syncthing-Fork starts and syncs the day’s photos and files to the NAS.

This saves battery and fits phone usage better than always-on sync.

For notes that must update quickly, you can skip charging-only mode and keep Wi-Fi-only mode.

Android 11+ Storage Restrictions

Android 11 and later restrict storage more heavily. Some directories may not be reliably accessible, especially:

1
2

Android/data
Android/obb

SD card directories may also be limited depending on vendor, Android version, and file picker authorization.

Recommendations:

Create dedicated sync directories under internal storage.
Do not use app-private system directories as primary sync folders.
For photos, prefer ordinary media folders such as DCIM/Camera.
For notes, use a clear path such as /storage/emulated/0/SyncData/Notes.

Stability matters more than choosing a path that looks native.

Do not sync all of:

`1`	`/storage/emulated/0`

It is too large and mixed, with caches, downloads, app data, and temporary files.

Choosing Folder Types on the Phone

Different scenarios need different folder types.

Two-Way Note Sync

If both phone and PC edit the same Markdown notes:

`1`	`Send & Receive`

Avoid editing the same file on multiple devices at the same time.

Phone Photos to NAS

If the phone mainly sends photos:

`1`	`Send Only`

Use versioning or snapshots on the NAS.

Read-Only Materials on the Phone

If the phone only needs to read files from the NAS:

`1`	`Receive Only`

This works for ebooks, reference documents, or script examples.

Think Through Deletion Semantics

Will deleting a phone photo delete it on the NAS? It depends on folder types and sync state.

To reduce risk:

Use Send Only on the phone.
Use Receive Only on the NAS.
Enable file versioning on the NAS.
Add snapshots or separate backups.

If your real goal is archival storage, sync into an inbox directory first, then let a NAS task copy files into an archive directory that Syncthing no longer manages.

Example:

1
2

/volume1/photos/inbox-phone
/volume1/photos/archive

Syncthing writes to inbox-phone; a scheduled script organizes files into archive.

Common Problems

Sync Stops After Screen Lock

Check:

Battery optimization allowlist.
Background running permission.
Auto-start permission.
Whether Wi-Fi-only or charging-only conditions are active.

Often the issue is Android background management, not Syncthing itself.

Cannot Find the Camera Folder

Use a file manager to confirm the real path. The common path is:

`1`	`/storage/emulated/0/DCIM/Camera`

Third-party camera or editing apps may use other folders.

Sync Is Slow

Check:

Whether the phone and NAS are on the same Wi-Fi.
Whether traffic is going through relay.
Whether 22000/TCP and 22000/UDP are reachable on the NAS.
Whether the phone is in power-saving mode.
Whether there are many small files.

Many small files are slower than fewer large files. After the first sync, incremental sync is usually much lighter.

Deleting Phone Photos Also Deletes NAS Copies

That means your sync relationship is propagating deletions. Syncthing is a sync tool, not a built-in append-only backup tool.

Fixes:

Check folder types on phone and NAS.
Enable NAS-side file versioning.
Add snapshots or independent backups.
Use an inbox directory and archive files outside Syncthing’s control if needed.

Recommended Setup

For Android + NAS:

Install Syncthing-Fork on the phone.
Grant file access.
Add it to the battery optimization allowlist.
Pair phone and NAS.
Put notes under /storage/emulated/0/SyncData/Notes.
Use /storage/emulated/0/DCIM/Camera for photos.
Set the phone photo folder to Send Only.
Set the NAS photo folder to Receive Only.
Enable home Wi-Fi-only sync.
If real-time sync is not needed, enable charging-only sync.
Enable NAS-side versioning or snapshots.

This avoids constant battery drain while still backing up photos when the phone returns home and charges.

Summary

Using Syncthing on Android is not just about installing the app. The important parts are permissions, background behavior, battery settings, and network conditions.

Syncthing-Fork is better suited to long-term phone sync. It can limit sync to Wi-Fi, selected Wi-Fi networks, or charging state, reducing battery drain and mobile data usage.

For photo backup to a NAS, use a one-way backup mindset: phone Send Only, PC or NAS Receive Only, plus NAS-side versioning, snapshots, and independent backups. Syncthing handles transfer; long-term safety still depends on your backup strategy.

How to Configure Syncthing for Multiple Devices: Peer Networks, Star Topology, and Introducers

Sun, 31 May 2026 12:13:57 +0800

Syncthing Series

Syncthing uses a decentralized P2P architecture. It does not have a traditional Server or Client role. At the protocol level, every device is a peer.

In real use, though, you can organize it in two common ways:

Pure peer network: every device pairs directly with the other devices.
Star network: one NAS, server, or always-on computer acts as the central node, and all other devices pair only with it.

Both approaches fit Syncthing’s design. The difference is management cost and daily workflow.

Understand Peers and the Pseudo Server First

Every Syncthing device has its own device ID. When two devices add each other’s ID and share the same folder, they can sync.

That means Syncthing itself does not require one server to hold all data. What people call a “server” is usually just an always-on device that you choose as the operational center.

For example:

A NAS is always on and has plenty of storage, so it works well as a central node.
Phones and laptops often go offline, so they are better treated as edge devices.
A desktop may be powerful, but it may not run 24/7, so it is usually a normal sync node.

This central node is not a protocol-level server. It is simply the device you let handle management and relay duties in your topology.

Mode 1: Pure Peer Mesh

In pure peer mode, every device pairs with every other device.

For example, suppose you have four devices:

NAS
Desktop
Laptop
Phone

Each device needs to connect to the other three. Any two online devices can then sync directly.

Advantages:

Transfer paths are more direct.
If one device is offline, other online devices can still sync with each other.
There is no dependency on a single central node.

Disadvantages:

The more devices you have, the more complex pairing becomes.
Adding a new device requires confirmation and setup on multiple existing devices.
Folder sharing relationships can become scattered.

When you only have a few devices, pure peer mode is comfortable. For one computer and one phone, or two computers syncing notes, there is no need to overthink the design.

Once you have five or six devices, maintaining a fully connected mesh by hand becomes increasingly annoying.

Mode 2: NAS-Centered Star Topology

Star topology is usually better for home and personal productivity setups.

Pick one device that stays online, has enough space, and has a stable network connection, such as:

NAS
Synology
Soft router
Mini PC
Home Linux server

Then pair every other device only with that center:

1
2
3

Phone   ----\
Laptop  ---- NAS
Desktop ----/

The phone does not need to pair directly with the laptop, and the laptop does not need to pair directly with the desktop. They all sync indirectly through the NAS.

Advantages:

Management is simple.
A new device only needs to pair with the NAS.
The NAS can handle versioning and backup buffering.
It fits 24/7 sync scenarios.

Disadvantages:

If the NAS is offline, other devices may not be able to keep syncing with each other.
If all traffic goes through the NAS, its network and disk performance affect the experience.
The central node’s permissions need to be managed carefully.

If you already have a NAS or an always-on mini server, star topology is the default recommendation. It keeps Syncthing’s P2P strengths while making day-to-day management feel much closer to centralized sync.

Basic Order for Multi-Device Setup

No matter which topology you choose, Syncthing setup follows this order:

Pair devices first.
Share folders second.
Confirm the local path on the receiving side last.

Do not start by creating folders everywhere. Clarify device relationships first, and the later steps will be much less chaotic.

Step 1: Pair Devices

Assume you want to connect device A and device B.

Device A could be a phone, while device B could be a NAS or computer.

On device A:

Open the Syncthing Web UI.
Click Actions in the upper-right corner.
Choose Show ID.
Copy the device ID or display the QR code.

On device B:

Open the Syncthing Web UI.
Click Add Remote Device.
Enter device A’s ID.
Give the device a recognizable name, such as My-Phone.
Save.

Then return to device A. It will usually show a prompt saying that device B wants to connect. Accept it.

At this point, the two devices have established a peer relationship, but no folders are syncing yet.

On device A, click Add Folder.

Common fields:

Folder label: a human-readable name, such as Notes.
Folder ID: the cross-device identifier. Use stable English names, such as notes.
Folder path: the real local path on this device.

Then switch to the Sharing tab and select the device B you just paired.

After saving, device A sends a folder sharing invitation to device B.

Open device B’s Web UI and wait a few seconds. You will usually see a prompt like:

`1`	`Device A wants to share a folder`

Click add, then choose a local storage path on device B.

For example:

`1`	`/volume1/notes`

Or, in a Docker deployment, a container path such as:

`1`	`/var/syncthing/notes`

After saving, sync starts.

The paths do not have to match across devices. Syncthing identifies the sync relationship by Folder ID, not by requiring every device to use the same local path.

How to Configure Star Topology

If you use the NAS-centered model, a good setup is:

Deploy Syncthing on the NAS first.
Pair every phone, computer, and server only with the NAS.
Create or accept the main sync folders on the NAS.
Each new device only needs to add the NAS device ID.
Share each folder only between the NAS and the devices that need it.

For example:

NAS
├── notes       -> desktop, laptop, phone
├── photos      -> phone, backup disk
├── downloads   -> desktop, NAS
└── scripts     -> desktop, laptop

This keeps the structure clear. You can treat the NAS as the control panel for sync relationships.

What Is an Introducer?

Syncthing has a useful feature called Introducer.

It is designed for multi-device setups.

Suppose you set the NAS as an introducer. Later, when a new device pairs with the NAS, the NAS can introduce the other devices it knows to the new device. It can also help propagate existing shared relationships.

This reduces repetitive clicking and repeated device pairing.

It is useful when:

You have several computers and phones at home.
The NAS is the long-running central node.
You add new devices often.
You want to reduce manual device relationship maintenance.

Be careful, though. An introducer expands the scope of automatically established relationships. Do not set an untrusted device as an introducer, and do not enable it casually before you understand the topology.

A safer rule is:

Only set the NAS or main server as the introducer.
Do not make ordinary phones or laptops introducers.
After adding a new device, check which devices and folders were added automatically.

Folder Type Controls Data Direction

Syncthing’s permission behavior is mostly controlled by the folder type.

Open a folder’s settings and adjust Folder Type in the options.

There are three common types:

Send & Receive

The default mode. Both sides can send and receive changes.

It is suitable for:

Editing notes from multiple devices.
Syncing documents across several computers.
Normal two-way sync folders.

This is the closest mode to true peer-to-peer sync.

Send Only

This device only sends changes and does not accept changes from other devices.

It is suitable for:

Data source folders.
Distributing a primary folder to other devices.
Preventing remote changes from affecting this device.

For example, you can set a software installer directory on the NAS to Send Only so other computers only receive it.

Receive Only

This device only receives changes and does not send local changes out.

It is suitable for:

Backup machines.
Read-only mirrors.
Preventing local accidental deletion from propagating back to the source.

For example, if the NAS receives photos from a phone, and you do not want phone-side deletion to also remove the NAS copy, you need to design folder types and deletion policy carefully.

Different Folders Can Use Different Topologies

Syncthing topology does not need to be site-wide or uniform. You can design it per folder.

For example:

notes: desktop, laptop, phone, and NAS all use Send & Receive.
photos: phone sends, NAS receives and keeps versions.
downloads: desktop and NAS sync, phone does not participate.
backup: main computer is Send Only, NAS is Receive Only.

Do not force every directory into one rule. In multi-device sync, the important question is data direction, not device count.

Think About Conflicts and Accidental Deletion Early

The most common multi-device sync problem is not failed setup. It is accidental deletion or conflicts after sync is already working.

Risky scenarios include:

Two devices edit the same file at the same time.
A mobile app automatically cleans a folder.
One device uses the wrong path, creates an empty folder, and syncs it out.
Cache files, temporary files, workspace state, and real files are synced together.
Versioning is not enabled on the NAS.

Recommendations:

Enable file versioning on the NAS for important folders.
Use .stignore to exclude caches and temporary files.
Before the first sync of a new folder, test with a small number of files.
If deletion behavior is unclear, do not set every device to Send & Receive.

Recommended Setup

If you have a NAS or always-on server, use star topology directly:

Use the NAS as the central node.
Pair the NAS with all devices.
Ordinary devices pair only with the NAS.
The NAS can be set as an introducer.
Choose Send & Receive, Send Only, or Receive Only per folder.
Enable file versioning on the NAS for important folders.
After adding a new device, share a test folder first to confirm path and permissions.

If you only have two or three devices, and they are often online, pure peer mode is fine. It is more direct and may be faster.

Summary

Syncthing is a P2P peer architecture, but that does not mean every device must be wired into a complex mesh.

Small setups can use pure peer mode. When you have many devices, a NAS, or an always-on host, star topology is usually better. Let the NAS act as the central node and introducer, and let other devices connect only to it. Management becomes much simpler.

The real questions are which devices you trust, which folders need to sync, where data originates, and which device should keep versions after accidental deletion. Topology is just the method. Data flow is the core of the configuration.

Deploy Syncthing with Docker: Compose, Ports, and Volume Mapping Pitfalls

Sun, 31 May 2026 12:12:05 +0800

Syncthing Series

Deploying Syncthing in Docker is a good fit for a NAS, a home server, or a VPS. It can act as an always-on sync node for photos, documents, Markdown notes, or download folders.

The important part of a Docker-based Syncthing setup is not merely whether the container starts. The real questions are:

whether the configuration directory is persistent;
whether the data folders you want to sync are mapped into the container;
whether ports and permissions are prepared in advance.

If these details are not handled well, a container update may wipe your configuration, the path you enter in the Web UI may not point to the real host folder, or sync tasks may fail with Permission denied.

Directory Planning

Start by creating a dedicated directory on the server or NAS, for example:

1
2

mkdir -p ~/syncthing
cd ~/syncthing

Put docker-compose.yml in this directory, and keep Syncthing’s configuration in a subdirectory:

1
2
3

syncthing/
├── docker-compose.yml
└── config/

The actual sync data can live in existing host paths, for example:

1
2

/volume1/downloads
/volume1/photos

Keep the configuration directory separate from the data directories. config stores Syncthing’s own configuration, keys, and index database. Folders such as downloads and photos are the actual data you want to sync.

Option 1: Docker Compose

Docker Compose is the recommended approach because updates, restarts, and migrations are easier to understand later.

Create ~/syncthing/docker-compose.yml:

version: "3"

services:
  syncthing:
    image: syncthing/syncthing:latest
    container_name: syncthing
    hostname: my-nas-syncthing
    environment:
      - PUID=1000
      - PGID=1000
      - TZ=Asia/Shanghai
    volumes:
      - ./config:/var/syncthing/config
      - /volume1/downloads:/var/syncthing/downloads
      - /volume1/photos:/var/syncthing/photos
    ports:
      - 8384:8384
      - 22000:22000/tcp
      - 22000:22000/udp
      - 21027:21027/udp
    restart: unless-stopped

Start it:

`1`	`docker compose up -d`

Check the status:

1
2

docker compose ps
docker logs -f syncthing

Open the Web UI:

`1`	`http://server-ip:8384`

After the first login, set a GUI username and password first.

Option 2: docker run

For quick testing, you can also start Syncthing directly with docker run:

docker run -d \
  --name syncthing \
  --hostname my-nas-syncthing \
  -e PUID=1000 \
  -e PGID=1000 \
  -e TZ=Asia/Shanghai \
  -p 8384:8384 \
  -p 22000:22000/tcp \
  -p 22000:22000/udp \
  -p 21027:21027/udp \
  -v /path/to/config:/var/syncthing/config \
  -v /path/to/data1:/var/syncthing/data1 \
  --restart unless-stopped \
  syncthing/syncthing:latest

Replace /path/to/config and /path/to/data1 with real host paths.

For example:

1
2

-v /volume1/docker/syncthing/config:/var/syncthing/config
-v /volume1/photos:/var/syncthing/photos

For long-term use, convert this into a Compose file so you do not need to rebuild the full command every time the container is recreated.

Container Paths and Host Paths

Docker beginners often get confused by paths.

For example, this volume mapping:

1
2

volumes:
  - /volume1/photos:/var/syncthing/photos

The left side, /volume1/photos, is the host path. The right side, /var/syncthing/photos, is the path inside the container.

When adding a sync folder in the Syncthing Web UI, the folder path must be the container path:

`1`	`/var/syncthing/photos`

That way Syncthing is actually operating on this host directory:

`1`	`/volume1/photos`

If you enter /volume1/photos in the Web UI, that path usually does not exist inside the container. Syncthing may report an error, or it may create a new directory inside the container filesystem that you did not intend to use.

Persist the Configuration Directory

This line is critical:

`1`	`- ./config:/var/syncthing/config`

Syncthing stores its configuration files, device keys, and index database in the configuration directory. If this directory is not mounted to the host, deleting or recreating the container may change the device ID and invalidate existing device pairings.

Use a stable host path such as:

`1`	`/volume1/docker/syncthing/config`

Do not put the configuration directory in a temporary location, and do not mix it with the actual sync data directories.

Ports and Firewalls

Common ports are:

8384/TCP   Web UI administration
22000/TCP Device sync traffic
22000/UDP QUIC sync traffic
21027/UDP Local discovery

If Syncthing runs on a home NAS, usually check:

whether the NAS firewall allows these ports;
whether Docker bridge port mapping is correct;
whether the router isolates Wi-Fi from wired devices;
whether the phone and computer are on the same subnet.

If Syncthing runs on a cloud server, also check the cloud provider’s security group. In particular, if 22000/TCP and 22000/UDP are not allowed, other devices may only connect through a relay, and the speed will be much slower.

8384 is the administration port. Do not expose it directly to the public internet. If remote administration is necessary, at least set a strong password, and preferably combine it with a reverse proxy, HTTPS, access control, or a VPN.

Permission Issues: PUID and PGID

If Syncthing starts and the Web UI is accessible, but a sync folder reports:

`1`	`Permission denied`

the container process usually does not have read/write permission on the host directory.

Check the UID and GID of the current user on the host:

id

The output may look like this:

`1`	`uid=1000(user) gid=1000(user) groups=1000(user)`

Then set the corresponding values in Compose:

1
2
3

environment:
  - PUID=1000
  - PGID=1000

Also confirm that the host directory itself allows this user to read and write:

`1`	`ls -ld /volume1/photos`

If necessary, adjust the owner or permissions:

`1`	`sudo chown -R 1000:1000 /volume1/photos`

On a NAS, do not blindly run recursive permission changes on an entire shared directory, especially if it is shared by multiple users. A safer approach is to prepare a dedicated sync directory for Syncthing, or grant the corresponding user access from the NAS permission management interface.

First-Time Web UI Security

After the container starts, visit:

`1`	`http://server-ip:8384`

On the first visit, Syncthing usually prompts you to set a GUI username and password. Do not skip this step.

Recommended practice:

set a GUI username and strong password immediately;
do not expose 8384 to the public internet;
use a VPN, SSH tunnel, or controlled reverse proxy for remote access;
if using a reverse proxy, proxy only the Web UI and do not accidentally expose unnecessary ports.

If someone else controls the administration interface, they may be able to add devices, modify shared folders, and change sync relationships. Syncthing encrypts data in transit, but the administration entry point still needs protection.

Add Sync Folders in the Web UI

Take a photo directory as an example. The Compose file already mounts:

`1`	`- /volume1/photos:/var/syncthing/photos`

When adding the folder in the Web UI:

Folder Label: you can use Photos;
Folder ID: use a stable English ID such as photos;
Folder Path: enter /var/syncthing/photos;
Sharing: choose the devices that should receive this folder;
Folder Type: choose Send & Receive, Send Only, or Receive Only based on the data flow.

If this Docker node is the central NAS node, common choices are:

regular documents: Send & Receive;
phone photo collection: Receive Only on the NAS;
outbound distribution folder: Send Only on the NAS.

Choose based on the intended direction of the data. Do not set every folder to bidirectional sync without thinking.

Update the Container

With Compose, updates are usually:

1
2

docker compose pull
docker compose up -d

As long as the configuration directory and data directories are mounted correctly, updating the container will not lose the device ID, pairings, or sync folder configuration.

Before updating, you can back up the configuration directory:

`1`	`tar -czf syncthing-config-backup.tar.gz ./config`

The configuration directory contains device private keys. Do not upload the backup casually to a public location.

Common Issues

Web UI Does Not Open

First check whether the container is running:

1
2

docker ps
docker logs syncthing

Then check port mappings:

`1`	`docker port syncthing`

If the container is healthy but the page still does not open, check the host firewall, NAS firewall, or cloud security group.

Folder Does Not Exist After Adding It

Check whether the path entered in the Web UI is the container path.

For example, if the host path is:

`1`	`/volume1/downloads`

and the container path is:

`1`	`/var/syncthing/downloads`

the Web UI should use the latter.

Only Relay Connections, Very Slow

Check first:

whether 22000/TCP is allowed;
whether 22000/UDP is allowed;
whether router port forwarding is correct;
whether the cloud security group allows both TCP and UDP;
whether the local firewall blocks Docker’s mapped ports.

Relays improve reachability, but they are not suitable for long-term heavy sync traffic.

File Permissions Are Wrong After Sync

First confirm that the container user is correct, then check the host directory permissions. Linux, NAS, and Windows shared folders have different permission models. Do not treat Syncthing as a permission repair tool.

For cross-system sync, try to sync ordinary files and directories. Avoid syncing system folders that depend on complex ACLs, ownership, or extended attributes.

A More Stable Setup

If your goal is to use a NAS or server as the central node, design it like this:

Run Syncthing with Docker on the NAS.
Mount the configuration directory to /volume1/docker/syncthing/config.
Mount each data category separately, for example /volume1/photos and /volume1/notes.
Add the NAS device ID from phones and computers.
Enable file versioning on important folders on the NAS side.
Keep the Web UI accessible only on the LAN or through a VPN.
Back up the NAS independently. Do not treat sync as the only backup.

In this setup, Syncthing handles device-to-device synchronization, the NAS provides always-on availability and version buffering, and real backup is still handled by snapshots, external disks, or off-site backups.

Summary

The key to deploying Syncthing with Docker is separating the container lifecycle from the sync data lifecycle.

The container can be updated, recreated, or migrated at any time. The configuration directory and data directories, however, must remain stable on the host. Use container paths in the Web UI, handle host permissions with PUID, PGID, and directory access rules, and open ports according to the actual network environment.

Once these pieces are clear, Syncthing works very well as a lightweight sync layer between a NAS, a server, and personal devices.

How to Use Syncthing: Practical Notes from Device Pairing to File Sync

Sun, 31 May 2026 11:59:09 +0800

Syncthing Series

Syncthing is well suited for peer-to-peer file synchronization between multiple devices. It is not a traditional cloud drive, and it does not first upload all data to a central server before downloading it elsewhere. Instead, authorized devices exchange files directly.

If you are considering it for Markdown notes, photo backup, configuration files, or a home NAS directory, the first question is not just whether it can sync. You should first understand devices, folders, device IDs, sync direction, discovery, and conflict handling.

What Syncthing Solves

Syncthing is designed for one core scenario: you have two or more devices and want a directory to stay consistent across them.

Typical examples include:

Syncing work files between a Windows desktop and laptop.
Syncing photos or documents between a phone and NAS.
Syncing small scripts, examples, or configuration notes between Linux servers.
Keeping Obsidian notes, Joplin attachments, or Markdown folders available on several devices.

It is better for cases where you control the devices and the data. If you need team permissions, web previews, sharing links, or collaborative editing, a conventional cloud drive or document platform may fit better.

What Happens on First Start

The official getting started guide suggests configuring two machines side by side. In Syncthing, each machine is a device. The machine you are configuring is the local device, while the other machine is a remote device.

On first start, Syncthing creates its configuration, cryptographic keys, and device ID. It also opens the local Web GUI by default:

`1`	`http://127.0.0.1:8384/`

The Web GUI is the everyday configuration interface. Syncthing may also create a default folder, usually a Sync directory under your user profile. You can use it for testing, or remove it later and add your own folders.

Device ID Is the Basis of Pairing

Syncthing pairs devices through device IDs.

Each device creates its own key on first start. The device ID is a readable fingerprint of that device certificate. Two devices only establish a sync relationship after they have added each other’s device ID.

A typical flow is:

Start Syncthing on both devices.
Open the Web GUI on both sides.
Add device B’s device ID on device A.
Add device A’s device ID on device B.
Choose which folders to share.
Save and wait for the connection.

The device ID does not need to be protected like a password, but you should not publish your sync topology unnecessarily. The things that really need protection are the device private key, Web GUI access, and the synced folders themselves.

Syncthing Does Not Sync the Whole Machine

Syncthing only syncs folders that you explicitly add. It does not sync an entire device by default.

Each folder has its own path, ID, shared devices, and folder type. It is usually better to separate folders by purpose:

notes/: Markdown notes.
photos-inbox/: phone photo intake.
docs/: documents shared across devices.
scripts/: scripts and configuration examples.

Do not start by syncing huge system directories, download directories, or mixed folders. The more complex the directory, the more likely conflicts, ignore rules, permissions, and scan cost will become long-term problems.

Three Common Folder Types

The official documentation explains folder types clearly. In practice, you mainly need to understand these three.

Send & Receive

This is the default mode. The folder sends local changes and receives remote changes.

It fits:

Editing notes across several devices.
Maintaining documents on multiple devices.
Normal two-way synchronization.

If two devices modify the same file at the same time, Syncthing creates a conflict file instead of silently overwriting one side.

Send Only

This mode treats the local folder as the reference copy. It sends changes to other devices, but does not apply changes from them.

It fits:

A primary device distributing files to backup devices.
Cases where one machine should be authoritative.
Situations where remote changes should not affect the local folder.

If remote changes appear, the local device may show the folder as out of sync. The Web GUI can then offer Override Changes, which pushes the local state to the rest of the cluster. Use that button carefully.

Receive Only

This is the opposite of Send Only. The folder receives cluster changes, but local changes are not sent to other devices.

It fits:

Backup targets.
Read-only mirrors.
Devices where local mistakes should not pollute the main sync set.

If local changes appear, the Web GUI may offer Revert Local Changes to return the folder to the cluster state.

Check Firewall and Ports First

Syncthing can use discovery, NAT traversal, and relays, but connections are more stable when the network is understood.

The important ports listed in the official firewall guide are:

1
2
3

22000/TCP
22000/UDP
21027/UDP

Where:

22000/TCP is used for TCP sync traffic.
22000/UDP is used for QUIC sync traffic.
21027/UDP is used for local discovery.

If devices are on the same LAN but cannot discover each other, first check local firewalls, router isolation, and whether Wi-Fi and wired networks are on different segments.

Across the internet or NAT, direct connections are usually faster than relays when port forwarding is possible. Without port forwarding, relays can still help devices connect, but performance is often worse.

On Linux with ufw and the corresponding application profile installed, you can use:

1
2

sudo ufw allow syncthing
sudo ufw status verbose

The Web GUI listens on 127.0.0.1:8384 by default. If you change it to 0.0.0.0:8384, the management interface becomes reachable from outside the machine. At that point you must think about passwords, HTTPS, reverse proxies, or SSH tunnels. For home use, an SSH tunnel is usually safer.

`.stignore` Belongs in the Sync Root

If some files should not sync, create a .stignore file in the root of the synced folder.

Important details:

.stignore must be in the root of the synced folder.
Rules are relative to that root.
.stignore itself is not synced to other devices.
The file should use UTF-8.

A simple example:

(?d).DS_Store
node_modules
*.tmp
cache/**
!/cache/keep.txt

(?d) means Syncthing may delete those ignored files when they would otherwise prevent a directory deletion. It is useful for generated files such as .DS_Store.

The exclamation mark ! negates a rule and includes a file again. Complex negative rules can make Syncthing scan directories that would otherwise be ignored, so start with simple patterns.

File Versioning Is Not Local Undo

Syncthing supports file versioning, but its meaning is easy to misunderstand.

The official documentation emphasizes that versioning stores the old local version when a remote change replaces it. If B modifies a file and syncs it to A, A can keep the replaced version. But if A edits a file locally, Syncthing cannot preserve A’s previous version before the edit.

Common versioning strategies include:

Trash Can File Versioning: move replaced or deleted files into .stversions.
Simple File Versioning: keep a fixed number of versions.
Staggered File Versioning: keep dense recent versions and sparser older versions.
External File Versioning: hand version handling to a script.

For important documents, enable at least simple or trash-can versioning on the backup target. It is not a full backup system, but it reduces the damage from accidental deletion or overwrite.

How Conflicts Happen

Syncthing detects conflicts. If two devices change the same file differently at the same time, it may create a conflict file such as:

`1`	`filename.sync-conflict-date-time-modifiedBy.ext`

This is safer than silent overwrite, but you still need to clean up conflict files.

Common conflict sources:

Opening the same Markdown note on multiple devices at once.
Applications automatically writing the same state file.
Syncing device-specific files such as .obsidian/workspace.json.
Case-sensitive and case-insensitive filename differences across Windows, macOS, and Android.

For notes, sync the text, attachments, and templates first. Be careful with workspace state, caches, and plugin temporary files; put them in .stignore when needed.

Security Boundaries

One of Syncthing’s security goals is that unauthorized devices cannot join the sync cluster and passive observers cannot read file contents in transit.

The security documentation explains that traffic between devices is protected by TLS, and peers verify that the device certificate fingerprint is in the allowed list. In practice, devices only sync after both sides are configured with the correct device IDs.

That does not mean Syncthing usage is invisible:

Global discovery announces device IDs and listening addresses.
Local discovery broadcasts on the LAN.
Relay servers can see device IDs, though they cannot decrypt synced data.
An exposed Web GUI reveals that the machine is running Syncthing.

Practical security advice:

Do not expose the Web GUI to the public internet unless authentication and encryption are properly configured.
Only add devices you trust.
Use disk encryption or separate backups for important folders.
Disable global discovery, relays, or auto-upgrade if your environment requires it, while accepting the loss of convenience.

Untrusted Encrypted Devices

Syncthing also supports untrusted encrypted devices. This lets an untrusted device store encrypted data only.

A typical use case is a cloud server or external machine that participates in sync or backup but should not see plaintext. Trusted devices encrypt data with a folder password before sending it; other trusted devices with the same password can sync and decrypt it.

The official documentation still treats this feature as beta/testing. It is useful for specific needs, but not the simplest starting point.

Remember:

File data, names, timestamps, hashes, and directory structure are protected.
Folder ID, label, and approximate file sizes are not fully hidden.
The password and folder ID must be kept safely.
The folder type on the untrusted device should be Receive Encrypted.

For a normal home NAS, your own computers, and phones, trusted-device sync plus system login security, disk encryption, and backups is usually easier to maintain.

Practical Configuration Advice

If you plan to use Syncthing for notes or documents long term:

Create separate folders by data type. Do not use one giant mixed folder.
Use Send & Receive on primary computers.
Consider Receive Only plus file versioning on a NAS or backup machine.
On phones, sync only the directories you need.
Use .stignore for caches, temporary files, and workspace state.
Make sure 22000/TCP, 22000/UDP, and 21027/UDP work on the LAN.
Keep the Web GUI local when possible; use SSH tunnels or VPN for remote access.
Do not treat sync as the only backup for important data.

Where Syncthing Fits

Syncthing is a good fit if:

You want data to stay mainly on your own devices.
You can understand device pairing, folders, and conflict handling.
You have a NAS, home server, or multiple personal devices.
You want to sync Markdown, photo intake folders, scripts, or lightweight documents.

It is not ideal if:

You need collaborative online editing.
You need web previews and sharing links.
You need fine-grained team permissions.
You do not want to deal with network, firewall, or conflict issues.

It is best understood as a reliable device-to-device sync layer, not a full cloud-drive product. Used well, it can connect a NAS, computers, and phones into a controllable personal data network. Used casually, it can become a maintenance burden through conflicts, accidental deletion, ignore rules, and network quirks.

Syncthing on KnightLi Blog

How to Manage Multiple Devices and Folders in Syncthing: Topology, Naming, and Versioning

Syncthing Series

Topology: Avoid Full Mesh, Prefer Star

Folder ID Matters More Than the Folder Label

Keep Hub Paths Organized

Introducers: Reduce Multi-device Pairing Work

Separate Backups from Two-way Sync

Phone Photo Backup

Multi-device Documents and Notes

Media Distribution

Backup Directories

Enable File Versioning on the NAS

Filter Temporary Files with Ignore Patterns

Multi-folder Naming Examples

Recommended Overall Design

Summary

How to Sync iPhone Photos to a PC or NAS with Syncthing

Syncthing Series

Understand the Limits on iOS First

Step 1: Install the Client and Grant Permissions

Notifications

Local Network Access

Photo Library Access

Step 2: Pair the iPhone with the PC or NAS

Step 3: Create a Photo Sync Folder on the iPhone

Step 4: Set the iPhone Side to Send Only

Step 5: Receive Photos on the PC or NAS

Set the Receiving Side to Receive Only

The Reality of iOS Background Sync

Avoid iCloud Optimized Storage Problems

Tips for the First Large Photo Sync

Recommended Configuration

Summary

Using Syncthing on Android: Syncthing-Fork Setup and Photo Backup

Syncthing Series

Why Syncthing-Fork Is Usually Better

Installation Sources

Step 1: Grant Required Permissions

Storage Permission

Battery Optimization Allowlist

Step 2: Pair with a NAS or Computer

Step 3: Receive a Folder Shared from NAS or PC

Step 4: Back Up Phone Photos to a PC or NAS

Add the Camera Folder on the Phone

Set the Phone Folder to Send Only

Configure the Receiver Path

Set the Receiver to Receive Only

Test with a Small Set First

Run Conditions: Avoid Mobile Data Usage

Charging-Only Sync

Android 11+ Storage Restrictions

Choosing Folder Types on the Phone

Two-Way Note Sync

Phone Photos to NAS

Read-Only Materials on the Phone

Think Through Deletion Semantics

Common Problems

Sync Stops After Screen Lock

Cannot Find the Camera Folder

Sync Is Slow

Deleting Phone Photos Also Deletes NAS Copies

Recommended Setup

Summary

How to Configure Syncthing for Multiple Devices: Peer Networks, Star Topology, and Introducers

Syncthing Series

Understand Peers and the Pseudo Server First

Mode 1: Pure Peer Mesh

Mode 2: NAS-Centered Star Topology

Basic Order for Multi-Device Setup

Step 1: Pair Devices

Step 2: Create and Share a Folder

Step 3: Accept the Share

How to Configure Star Topology

What Is an Introducer?

Folder Type Controls Data Direction

Send & Receive

Send Only

Receive Only

Different Folders Can Use Different Topologies

`.stignore` Belongs in the Sync Root