NAS 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.

References

Sync Local Markdown Notes with a Self-Hosted Git Server on a NAS

Sat, 30 May 2026 16:14:19 +0800

If you already have a local NAS and want to keep your notes as much as possible under your own control, you can put Markdown notes into a Git Server on the NAS and sync them with Android and Windows clients. This setup does not depend on public cloud drives, and it works well with note tools centered on local Markdown files, such as Obsidian, Markor, VS Code, and Typora.

The basic idea is simple:

Create a bare Git repository on the NAS as the central notes repository.
Clone the repository on Windows and write notes with a normal editor.
Clone the same repository on Android and use a Git client to pull and push.
Before switching devices, run pull; after writing, run commit and push.

This is not the most hands-off sync method, but it gives good control and clear version history. Once you build the habit of committing, you can keep notes, configuration, and image attachments on your own NAS for long-term storage.

Who This Setup Is For

This setup is suitable for people who:

Already have a NAS at home or in the office.
Mainly write notes as Markdown files.
Want note data stored inside a local network instead of only on a commercial cloud drive.
Need sync between Windows and Android devices.
Can accept basic Git operations such as clone, pull, commit, and push.

If you want fully automatic and invisible sync, Syncthing, WebDAV, or the built-in sync of a notes app may be easier. Git is better for a notes library where version history, rollback, migration, and control matter.

1. Install Git Server on the NAS

Different NAS systems expose this in different places, but the goal is the same: let the NAS provide a Git repository that can be accessed through SSH.

There are three common approaches:

Method	Suitable Scenario
Install Git Server from the NAS package center	Synology, QNAP, and other consumer NAS systems when you want less setup work
Deploy Gitea with Docker	You want a web UI, account management, and a more complete Git service
Use SSH + a bare repository directly	You only use it yourself and want something simple and stable

For personal note sync, SSH + a bare repository is usually enough. Suppose the NAS has a dedicated Git user named git, and repositories are stored under /volume1/git. On the NAS terminal, run:

1
2
3

mkdir -p /volume1/git/notes.git
cd /volume1/git/notes.git
git init --bare

A bare repository is not edited directly. It only acts as the sync center. The actual note-writing directory lives locally on Windows or Android.

Then confirm that SSH can access the NAS:

`1`	`ssh git@192.168.1.10`

If the NAS supports SSH public-key login, configure keys so you do not need to enter a password every time you push. Windows and Android can each generate their own SSH key, and then you can add the public keys to the NAS authorized_keys file or the Git Server user settings.

2. Windows Setup

On Windows, install Git for Windows first. Then choose a local directory for notes, such as D:\Notes.

Initial clone:

`1`	`git clone git@192.168.1.10:/volume1/git/notes.git D:\Notes`

After entering the directory, you can create a basic structure:

1
2

cd D:\Notes
mkdir inbox, daily, projects, resources

Then open D:\Notes with Obsidian, VS Code, Typora, or another Markdown editor. After writing the first batch of notes, commit them:

1
2
3

git add .
git commit -m "初始化笔记库"
git push origin main

If the default branch is master, replace main with master in the command. You can also standardize it to main:

1
2

git branch -M main
git push -u origin main

For daily use, keep this rhythm on Windows:

git pull --rebase
git add .
git commit -m "更新笔记"
git push

3. Android Setup

On Android, use a client that supports Git to sync the local Markdown directory. Common choices include:

Tool	Usage
Termux	Most flexible, close to a Linux command line
MGit	Graphical Git client, suitable if you do not want to type many commands
GitJournal	More like a notes app, suitable for simple Markdown notes

If you choose Termux, first install Git and OpenSSH:

1
2

pkg update
pkg install git openssh

Generate an SSH key:

`1`	`ssh-keygen -t ed25519 -C "android-notes"`

Add the generated public key to the Git user authorization on the NAS. Then choose a local directory on the phone and clone the repository:

`1`	`git clone git@192.168.1.10:/volume1/git/notes.git ~/notes`

If you want ordinary Android editors to access this directory, you can put the repository in shared storage, for example:

1
2

cd /sdcard
git clone git@192.168.1.10:/volume1/git/notes.git Notes

Then open /sdcard/Notes with Markor, Obsidian Android, or another Markdown editor. After editing on the phone, return to Termux and run:

cd /sdcard/Notes
git pull --rebase
git add .
git commit -m "手机更新笔记"
git push

Permissions and paths are the easiest sources of trouble on Android. Termux’s own home directory is more stable, but some editors may not access it directly. /sdcard is easier for editors to access, but permissions, file watching, and performance may be limited by the system. Test with a small number of notes before deciding on the final directory.

4. How Obsidian and Joplin Fit In

The NAS Git Server only solves where files live and how they sync. You still need to choose a notes app for writing. Here, the setup can be split into an Obsidian path and a Joplin path.

Setup	Sync Method	Best For	Notes
Obsidian + Git	The notes directory is the Git repository, and Windows and Android both pull the same repository	People who want backlinks, knowledge graphs, plugins, and pure Markdown files	On Android, test whether the Git client and Obsidian can access the same directory correctly
Joplin + Git	Do not put the Joplin database directly into Git; use Joplin’s own sync or export Markdown to Git regularly	People who want web clipping, end-to-end encryption, and a traditional notebook structure	Joplin’s local data is not a normal Markdown folder and is not suitable as a direct Git-synced notes library

Obsidian Setup

Obsidian is the best fit for this NAS Git sync setup. Its vault is essentially an ordinary folder containing Markdown files, image attachments, and configuration files. You can directly use D:\Notes or /sdcard/Notes as the Obsidian vault.

Windows workflow:

`1`	`git clone git@192.168.1.10:/volume1/git/notes.git D:\Notes`

Then open D:\Notes in Obsidian.

Android workflow:

1
2

cd /sdcard
git clone git@192.168.1.10:/volume1/git/notes.git Notes

Then open /sdcard/Notes in Obsidian Android.

Suggestions for the Obsidian setup:

For single-user use, you can commit .obsidian/ so themes, plugins, and some settings sync across devices.
If Android and Windows use very different plugins, commit only the note content and exclude device-state files such as .obsidian/workspace.json.
Put image attachments under attachments/ to avoid scattering them across directories.
Before opening Obsidian, run git pull --rebase; after writing, run commit and push.

You can prepare a .gitignore to reduce conflicts caused by device-state files:

1
2
3

.obsidian/workspace.json
.obsidian/workspace-mobile.json
.trash/

Joplin Setup

Joplin works differently from Obsidian. Although it uses Markdown syntax, its local data is mainly managed by the application’s database. It is not a normal Markdown folder that can be synced directly with Git. Therefore, do not put Joplin’s configuration or database directory directly into a Git repository.

If you prefer Joplin, two safer approaches are:

Approach	Description
Use Joplin’s built-in sync	Sync through WebDAV, Nextcloud, Joplin Cloud, Dropbox, OneDrive, and similar options. The NAS can provide WebDAV or Nextcloud
Export Markdown to Git regularly	Use Joplin as the main notes app, regularly export notes as Markdown, and commit them to the NAS Git repository as a backup

If your NAS already has WebDAV or Nextcloud, connecting Joplin directly to the NAS for sync is smoother than Git. It can also enable end-to-end encryption, which is suitable for people who do not want to handle Git conflicts but still want data under their own control.

The recommended Joplin + NAS path is:

Enable WebDAV on the NAS or deploy Nextcloud.
Configure the same sync target on Joplin for Windows.
Configure the same sync target on Joplin for Android.
When versioned backup is needed, export Markdown to the Git repository regularly.

Simple rule of thumb:

Choose Obsidian if you want “local Markdown folder + backlinks + Git history”.
Choose Joplin if you want “traditional notes app + web clipping + encrypted sync”.
If you want the NAS Git Server as the main sync center, Obsidian is more suitable.
If you want the NAS to act as a private cloud sync backend, Joplin is more suitable.

5. Recommended Notes Directory Structure

Do not design the notes library too elaborately at the beginning. Start with a structure like this:

Notes/
  inbox/
  daily/
  projects/
  resources/
  attachments/
  README.md

The meaning is straightforward:

inbox/ stores temporary notes.
daily/ stores journals, logs, and daily records.
projects/ stores project notes.
resources/ stores long-term reference material.
attachments/ stores images, PDFs, and other attachments.

If you use Obsidian, you can use this directory directly as a vault. Whether to commit .obsidian/ depends on personal preference. For single-user multi-device use, committing it is fine. If plugins differ greatly across devices, commit only part of the configuration.

6. Avoiding Sync Conflicts

The key to syncing notes with Git is not complicated commands, but stable habits.

Recommended rules:

Before writing on another device, run git pull --rebase.
After a writing session, run commit and push promptly.
Do not edit the same file on two devices for a long time at the same time.
Do not keep adding unlimited images and large attachments into the Git repository.
Regularly keep another backup of the repository outside the NAS.

If a conflict happens, Git will mark the conflicting files. Markdown text conflicts are usually not hard to resolve, but the experience is worse on a phone, so try to resolve conflicts on Windows.

7. Do You Need Automatic Sync?

You can write a simple Windows script that chains pull, add, commit, and push. But for note sync, fully automatic commits are not recommended, because accidental deletions, empty commits, conflicts, and large attachments may all be pushed automatically.

A safer approach is semi-automatic:

Pull manually before opening notes.
Run a script to commit after writing.
Use a simple commit message that says what changed.

For example, you can prepare a sync-notes.ps1 on Windows:

git pull --rebase
git add .
git commit -m "更新笔记"
git push

If there are no changes, git commit will report nothing to commit. That is not a problem.

8. Pros and Cons of This Setup

Aspect	Description
Pros	Data stays on the local NAS, version history is clear, rollback is possible, migration is easy, and it suits Markdown
Cons	Requires understanding Git, conflicts need manual handling, and the mobile experience is not as smooth as cloud sync
Best for	Technical users, local-first notes, personal knowledge bases, project documentation
Not for	People who do not want to touch a command line, need real-time multi-user collaboration, or frequently sync large attachments

My Recommendation

If you only want to sync ordinary Markdown notes between Android and Windows, start with the smallest setup: one bare repository on the NAS, Git for Windows on Windows, and Termux or MGit on Android. Do not introduce complex permissions, automation scripts, or excessive categorization on day one.

After this workflow runs smoothly, then consider Gitea, automatic backups, per-device SSH key management, a separate attachment repository, scheduled tasks, and other extensions. The most important thing for a notes system is long-term stability, not filling it with every feature on the first day.

In one sentence: a NAS Git Server is suitable for turning Markdown notes into a local-first, traceable, and portable personal knowledge library. It is less effortless than cloud sync, but the control is clearer.

What is Above 4G Decoding? Why multi-PCIe systems, NAS expansion cards, and large-VRAM GPUs should enable it

Sun, 24 May 2026 00:51:13 +0800

Above 4G Decoding is a low-level PCIe resource allocation option in the motherboard BIOS. It often appears when troubleshooting NAS boxes, mini PCs, workstations, multi-GPU systems, routers, HBA / SATA expansion cards, and local AI machines.

In simple terms, it allows a 64-bit system to assign PCIe devices’ MMIO address space above the 4GB physical address range.

That sounds low-level, but the problem is very real: when a motherboard has a GPU, NVMe drive, NIC, SATA expansion card, capture card, HBA, and other PCIe devices, forcing all of them to compete for address space below 4GB can cause resource allocation failures, missing devices, or even boot freezes.

Why is there a 4GB boundary?

The 4GB boundary is a historical legacy of the 32-bit era.

A 32-bit address space can address at most:

`1`	`2^32 bytes = 4GB`

Modern computers have 64-bit CPUs and operating systems, and memory sizes of 16GB, 32GB, 64GB, or more are common. But during POST and PCIe device initialization, motherboards still need to account for old compatibility assumptions. Many PCIe device resource mappings are initially arranged below the 4GB address boundary.

The problem is that the space below 4GB is not only for RAM. The system must reserve part of it for hardware devices.

That is where MMIO comes in.

What is MMIO?

MMIO means Memory-Mapped I/O.

The CPU cannot directly touch the internal registers or memory windows of PCIe devices as if they were normal RAM. Instead, part of the device’s registers, buffers, or VRAM window is mapped into the system address space. When the CPU reads or writes that address range, it is effectively communicating with the PCIe device.

Roughly:

A device needs an address range.
The motherboard assigns a physical system address range to it.
When the CPU accesses that address range, it actually accesses the PCIe device.

This mapped region is not ordinary RAM. It is an address window occupied by hardware.

In old default configurations, many devices’ MMIO regions are constrained below 4GB, often around the 3GB to 4GB area. This usually works with few devices, but becomes crowded as more devices are installed.

What is BAR?

Every PCIe device uses BAR to tell the motherboard how much address space it needs.

BAR means Base Address Register. Its job is to say:

`1`	`I need a block of MMIO space. Please assign me an address range.`

GPUs, NVMe drives, SATA controllers, NICs, HBAs, and USB expansion cards may all need BAR space. More devices means more address windows. GPUs may need especially large mappings.

If the available MMIO space below 4GB is insufficient, the motherboard may fail to allocate resources to later devices.

What happens if Above 4G Decoding is disabled?

When Above 4G Decoding is disabled, the motherboard tends to pack PCIe resources below the 4GB boundary. With only a few devices, you may not notice anything. With many devices, problems can appear.

Common setups include:

A discrete GPU.
One or more NVMe SSDs.
A JMB585 / ASM1166 SATA expansion card.
A 2.5G / 10G NIC.
A Wi-Fi / Bluetooth module.
Extra HBAs, capture cards, or USB expansion cards.

All of these devices request BAR / MMIO address space from the motherboard. If the below-4GB region is full, the motherboard may show:

A PCIe card is not recognized.
The device does not appear in BIOS.
Linux / Windows reports missing devices or resource errors.
Boot freezes during POST.
Black screen or blinking cursor.
Each card works alone, but the system fails when multiple cards are installed together.

In JMB585 SATA expansion card scenarios, users often see the motherboard hang before BIOS, or the expansion card disappear after adding NVMe or NIC devices. Besides Option ROM, CSM, and PCIe Gen speed, PCIe address-space allocation is also worth checking.

What changes when Above 4G Decoding is enabled?

Enable:

`1`	`Above 4G Decoding = Enabled`

This tells the motherboard that PCIe devices supporting 64-bit addressing may have their MMIO resources allocated above 4GB.

Then PCIe devices no longer need to fight for the small below-4GB region. The motherboard can place some BAR / MMIO mappings at higher addresses, reducing resource conflicts.

For modern 64-bit systems, this is usually a reasonable setting, especially on:

Multi-disk NAS machines.
Multi-NIC routers.
Mini PCs with SATA / HBA expansion cards.
Multi-GPU workstations.
AI inference or training machines.
Desktop systems with GPU, NVMe, capture cards, and expansion cards.

Its goal is not to improve normal application performance. Its goal is to make hardware resource allocation less cramped.

Relationship with JMB585 / SATA expansion cards

A JMB585-style SATA expansion card may not need huge MMIO space by itself. The problem is often not how much this card needs alone, but how all PCIe devices in the system compete for address space together.

For example, a mini PC may include:

An NVMe system disk.
An onboard NIC.
A Wi-Fi module.
A JMB585 five-port SATA expansion card.
Possibly a discrete GPU or other controller.

If BIOS resource allocation is conservative, JMB585 may be one of the last devices initialized. Earlier devices have already consumed much of the below-4GB space. When JMB585 asks for BAR space, the motherboard may fail or enter an abnormal state.

Enabling Above 4G Decoding lets the motherboard place some device resources above 4GB, reducing the chance of conflict.

It cannot repair a bad card or solve every PCIe link-training problem, but it is well worth trying when issues appear only after several devices are installed.

Relationship with Resizable BAR / SAM

Many users first notice Above 4G Decoding when configuring GPU performance features, such as:

Resizable BAR
Re-Size BAR
ReBAR
Smart Access Memory
SAM

They are related, but not the same thing.

Above 4G Decoding is the foundation. It allows PCIe device MMIO resources to be assigned above 4GB.

Resizable BAR is a further capability. Traditionally, even if the CPU can access GPU memory, it often does so through a relatively small window, such as a 256MB mapping. With ReBAR, the CPU can map a larger portion of the GPU’s VRAM at once, theoretically reducing access switching overhead.

Many motherboards require Above 4G Decoding to be enabled before Resizable BAR can be enabled. So:

Above 4G Decoding: allows device addresses above 4GB.
Resizable BAR / SAM: allows the GPU BAR window to become larger.

For NAS and SATA expansion cards, the important part is usually the PCIe address space provided by the first option, not ReBAR itself.

Side effects

On modern 64-bit Windows, Linux, Ubuntu, Debian, TrueNAS, Proxmox, and similar systems, enabling Above 4G Decoding usually has no obvious downside.

Still, keep these points in mind:

Very old 32-bit operating systems may not be suitable.
Some very old BIOS implementations or legacy PCIe devices may be incompatible.
If the system cannot boot after changing BIOS settings, clear CMOS or restore defaults.
If you enable ReBAR / SAM as well, verify that the GPU, motherboard, OS, and driver support it.

On modern hardware and 64-bit systems, it is usually a healthy low-level setting to keep enabled, especially when multiple PCIe devices are installed.

When should you enable it?

Consider enabling Above 4G Decoding when:

You use a 64-bit operating system.
Multiple PCIe devices are installed.
You have a discrete GPU, especially with 4GB or more VRAM.
You use JMB585, ASM1166, HBA, RAID, capture, or other expansion cards.
You are building a multi-disk NAS or router.
You use multi-GPU, AI accelerator, or local LLM hardware.
Installing a PCIe card causes boot freeze, black screen, or blinking cursor.
Each device works alone, but combinations fail.

If you are troubleshooting a JMB585 SATA expansion card freezing during POST, check it together with:

Disable CSM.
Disable unnecessary Storage OpROM.
Change PCIe speed from Auto or Gen3 to Gen2.
Enable Above 4G Decoding.
Try another PCIe slot.

What is it called in BIOS?

Different motherboard vendors use slightly different names. Common names include:

Above 4G Decoding
Above 4GB MMIO BIOS assignment
Memory Mapped I/O above 4GB
64-bit PCIe decoding
PCI 64-bit Resource Handling

Common menu locations include:

Advanced
PCIe Settings
PCI Subsystem Settings
Chipset
North Bridge
IO Ports
Boot

Some motherboards place it near Resizable BAR, while others hide it under advanced PCIe or chipset settings.

Summary

The core purpose of Above 4G Decoding is to let the motherboard allocate PCIe device MMIO / BAR address space above 4GB. It does not fix drivers; it addresses BIOS / PCIe resource allocation.

On a simple PC with few devices, it may feel invisible. On a multi-disk NAS, multi-NIC router, mini PC with JMB585 / ASM1166 SATA expansion card, multi-GPU workstation, or local AI box, it matters.

If installing a PCIe expansion card causes BIOS freezes, black screens, blinking cursor, missing devices, or failure only when multiple devices are installed together, Above 4G Decoding = Enabled is a BIOS option worth checking early. It is not a cure-all, but it helps modern 64-bit hardware escape the old below-4GB address-space limitation and reduces PCIe resource conflicts.

PCIe expansion card causes a blinking cursor before BIOS: how to troubleshoot POST freezes

Sun, 24 May 2026 00:46:52 +0800

If a PCIe expansion card is installed and the machine cannot even reach the BIOS screen, stopping at a black screen or blinking cursor before the motherboard finishes booting, this is usually not a Linux driver issue. It is an earlier hardware-level freeze.

At this stage, the operating system has not loaded yet, so Linux kernel parameters such as pci=nomsi and pcie_aspm=off cannot help. The problem happens during POST, the power-on self-test stage. Common failure points include PCIe link training, PCIe resource allocation, Option ROM loading, Legacy / UEFI compatibility conflicts, or a faulty expansion card.

In short: if you cannot even enter BIOS, do not start by changing Linux. First make the motherboard complete POST.

What this failure means

During a normal boot, the motherboard scans PCIe devices, assigns bus, I/O, MMIO, and other resources, and decides whether to load any Option ROM provided by the device. Some SATA expansion cards, HBAs, NICs, capture cards, or adapters include firmware for boot support or device initialization, and the motherboard firmware may try to read it.

If the expansion card, motherboard BIOS, PCIe slot, power, attached device, or Option ROM is incompatible, the system may freeze during motherboard self-test. Typical symptoms include:

Black screen with only a blinking cursor.
Stuck before or after the motherboard logo.
Del, F2, F11, or F12 cannot enter BIOS or the boot menu.
Everything works after removing the PCIe expansion card.
NVMe, GPU, NIC, or existing boot device works normally when the card is removed.

This means the motherboard has not had a chance to hand control to the operating system; the card has already blocked the boot process.

Which PCIe expansion cards commonly trigger this

This POST freeze does not only happen with JMB585 SATA cards. Any PCIe device that the motherboard needs to initialize, allocate resources for, or load Option ROM from can trigger similar problems.

Common examples include:

JMB585, ASM1166, and similar PCIe SATA expansion cards.
LSI / Broadcom HBA or RAID cards.
2.5G, 10G, copper, or fiber NICs.
PCIe to M.2 / U.2 / SATA adapters.
Video capture cards.
USB 3.x expansion cards.
Older GPUs, RAID cards, or server pull cards with Option ROM.
Cheap PCIe cards with poor build quality, modified firmware, or broken EEPROM.

The device may not be “dead.” It may simply be incompatible with the current motherboard BIOS, PCIe lane routing, PCIe speed, boot mode, or address resource allocation.

Why Linux kernel parameters do not work yet

Parameters such as pci=nomsi, pcie_aspm=off, and libata.force are Linux kernel boot parameters. They only take effect after the kernel has loaded.

A blinking cursor before BIOS, a freeze before the motherboard logo, or a keyboard that cannot enter BIOS means the system is still in POST. The code running is motherboard firmware, not the Linux kernel. Linux has not started yet, so it cannot read those parameters.

For this class of failure, do not start by editing /etc/default/grub. Focus first on:

BIOS / UEFI boot mode.
CSM / Legacy compatibility layer.
PCIe Option ROM.
PCIe link training.
PCIe address space and resource allocation.
Expansion card, slot, power, and attached devices.

Step 1: disconnect devices attached to the expansion card

Start with the lowest-risk test. Leave the PCIe expansion card installed, but disconnect SATA data cables, attached device cables, or disk power from whatever is connected to it. Let the card sit in the motherboard with no attached devices.

Then boot and test:

If the system can enter BIOS after disconnecting disks or devices, the expansion card itself probably did not hard-lock the motherboard. The problem may be one disk, cable, power path, or boot-device detection.
If it still freezes, the problem is more likely between the expansion card and the motherboard PCIe / BIOS compatibility.

Why can attached disks cause POST freezes? Common reasons include:

A disk has a damaged boot sector or partition table, and the BIOS misidentifies it as a boot device and hangs while reading it.
Multiple HDDs spin up at once and the power supply cannot handle the transient current.
A SATA cable has poor contact, causing controller initialization to time out.
A disk is in poor health and slows down initialization.

If it boots after disconnecting disks, reconnect them one by one to find the specific disk or cable that triggers the problem.

Step 2: remove the card and disable CSM in BIOS

Many PCIe expansion cards freeze during POST because of the CSM / Legacy boot compatibility layer.

CSM stands for Compatibility Support Module. It lets UEFI motherboards support old Legacy boot behavior. The problem is that some cheap SATA expansion cards or modified cards include old Option ROMs. When the motherboard runs in CSM mode, it may try to load those old boot firmwares, which can conflict with modern UEFI firmware.

Why CSM and Option ROM can freeze POST

During POST, the motherboard enumerates PCIe devices and checks whether they provide boot firmware. Older storage cards, RAID cards, HBAs, NICs, and SATA expansion cards may provide Option ROM so the motherboard can recognize the device before the operating system starts, or even boot from it.

The problem is that Option ROM depends heavily on BIOS implementation. Some expansion cards have outdated, modified, damaged, or server-specific Option ROMs. When a modern consumer motherboard tries to load them under CSM / Legacy mode, it may enter an initialization loop, black screen, blinking cursor, or keyboard lock.

Disabling CSM and Storage OpROM prevents the motherboard from executing the card’s own pre-boot firmware. If your system disk is not connected to that expansion card, most NAS and data-disk scenarios do not need to boot from it. Letting Linux or Windows recognize it after boot is usually more stable.

Steps:

Shut down and remove power, then remove the PCIe expansion card.
Boot with the original GPU, iGPU, or existing boot device and enter BIOS.
Find CSM, Compatibility Support Module, or Legacy Boot.
Set CSM to Disabled.
Use UEFI Only boot mode if possible.
Save BIOS settings and shut down.
Reinstall the PCIe expansion card and test again.

If disabling CSM lets the machine pass POST, the likely cause was Legacy Option ROM or boot compatibility conflict.

Step 3: disable PCIe / Storage Option ROM

Some BIOS menus provide more detailed Option ROM controls, such as:

PCIe Option ROM
Storage OpROM
Mass Storage Controller Option ROM
Launch Storage OpROM Policy
Option ROM Messages

If you find a similar option, set the expansion card slot or storage-controller Option ROM to:

`1`	`Disabled`

or:

`1`	`Do Not Launch`

This tells the motherboard not to load boot firmware from the card, and to leave it as an ordinary PCIe device for the operating system to detect later.

If the system disk is not attached to this expansion card and the card is only used for data disks, NAS disks, warehouse disks, NICs, or capture devices, you usually do not need to boot from it. Disabling its Option ROM is often safer.

Step 4: force PCIe speed to Gen2 or Gen1

Many cards advertise PCIe Gen3 links, but the motherboard, adapter, cabling, slot, or card build quality may not be good enough. PCIe link training may fail at Gen3 speed, leaving the motherboard waiting for device initialization.

What PCIe Gen3 link-training failure looks like

When a PCIe device is installed, the motherboard and device negotiate link width and speed, such as x1, x2, x4, and Gen1, Gen2, Gen3. This process is called Link Training.

If the device, slot, adapter, motherboard traces, or power is unstable, both sides may fail to negotiate at higher speeds. Common symptoms include:

Black screen or blinking cursor before BIOS after installing the card.
Motherboard logo hangs for a long time and keyboard input does not respond.
Sometimes it boots, sometimes it hard-freezes.
Forcing PCIe Gen2 makes it stable.
Moving to another slot makes it stable.
The card works in a chipset slot but not a CPU-connected slot, or the opposite.

This is not an operating-system disk-drop issue. The motherboard and device have not finished PCIe link initialization yet. Forcing Gen2 / Gen1 lowers signal rate and trades theoretical bandwidth for stable boot.

Steps:

Remove the PCIe expansion card.
Enter BIOS.
Find the speed setting for the target PCIe slot, such as PCIe Speed, PCIe Link Speed, or Max Link Speed.
Change Auto or Gen3 to Gen2.
If Gen2 is still unstable, try Gen1.
Save, shut down, reinstall the card, and test.

For SATA HDDs, Gen2 x1 or Gen2 x2 is often enough. When stability matters, do not insist on Gen3.

If BIOS does not provide a PCIe speed setting, only then consider physical down-training methods. Some users tape selected gold-finger pins to force a card into x1 mode and test whether the second PCIe lane or high-speed signal quality is the problem. This is risky and easy to do wrong, so it should not be the first choice. Prefer BIOS speed limiting.

Step 5: enable Above 4G Decoding

If the motherboard has NVMe, GPU, wireless card, HBA, capture card, or multiple PCIe devices, BIOS must assign address space and MMIO resources during POST. Older boards or conservative BIOS resource allocation may freeze because of insufficient resources or address conflicts.

Try enabling:

`1`	`Above 4G Decoding`

It is often under Advanced, PCIe Settings, PCI Subsystem Settings, Chipset, or similar menus.

This option allows PCIe devices to use address space above 4GB, helping reduce resource allocation problems in multi-device systems. Although it is often mentioned for GPU passthrough, mining cards, HBAs, and multi-PCIe setups, it is also worth trying for SATA expansion cards that freeze during POST.

Step 6: change PCIe slots

Do not test only one slot. Different PCIe slots may be wired differently:

The long slot near the CPU is often CPU-connected and intended for GPUs.
Some short slots or secondary long slots may come from the chipset PCH.
Some slots share lanes with NVMe, SATA, Wi-Fi, or other devices.

If the expansion card freezes in a CPU-connected slot, try a chipset slot or lower-bandwidth slot. If the PCH slot is unstable, try another slot.

Also check the motherboard manual for lane-sharing rules, such as “this PCIe slot is disabled when this M.2 slot is populated.”

Recommended fast troubleshooting path

If you want to restore boot quickly, try this order:

Disconnect all devices attached to the expansion card, such as SATA disks, U.2 disks, or external cables.
If it still freezes, remove the card and enter BIOS.
Disable CSM and switch to UEFI Only.
Disable Storage OpROM or related PCIe Option ROM.
Enable Above 4G Decoding.
Force the target PCIe slot to Gen2; if that fails, try Gen1.
Save, shut down, reinstall the PCIe expansion card, and test.
If it passes POST, reconnect disks or devices one by one.

This path prioritizes the two most common causes: Legacy / Option ROM conflicts and PCIe Gen3 link-training incompatibility.

How to tell whether the card is bad or the motherboard is incompatible

If all steps above still end with a blinking cursor, do two cross-checks:

Test the same expansion card in another computer.
Test a known-good similar PCIe expansion card in the current motherboard.

Use this logic:

The same card freezes multiple computers: the card likely has a hardware or firmware problem.
The card freezes only on this motherboard but works elsewhere: motherboard BIOS, slot wiring, PCIe speed, or resource allocation is more likely.
Other similar expansion cards work in this motherboard: the original card is more suspicious.
Other PCIe devices are also unstable in this motherboard: suspect the slot, power, BIOS settings, or PCIe lane sharing.

If this card freezes multiple computers while other cards work on the current board, possible causes include:

Damaged expansion-card EEPROM / Option ROM data.
Short circuit or power problem on the card.
Gold-finger, solder joint, crystal, or power-chip hardware issue.
Firmware incompatible with many motherboard BIOS implementations.

If it freezes only on one motherboard, suspect BIOS, slot lanes, PCIe speed, CSM, or resource allocation.

Do not treat OS parameters as BIOS-stage fixes

Again, if the machine has not entered Linux, kernel parameters such as pci=nomsi, pcie_aspm=off, and libata.force do not take effect.

They only handle problems after the operating system takes over the hardware, such as disk drops, interrupt errors, and PCIe ASPM wake failures under Linux. They cannot help with a blinking cursor before BIOS or a POST-stage freeze because they never get a chance to run.

For this class of failure, focus on:

BIOS settings.
PCIe link training.
Option ROM.
Slot and resource allocation.
Physical condition of the expansion card and attached devices.

Summary

When a PCIe expansion card causes a blinking cursor before BIOS, the system is stuck during POST. The most common fixes are:

Disconnect all attached devices to rule out disk or power triggers.
Disable CSM and use pure UEFI.
Disable Storage / PCIe Option ROM.
Lower PCIe speed from Auto / Gen3 to Gen2 or Gen1.
Enable Above 4G Decoding.
Try another PCIe slot.

If none of these works and the card also freezes other computers, strongly suspect hardware or firmware damage on the card itself. For NAS and storage servers, stability matters more than attractive specs. With POST-level freezes, first make the motherboard pass self-test reliably, then troubleshoot Linux kernel parameters and drivers.

pci=nomsi and pcie_aspm=off explained: troubleshooting SATA expansion cards not detected, dropping disks, or freezing on Linux

Sun, 24 May 2026 00:41:23 +0800

When using PCIe SATA expansion cards on Linux or Ubuntu, users often run into disks not being detected, disks dropping after some runtime, system freezes, or boot problems around PCIe link training. Common examples include JMB585 and ASM1166 SATA cards, especially in NAS boxes, mini PCs, industrial PCs, modified motherboards, or cheap adapter setups.

pci=nomsi and pcie_aspm=off are two Linux kernel parameters often used when troubleshooting this class of problem. They both involve PCIe, but they address different layers:

pci=nomsi mainly targets interrupt signaling problems, meaning the way the device notifies the CPU is unreliable.
pcie_aspm=off mainly targets PCIe power management problems, meaning the link fails to wake reliably after entering a low-power state.

If you treat these two options as the same kind of fix, troubleshooting becomes guesswork. A better approach is to look at the symptoms and decide whether interrupts, link power management, or the hardware itself is the more likely suspect.

pci=nomsi: disable message-signaled interrupts

pci=nomsi can be read as:

PCI: PCI-related devices.
no: disable.
MSI: Message Signaled Interrupts.

It tells the Linux kernel not to use MSI / MSI-X interrupt mechanisms for PCI devices, and to fall back to the older INTx interrupt mode.

What is MSI?

Traditionally, hardware devices notify the CPU through physical interrupt pins, known as legacy IRQs. This works, but sharing and scaling are limited.

MSI / MSI-X came later. Instead of pulling a physical interrupt pin, the device writes a message to a specific memory address. When the CPU receives that message, it knows which device raised the interrupt. On modern systems, MSI / MSI-X is usually more flexible and better suited for high-concurrency devices.

The problem is that not every PCIe expansion card implements MSI reliably. Some cheap cards, retired enterprise cards, bridge-chip designs, or SATA controllers with poor firmware may produce abnormal MSI messages, lost interrupts, or interrupt storms under Linux drivers.

Common symptoms include:

The machine hangs while detecting the PCIe expansion card during boot.
The SATA expansion card does not detect disks at all.
Random system freezes.
dmesg shows errors such as irq xx: nobody cared.
The card appears to work under Windows but is unstable under Linux.

The core problem is not the hard disk or filesystem. It is the interrupt communication path between the device and CPU.

What happens after adding pci=nomsi?

Enable:

`1`	`pci=nomsi`

This tells the Linux kernel not to let PCI devices use advanced MSI message interrupts, and to fall back to legacy INTx interrupts.

This may slightly reduce performance and interrupt handling efficiency, especially on high-throughput or high-interrupt devices. For home NAS setups, SATA expansion cards, and ordinary hard-drive arrays, the practical impact is usually small. The value is that it bypasses MSI compatibility bugs in some device firmware or bridge chips, allowing the system to identify the device and handle I/O reliably.

In short, pci=nomsi addresses “the device’s way of notifying the CPU is unreliable.”

pcie_aspm=off: disable PCIe Active State Power Management

pcie_aspm=off can be read as:

PCIe: PCI Express.
ASPM: Active State Power Management.
off: disable.

It disables PCIe link power-saving mechanisms, preventing PCIe links from entering low-power states.

What is ASPM?

ASPM is a PCIe power-saving mechanism. When the system sees that a PCIe link is idle, it can move the link into a lower-power state such as L0s or L1. When the device needs to transfer data again, the link wakes back up to normal operation.

On well-designed hardware, this saves power and is almost invisible to users. On some consumer motherboards, mini PCs, industrial systems, cheap SATA cards, adapters, or systems with weaker signal quality, the problem is “it goes to sleep and does not wake cleanly.”

A typical case is a JMB585 or ASM1166 PCIe SATA card entering a low-power state after being idle. The next disk access requires the link to wake from L1. If the controller, motherboard, riser, power, or firmware quality is not good enough, wake-up may be too slow or the physical signal may glitch. The Linux kernel may then think the device briefly disappeared.

Typical dmesg messages include:

1
2
3

pcieport 0000:00:1c.0: PCIe Bus Error: severity=Corrected, type=Physical Layer
ata1: link is slow to respond, please be patient
ata1: COMRESET failed (errno=-16)

This may be followed by:

Disk dropout.
Degraded arrays.
Filesystem remounted read-only.
NAS services failing.
System I/O hangs.
Disk temporarily returns after reboot.

The frustrating part is that the problem may not appear at boot. It often happens after the system has been running, after an idle period, or during a load transition.

What happens after adding pcie_aspm=off?

Enable:

`1`	`pcie_aspm=off`

This tells the kernel to disable system-wide PCIe ASPM. PCIe links should remain in normal connected states as much as possible, whether idle or busy, instead of entering low-power sleep.

The side effect is slightly higher power use. For desktops, NAS boxes, and mini PCs, this is often only hundreds of milliwatts to one or two watts. For laptops, it may affect battery life. The benefit is fewer disk drops, link-training errors, and physical-layer errors caused by PCIe link sleep and wake.

In short, pcie_aspm=off addresses “the PCIe link does not wake reliably after sleeping.”

The difference between the two parameters

They solve two different classes of problems:

Parameter	Core problem	Common symptoms	Main side effect
`pci=nomsi`	Interrupt signaling conflicts, poor MSI / MSI-X compatibility	Boot hangs, no disk detection, `irq xx: nobody cared`, system freeze	Slightly lower interrupt efficiency under very high concurrency
`pcie_aspm=off`	PCIe power-save wake failure, unstable link signal	Works at boot, drops disks later, `PCIe Bus Error`, `COMRESET failed`	Slightly higher power use, slightly lower laptop battery life

They do not replace each other. One controls interrupts, the other controls link power management.

If the system hangs during boot or the device is never detected, suspect pci=nomsi first. If it boots normally but drops disks later, or dmesg shows Physical Layer, COMRESET, or “link is slow to respond” messages, suspect pcie_aspm=off first.

Should you add both?

Many NAS users add both at once:

`1`	`pci=nomsi pcie_aspm=off`

This is a quick troubleshooting method, especially with JMB585, ASM1166, mini PCs, adapter cards, uncertain power, and uncertain cabling. It can bypass MSI compatibility issues and ASPM wake problems at the same time.

From a troubleshooting perspective, it is better to record symptoms and logs first:

If you see interrupt errors or boot hangs, try pci=nomsi first.
If you see disk drops, PCIe Bus Error, or COMRESET after runtime, try pcie_aspm=off first.
If the system is unstable and you need to restore service quickly, add both, then test them separately later.

This helps you identify the actual class of problem, which is useful when changing cards, slots, motherboards, or BIOS settings later.

How to make it permanent on Ubuntu / Debian

Edit the Grub configuration file:

`1`	`sudo nano /etc/default/grub`

Find this line:

`1`	`GRUB_CMDLINE_LINUX_DEFAULT="quiet splash"`

Append the parameters inside the quotes, separated by spaces. For example:

`1`	`GRUB_CMDLINE_LINUX_DEFAULT="quiet splash pci=nomsi pcie_aspm=off"`

Save and exit. In Nano, press Ctrl+O, confirm with Enter, then press Ctrl+X.

Update Grub and reboot:

1
2

sudo update-grub
sudo reboot

After reboot, check whether the kernel command line is active:

`1`	`cat /proc/cmdline`

If the output contains pci=nomsi and pcie_aspm=off, the parameters are active for the current boot.

What else should you check?

These two parameters are useful, but they are not universal fixes for every disk-drop problem. When troubleshooting SATA expansion cards and NAS disk drops, also check:

Loose or poor-quality SATA data cables.
Stable disk power, especially when many disks spin up at once.
Poor PCIe slot contact.
Expansion card overheating.
BIOS options related to PCIe ASPM, Above 4G Decoding, and PCIe speed.
Known firmware issues in the SATA expansion card.
Disk SMART warnings, bad sectors, or I/O errors in system logs.

If disk SMART is already reporting errors, or power delivery is unstable, kernel parameters alone will not solve the underlying problem.

Summary

pci=nomsi and pcie_aspm=off are both common troubleshooting parameters for unstable PCIe SATA expansion cards on Linux, but they work at different layers:

pci=nomsi: disables MSI / MSI-X to bypass interrupt compatibility issues.
pcie_aspm=off: disables PCIe ASPM to avoid wake failures after link power saving.

For JMB585, ASM1166, NAS systems, mini PCs, and cheap PCIe cards, these two parameters often help. The safer approach is to inspect dmesg, decide whether the problem looks like interrupts or link power management, then choose one or both.

They are troubleshooting tools, not a replacement for good hardware. If the system becomes stable after adding them, the problem is likely in interrupt compatibility or PCIe power management. If disks still drop, continue checking power, cables, cooling, disk health, and the expansion card itself.

Hard Drive Prices Are Soaring: Do Not Expand Your NAS Yet, Try a $200 TerraMaster + HC620 Cold Data Setup

Mon, 04 May 2026 11:46:53 +0800

When hard drive prices rise sharply, a full NAS does not always need an immediate drive upgrade. If the main NAS is still working normally and only running out of capacity, it is often better to separate data by access frequency: keep frequently used hot data on the original NAS, and move rarely used cold data and backups to a separate cold-storage disk.

This article records a low-cost approach: use large HC620 drives for cold data, then use an inexpensive TerraMaster F2-220, F2-221, or F4 as the migration and mount node. It does not aim for high performance. It solves one practical problem: during a period when upgrading disks is not cost-effective, first free up space on the main NAS.

Idea

Sort data by access frequency first:

Hot data: photos, work files, recent downloads, frequently watched videos. Keep these on the main NAS.
Cold data: old media libraries, archived materials, large files that rarely change. Move these to HC620.
Backup data: data that only needs periodic writes and occasional reads. This can also be stored on HC620.

For HC620 usage scenarios, see the site article: Misunderstandings and Correct Usage of Western Digital HC620 SMR Drives. It is better suited to sequential writes, long-term storage, and random reads. It is not suitable for workloads with frequent deletes and repeated writes.

If the goal is simply to free up space on the main NAS, I do not recommend replacing the main NAS disks on a large scale while hard drive prices are high. Move rarely used data out first, and let the main NAS continue handling hot data. This is usually more cost-effective.

Why Use an Old TerraMaster

The problem with HC620 is not capacity, but convenience. It has requirements for the operating system, interface, and usage pattern, so putting it directly into a USB hard drive enclosure is not a good fit.

An old TerraMaster F2-220, F2-221, or some F4 models can be used as a low-cost cold-data node. The advantages are straightforward:

Cheap. A used F2-220 is often under 200 RMB.
Small footprint and acceptable power consumption.
The system can be installed on a USB drive, so it does not occupy a drive bay.
Two or more SATA bays are available, making it suitable for HC620 archive disks.

These old machines are not powerful, but they are enough for cold-data migration, CIFS mounting, and background copying. Although the F2-220 only has older SATA 3G ports, HC620 can still reach around 200MB/s in outer-track disk-to-disk copies in testing. For cold-data migration, this is not slow. The bottleneck is often the network, the source disk condition, or the number of files.

If the onboard gigabit network is not fast enough, you can also add a USB 2.5G network adapter. A cold-data node does not need complicated modification. As long as the system recognizes the adapter, and both the switch and main NAS support 2.5G, the network bottleneck can be raised noticeably.

Prepare Video Output

If the machine has no HDMI port, you need VGA for system installation. The F2-220 has an internal VGA header. You can use a motherboard internal 12-pin VGA adapter cable: one end connects to the internal header, and the other end exposes a standard VGA connector for a monitor.

For VGA adapter specifications and notes, see: Installing fnOS on TerraMaster F2-220: VGA Output. In short, search terms include “12Pin VGA adapter cable”, “motherboard 12-pin VGA cable”, and “2.0mm 12Pin to VGA”. Before buying, check pitch, direction, and pinout.

Install Ubuntu Server to a USB Drive

Install Ubuntu Server to a USB drive so all hard drive bays remain available for data disks.

The F2-220 is relatively weak, so installing directly on it can be slow. A more efficient method is to plug the USB drive into a faster computer, complete the Ubuntu Server installation there, then move the USB drive back to the TerraMaster. As long as the boot mode is compatible, it usually works directly.

After installation, check the network configuration carefully. Otherwise, the machine may boot but have no network connection, making SSH management impossible.

Configure Networking

After entering the system, check the network interface name first:

`1`	`lshw -c network`

The sample output shows the logical name:

  *-network
       description: Ethernet interface
       product: RTL8111/8168/8211/8411 PCI Express Gigabit Ethernet Controller
       vendor: Realtek Semiconductor Co., Ltd.
       physical id: 0
       bus info: pci@0000:02:00.0
       logical name: enp2s0
       version: 07
       serial: 6c:bf:b5:00:63:ab
       size: 1Gbit/s
       capacity: 1Gbit/s
       width: 64 bits
       clock: 33MHz
       capabilities: bus_master cap_list ethernet physical tp mii 10bt 10bt-fd 100bt 100bt-fd 1000bt 1000bt-fd autonegotiation
       configuration: autonegotiation=on broadcast=yes driver=r8169 driverversion=6.8.0-111-generic duplex=full firmware=rtl8168e-3_0.0.4 03/27/12 ip=192.168.8.205 latency=0 link=yes multicast=yes port=twisted pair speed=1Gbit/s
       resources: irq:17 ioport:e000(size=256) memory:d0604000-d0604fff memory:d0600000-d0603fff

Here the interface name is enp2s0. Then edit the netplan configuration:

`1`	`sudo more /etc/netplan/01-install-config.yaml`

If the file does not exist, create it with this content:

network:
  version: 2
  ethernets:
    enp2s0:
      dhcp4: true

Replace enp2s0 with the actual interface name on your machine. Save the file and apply it:

`1`	`sudo netplan apply`

After the network is restored, you can SSH into the TerraMaster and continue without keeping a monitor connected.

Format HC620 as btrfs

If the HC620 is new, or if all data on it has been confirmed unnecessary, format it as btrfs first. The following operations erase the target drive. Confirm the disk device before running them. Do not format the main NAS share or the system USB drive by mistake.

List current disks:

`1`	`lsblk -o NAME,SIZE,MODEL,SERIAL,FSTYPE,MOUNTPOINTS`

You can also check stable disk paths:

`1`	`ls -l /dev/disk/by-id/`

After confirming which device is the HC620, unmount any existing mount point:

1
2

sudo umount /dev/sda 2>/dev/null
sudo umount /dev/sda1 2>/dev/null

If you want to create btrfs directly on the whole disk:

`1`	`sudo mkfs.btrfs -f -O zoned -d single -m single -L HC620_01 /dev/sda`

Parameter notes:

-f: force file-system creation, avoiding old signatures blocking the format.
-O zoned: enable the zoned feature, suitable for drives like HC620 that need zone-aware sequential writes.
-d single -m single: use single-disk mode for both data and metadata.
-L HC620_01: set a label for easier identification.

If your system or kernel does not handle zoned btrfs well, continue with the earlier test notes: Is a New WD HC620 14T Drive for About 600 RMB Worth Buying?. Compatibility for this type of drive depends on kernel version, SATA controller, and file-system support. Do not import real data until the setup behaves normally.

After formatting, test with a temporary mount:

1
2
3

sudo mkdir -p /mnt/disk1
sudo mount /dev/sda /mnt/disk1
df -h

After confirming it mounts correctly, write /etc/fstab for automatic mounting. For long-term use, prefer /dev/disk/by-id/ instead of /dev/sda to avoid device-name changes after reboot.

Configure Mounts

This cold-data node usually needs to mount two types of paths:

The main NAS share, used to read data that needs to be migrated.
The local HC620 data disks, used to store cold data and backups.

Create mount directories first:

`1`	`sudo mkdir -p /mnt/xxxxx /mnt/disk1 /mnt/disk2`

If you need to mount CIFS/SMB shares, install the tools:

1
2

sudo apt update
sudo apt install cifs-utils

Then edit /etc/fstab and add lines like these:

1
2
3

//192.168.x.xxx/xxxxx   /mnt/xxxxx cifs auto,username=xxxxx,password=xxxxx,uid=997,gid=997,file_mode=0777,dir_mode=0777,nofail 0 0
/dev/sda  /mnt/disk1  auto  defaults,nofail  0  0
/dev/sdb  /mnt/disk2  auto  defaults,nofail  0  0

The first line mounts the main NAS share. The next two lines mount local disks.

In real use, prefer stable paths such as /dev/disk/by-id/ for data disks to avoid /dev/sda and /dev/sdb changing order after reboot. HC620 formatting and mounting notes are also covered in the earlier record: Is a New WD HC620 14T Drive for About 600 RMB Worth Buying?.

Test the mount after editing:

1
2

sudo mount -a
df -h

After confirming that both the main NAS share and local data disks appear, start migrating data.

Copy Files in the Background

For large data migrations, do not run plain cp directly in the SSH foreground. The preferred setup here is screen + mc: screen keeps the session alive after SSH disconnects, while mc provides a clearer two-pane file-management interface.

mc is well suited to manually organizing cold data. Open the main NAS mount on the left, open the HC620 data disk on the right, select files, and press F5 to copy. During copying, it shows both current-file progress and total progress, which is much easier to read than raw command-line output when moving many files.

The image above illustrates the copy-progress window. The Midnight Commander manual also notes that copy, move, and delete operations show a file-operation dialog in verbose mode, with current-file and total progress available.

Install the tools:

`1`	`sudo apt install screen mc rsync`

Start a background session:

`1`	`screen -S cold-data`

Run mc inside screen:

mc

The usual workflow is to open the source directory and target directory in the two panels, then operate with shortcuts:

Tab: switch between panels.
Insert: select multiple files or directories.
F5: copy to the other panel.
F6: move or rename.
F8: delete, use carefully.

If you need a more scriptable and repeatable sync task, use rsync instead:

`1`	`rsync -avh --progress /mnt/xxxxx/old-data/ /mnt/disk1/old-data/`

Even if SSH disconnects during copying, the screen session remains alive. Reconnect and run:

`1`	`screen -r cold-data`

You will return to the original copy task.

Usage Advice

This setup is for cold data and backups. Do not use HC620 as a high-frequency write disk. Suggested usage:

Keep hot data and daily services on the main NAS.
Store large long-term files, media libraries, and archive materials on HC620.
Migrate mainly by sequential writes; avoid frequent deletes and repeated small-file writes.
Keep at least two copies of important data. Do not keep the only copy on a single disk.
After migration, sample-check files and confirm that directory and file counts look normal.

If hard drive prices fall later, upgrading the main NAS array can still be considered. For now, using a low-cost node to relieve capacity pressure keeps both risk and spending more controllable.

Summary

When NAS space is full, buying new drives immediately is not the only answer. Treat the main NAS as the hot-data device, treat HC620 as cold-data and backup storage, and use a cheap TerraMaster F2-220, F2-221, or F4 as the mount and copy node. This is a low-cost and practical transitional setup.

The key is not performance, but division of responsibility: the main NAS keeps the daily experience smooth, while cold data is stored separately. This frees up space and avoids a large upgrade cost during a period of high hard drive prices.

Installing fnOS on TerraMaster F2-220: F3 Backplane, NVMe, and BIOS Module Injection

Mon, 04 May 2026 06:09:40 +0800

This is a practical note on installing fnOS on a TerraMaster F2-220. The goal is to replace the original TOS and keep using the NAS after official support for the F2-220 has ended. The process also verifies that the F3 backplane can work on the F2-220, and solves the issue where the BIOS cannot boot from NVMe.

The original F3 backplane project was verified on the F2-221 with a J3355 platform. The F2-220 uses the J1800 platform, so compatibility was not guaranteed. A V1.1 version existed in a project fork with fewer components, lower cost, and less assembly difficulty, so that version was used for testing.

PCB Fabrication and Soldering

Backplane project: arnarg/f3_backplane. The board used here is the V1.1 version from a fork. Its core goal is to keep the original SATA drive bays while exposing an NVMe SSD position from the backplane connector.

Multiple PCBs were received after fabrication. One detail appeared during soldering: after soldering the M.2 connector, it became clear that the SATA connector was different from common SATA connectors.

A fully matching native SATA connector was not found on Taobao, so an existing connector was modified instead: the pins were pulled out, positions were swapped, and then the connector was soldered back to the board.

The key takeaway is that the F3 backplane approach can be tried on the F2-220, but SATA connector selection needs special attention. Do not order only by looking for a generic SATA connector.

VGA Output

The F2-220 has no exposed video output, but it has an internal 12-pin VGA header. You need an internal motherboard 12Pin VGA adapter cable. One end connects to the 12-pin header inside the machine, and the other end is usually a standard DB15 VGA female connector for an external monitor.

Useful search keywords include “12Pin VGA adapter cable”, “motherboard 12-pin VGA adapter cable”, and “2.0mm 12Pin to VGA”. Before buying, compare the connector direction, pitch, and pinout against a photo of the internal header. Do not order based only on the “12Pin” label.

This step is important for installation. Without video output, BIOS and installer troubleshooting becomes much harder.

Installing fnOS

Boot the fnOS installer through Ventoy. The installer can see the NVMe SSD, which means the backplane and NVMe hardware path are working.

However, after installation, removing the boot drive causes the machine to reboot into the BIOS screen instead of entering fnOS. The BIOS boot list does not contain the NVMe SSD. If fnOS is installed to a USB drive and booted from there, the system can still see the NVMe drive normally.

This indicates:

NVMe hardware detection is fine.
Linux can access the NVMe drive.
The failure point is the BIOS boot stage.
The F2-220 platform is old, and the stock BIOS likely lacks an NVMe boot module.

Backing Up the BIOS

At this point, fnOS can already boot from a USB drive. Since fnOS is Debian-based, flashrom can be used inside the system to back up and flash the BIOS.

Flashing BIOS is risky. Prepare a programmer if possible, so recovery is still possible after a failed flash.

Install flashrom:

1
2

sudo apt update
sudo apt install flashrom -y

Check whether the BIOS chip can be detected:

`1`	`sudo flashrom -p internal`

Detected chip information may look like this:

`1`	`Found Winbond flash chip "W25Q64.W" (8192 kB, SPI) mapped at physical address 0x00000000ff800000.`

Back up the original BIOS. Replace the chip model in the command with the actual result from your machine:

`1`	`sudo flashrom -p internal -c "W25Q64.W" -r backup_factory.bin`

Injecting the NVMe Module

The backed-up BIOS is a .bin file. You can transfer it to a PC with WinSCP, then refer to the Bilibili tutorial 让老主板用上 Nvme 协议的固态 to inject the NVMe module into the BIOS file.

After processing, transfer the modified BIOS file back to fnOS.

Do not blindly reuse someone else’s BIOS file. Different machines, BIOS versions, and flash chips may differ. The safer approach is to back up your own original BIOS and modify that backup.

Flashing the New BIOS

The flash command is shown below. Replace the chip model, firmware path, and file name according to your actual setup:

`1`	`sudo flashrom -p internal -c "W25Q64.W" -w /vol1/NEW_NVME.bin`

When the output shows this line, verification has passed:

`1`	`Verifying flash... VERIFIED.`

After flashing, the BIOS boot list may show a PATA entry. On older BIOS setups with an injected NVMe module, the NVMe boot entry often appears as PATA. Seeing it means the BIOS can now recognize the NVMe boot path.

Result

Final result:

F3 Backplane V1.1 can detect NVMe on the TerraMaster F2-220.
The fnOS installer can see the NVMe SSD.
The stock BIOS cannot boot directly from NVMe.
After injecting the NVMe module into the BIOS, a PATA boot entry appears.
The machine can boot fnOS from NVMe after the BIOS modification.

Testing feedback also notes that this NVMe channel is only a little over 300MB/s. That is enough for a system drive. There is no need to use a high-end SSD; even a small Optane drive can be sufficient.

Notes

This is not a risk-free general tutorial. It is closer to a hardware and BIOS modification record. Before trying it, note the following:

F2-220 and F2-221 use different platforms, so F2-221 results should not be treated as identical to F2-220 results.
The F3 backplane requires PCB fabrication and soldering. The SATA connector may also require pin modification.
A suitable internal VGA adapter cable is needed for installation and troubleshooting.
BIOS flashing can brick the machine. Prepare a programmer and keep the original backup.
The chip model in the flashrom command must match the chip detected on your own machine.
Do not directly flash someone else’s modified BIOS. Inject the NVMe module into your own backup first.

The value of this note is that it adds real F2-220 test results: the F3 backplane idea is not limited to the F2-221, and the F2-220 can also use an NVMe system drive. The real blocker is not Linux detecting NVMe, but whether the BIOS supports NVMe booting.

fnNAS forum test thread: 铁威马F2-220折腾飞牛OS过程

TerraMaster F2-221 NAS Backplane Pinout Notes

Mon, 04 May 2026 06:02:56 +0800

This note documents the non-standard backplane connector pinout of the TerraMaster F2-221 NAS. The connector looks close to a PCIe edge connector, but it is not a standard PCIe slot. It is a custom TerraMaster backplane interface.

The connector carries SATA, power, reset, and PCIe signals at the same time. Once PCIe1 x1 is confirmed usable, a custom backplane can expose an M.2 M-key slot and use an NVMe SSD as an internal system drive.

The same idea also applies to the TerraMaster F2-220. Although the F2-220 and F2-221 use different platforms, a fnNAS forum test shows that F3 Backplane V1.1 can detect NVMe on the F2-220, and the NVMe drive is visible inside the OS installer. The extra work is that the old BIOS may not support booting from NVMe.

Summary

The F2-221 backplane connector contains:

Signals for two native SATA ports
12V, 5V, 3.3V, and GND
SATA drive power-control related signals
PERST#
At least one usable PCIe Gen2 x1 signal group
Partial clues for a second PCIe signal group, but not fully verified

PCIe1 can be used to expose an M.2 M-key NVMe slot. In testing, the NVMe drive runs at PCIe Gen2 x1, and the BIOS can detect and boot from it.

F2-220 testing points in the same direction: the hardware can detect NVMe, but the BIOS boot stage may require injecting an NVMe module, and the boot entry may appear as PATA.

Backplane Connector Pinout

The connector has B/A sides. ? means unknown or unconnected, and NC means not connected.

Pin	B side	A side
1	12V	?
2	12V	12V
3	12V	12V
4	GND	GND
5	SATA1 A+	SATA1 B+
6	SATA1 A-	SATA1 B-
7	GND	NC
8	5V	5V
9	5V	5V
10	?	5V
11	?	?
12	3.3V	GND
13	GND	3.3V
14	SATA2 A+	3.3V
15	SATA2 A-	GND
16	GND	SATA2 B+
17	PERST#	SATA2 B-
18	GND	GND
19	PCIe1 TX+	NC
20	PCIe1 TX-	GND
21	GND	PCIe1 RX+
22	GND	PCIe1 RX-
23	PCIe1 REFCLK+	GND
24	PCIe1 REFCLK-	GND
25	GND	PCIe2 RX+
26	GND	PCIe2 RX-
27	PCIe2 TX+	GND
28	PCIe2 TX-	GND
29	GND	PCIe2 REFCLK+
30	?	PCIe2 REFCLK-
31	?	GND
32	GND	?

PCIe1 has higher practical reference value. PCIe2 is not fully verified and should only be treated as a clue, not a reliable design basis.

Signal Source Reasoning

The stock F2-221 dual-bay backplane does not include a PCIe-to-SATA controller. SATA signals go directly from the motherboard connector into the backplane. The extra PCIe signals are mainly inferred from other multi-bay models in the same product family.

The TerraMaster F5-422 backplane uses two ASMedia ASM1061 chips. ASM1061 is a PCIe Gen2 x1 to dual-SATA controller. Combined with the Intel J3355 having 2 SATA ports and 6 PCIe Gen2 lanes, this suggests that multi-bay models expand SATA ports through PCIe.

Therefore, it is reasonable for the F2-221 motherboard connector to retain PCIe signals. The vendor likely reuses motherboard designs across models with different bay counts and changes functionality through the backplane.

PCIe Differential Pair Identification

PCIe differential pairs often go into inner layers after vias, so photos alone cannot trace the complete routing. One useful rule is that, in traditional PCIe designs, TX differential pairs usually have AC coupling capacitors.

The direction must be viewed in reverse:

TX from the ASM1061 controller’s perspective corresponds to RX on the CPU or motherboard side.
RX from the ASM1061 controller’s perspective corresponds to TX on the CPU or motherboard side.
REFCLK needs to be judged together with neighboring differential pairs and routing location.

This kind of pinout is better treated as hardware reverse-engineering material, not as an official specification.

Validation

F3 Backplane designs based on this pinout have completed the following validation:

The original two SATA drive bays remain usable.
PCIe1 can be routed to an M.2 M-key slot.
The NVMe SSD can be detected by BIOS.
The NAS can boot directly from the NVMe SSD.
btrfs scrub found no disk errors.
The system ran from the NVMe SSD for weeks without obvious issues.

The test NVMe SSD was a Patriot P300 128GB. hdparm result:

1
2
3

/dev/nvme0n1:
 Timing cached reads:   4554 MB in  2.00 seconds = 2279.68 MB/sec
 Timing buffered disk reads: 1222 MB in  3.00 seconds = 407.22 MB/sec

This speed matches the PCIe Gen2 x1 limitation. The goal is not to fully utilize NVMe performance, but to replace an external USB SSD with an internal system drive.

Notes

This pinout is useful as a reference for hardware reverse engineering and custom backplanes, but it should not be treated as official documentation.

The connector is not standard PCIe and cannot directly accept generic PCIe devices.
? pins are unverified and should not be connected to critical circuits casually.
PCIe2 is not fully verified and carries higher risk than PCIe1.
CLKREQ is not fully routed like a normal M.2 design, so ASPM may not work.
SATA power includes hot-swap related load switch and slow start logic; do not route only signal lines while ignoring power control.
If reproducing the design, measure your own motherboard and backplane again instead of relying only on photos.

Original project write-up: I made a new backplane for my Terramaster F2-221 NAS
F3 Backplane KiCad project: arnarg/f3_backplane
F3 Backplane pinout CSV: f3_backplane.csv
F2-220 compatibility test: 铁威马F2-220折腾飞牛OS过程

Seagate Exos 2X14 Dual-Arm HDD: Cheap, Fast, Large, and Not for Everyone

Fri, 01 May 2026 11:05:45 +0800

The Seagate Exos 2X14 / Mach.2 is a rather unusual enterprise mechanical hard drive. Its key selling point is not just capacity, but its dual-arm design: a single 14TB drive appears to the system as two 7TB logical disks, with each side using its own head-arm assembly for parallel access.

That makes it look very tempting on the used market. When ordinary 14TB enterprise drives are being pushed up in price, these retired dual-arm drives can sometimes offer 14TB of capacity for less money while delivering sequential speeds close to SATA SSD territory. But this is not a normal NAS drive that everyone should buy as a drop-in replacement. Its strengths and risks are both obvious, and they need to be understood before buying.

Why It Can Be So Fast

A normal mechanical hard drive has one head-arm assembly, so reads and writes are mainly handled by one group of heads at a time. The Exos 2X14 / Mach.2 splits one physical drive into two 7TB logical units, allowing two head-arm groups to work at the same time.

Each 7TB logical disk can reach roughly 250MB/s in sequential reads and writes, similar to many large enterprise HDDs. If the two 7TB logical disks are combined as RAID 0, large sequential transfers can approach 500MB/s when there is no network bottleneck. That is close to mainstream SATA SSD performance and enough to saturate a 2.5G network.

However, this boost mainly applies to large sequential transfers. 4K small files, fragmented files, and random access do not suddenly become fast just because of the dual-arm design and RAID 0. It is still a mechanical hard drive at heart, so small-file workloads remain slow.

The Biggest Barrier Is Hardware Compatibility

Most low-priced units available on the used market are retired server drives with SAS interfaces, not SATA models. That means they are not suitable for most off-the-shelf NAS systems.

Consumer and prosumer NAS devices from brands such as UGREEN, Synology, and QNAP are usually designed around SATA backplanes, and SAS drives often cannot be used directly. DIY NAS users also need extra hardware:

An available PCIe slot on the motherboard
A SAS HBA or RAID card, such as an LSI 2008 flashed to IT mode
A server SAS backplane, or cables such as SFF-8087 to SFF-8482 adapters
An operating system that can correctly identify the two logical disks from the same physical drive

The controller card itself may not be expensive. The real hassle is the full chain of cabling, compatibility, cooling, power, and available PCIe space. If the machine is already tight on space, airflow, cables, or expansion slots, this drive adds real friction.

Do Not Treat the Two 7TB Disks as Backups of Each Other

The easiest mistake is treating the two 7TB logical disks shown by the system as two independent drives. They are not two physical disks; they are two logical units inside the same physical hard drive.

If these two 7TB logical disks are configured as RAID 1, it may look like a mirror, but the practical value is very limited. They share the same enclosure, controller board, power path, and part of the same mechanical environment. If the physical drive, board, or power path fails, the original data and the supposed backup can disappear together.

RAID 5 and RAID 6 also require caution. Traditional RAID 5 usually tolerates the failure of one physical disk, but when a dual-arm drive fails, the array may effectively lose two 7TB logical disks at the same time. If the array design does not account for this failure model, redundancy can be defeated very easily.

So this type of drive is better understood as one fast, large, risk-concentrated disk, not as two independent disks that can safely protect each other.

How to Use It in NAS Systems

If hardware passthrough and driver recognition work properly, systems such as FNOS, TrueNAS, Unraid, and Windows can usually see the two 7TB logical disks. The key question is not whether the system can see them, but how they should be used.

In FNOS, the two 7TB logical disks can be combined into a RAID 0 storage space to gain sequential throughput.

In TrueNAS, creating a storage pool may trigger a prompt about using disks with the same serial number. If you are sure you want to use this drive, you can allow it, place the two logical disks into the same vdev, and choose Stripe instead of Mirror. Mirror creates an unreliable illusion of redundancy here.

In Unraid, it is not recommended to put the two logical disks into the main array with a parity disk. A better approach is to create a separate cache pool or dedicated high-speed pool, use Btrfs or ZFS for an independent RAID 0, and assign it to temporary high-speed data, downloads, transcoding cache, or data that can be rebuilt.

Windows can also identify and use the disks, with similar logic: striping can improve sequential performance, but it should not be treated as a real two-drive backup plan.

Lifespan, Temperature, and Power Still Matter

The dual-arm design improves performance, but it also makes the mechanical structure more complex. These drives contain two head-arm assemblies and more head components, which naturally means more mechanical risk points. Since most units on the used market are retired enterprise drives, real power-on hours, previous workload, handling history, and transport condition are often unclear. Specification-sheet endurance numbers should not be trusted blindly.

Power and cooling also matter. Under full load, power consumption may exceed 11W, and shell temperatures above 40 degrees Celsius are not unusual. If the drive is installed in a small case, dense drive cage, or low-airflow NAS, sustained heat can further affect stability and lifespan.

Who Should Buy It

This drive is suitable for people who are comfortable building a DIY NAS, already have the right SAS hardware, understand the risks of RAID 0, and mainly handle large sequential files. Media libraries, download caches, temporary project storage, and rebuildable data pools can all benefit from its capacity and speed.

It is not suitable for:

Users of off-the-shelf branded NAS systems
Users who do not want to buy a SAS card and adapter cables
Primary storage with high data-safety requirements
Users who want to use the two 7TB logical disks as a RAID 1 backup
Workloads dominated by small files, virtual-machine random I/O, or databases

If the goal is low-cost capacity and fast sequential reads and writes, the Exos 2X14 / Mach.2 is genuinely interesting. But its proper role is a cheap, fast, tinkerer-friendly special-purpose drive, not a universal NAS disk that everyone can buy without thinking.

Hard drives have prices; data has value. This kind of dual-arm drive can be worth buying, but it is best used only for recoverable, rebuildable, or separately backed-up data. Truly important files should still live inside a clear and reliable backup strategy.

Why Are 16-Core Board+CPU Combos So Cheap? Is a Xeon D-1581 Integrated Board Actually Worth Buying?

Wed, 29 Apr 2026 10:48:00 +0800

These Xeon D-1581 integrated board+CPU combos have started popping up again, and the reason is simple: the price looks extremely tempting.

The selling points are easy to recognize:

16 cores and 32 threads
motherboard and CPU together
multiple NICs
PCIe
a price that looks unusually low

On paper, it really does look like a dream board for NAS, AIO, download boxes, or home labs.
But whether this kind of board is worth buying has less to do with the core count itself and more to do with whether the use case matches.

The Short Verdict

The strengths are easy to see:

lots of cores
integrated board+CPU is convenient
expansion is usually better than many mini PCs
very comfortable for lots of background services

The weaknesses are just as clear:

the platform is old
single-core performance is mediocre
stability and compatibility depend a lot on the board itself
many cheap listings are really just old-platform risk being resold

So this is good for people who like tinkering, not for people who like wishful thinking.
If you clearly want it for NAS, containers, or a lab host, it can be very appealing. If you want a cheap, low-maintenance main machine, it will probably disappoint you.

Why This Kind of Board Feels So Attractive

The reason is simple: it stacks together several things people love hearing.

16 cores and 32 threads
multiple NICs and PCIe
motherboard and CPU included together
very low pricing after falling out of the server market

At the same price, a desktop platform may only get you an ordinary 4-core or 6-core chip, while this gives you 16 cores and 32 threads.
That is exactly why it is so tempting and also a little dangerous: what it really sells is thread count and I/O presence, not a complete user experience.

Strengths

1. It is genuinely comfortable for service-heavy use

This kind of board is best suited for:

NAS
Docker hosts
download boxes
home labs
light to medium virtualization

It is not about one task being especially fast. It is about being able to keep many things running on one machine at the same time.

2. Expansion is better than many mini PCs

If you need to:

add NICs
add an HBA
add storage adapter cards
experiment with storage and networking layouts

then this kind of board is usually more interesting than a mini PC.

3. Integrated board+CPU makes setup faster

You do not need to match a separate CPU and motherboard, and there is less compatibility guessing.
For people who like old-platform tinkering, that is genuinely useful.

Weaknesses

1. The platform is old

This is the biggest starting point.
An old platform means weaker single-core performance, older interface standards, and no reason to expect modern power efficiency.

2. It is not a great front-end daily machine

16 cores and 32 threads sound powerful, but this kind of board behaves more like a background worker than a responsive daily desktop.
If you try to use it as a main desktop PC, the feel will usually not make you happy.

3. Cheap often comes with risk

The common problem is not simply whether it powers on. It is more about:

mixed or unclear board origins
unstable BIOS and compatibility
possible pickiness with memory, NICs, or PCIe devices
needing to verify long-term stability yourself

In plain terms, cheap does not mean low-maintenance.

4. Power use may not be as low as you imagine

A lot of people imagine this as “many threads, low power, great for 24/7 use.”
Reality is not that simple. Total system behavior depends heavily on board design, cooling, and how much hardware you hang off it.

Who It Fits Best

The best fit is pretty clear:

people who want a low-cost NAS
people building a home lab
people who want to run many containers or services
people who accept old platforms and do not mind troubleshooting

Who It Does Not Fit Well

It is a poor fit for people who:

want a main desktop machine
want a cheap but hassle-free system
care a lot about power, noise, and support
do not want to troubleshoot things themselves

Final Line

A Xeon D-1581 board like this is not impossible to buy. It is just only good value in the right use case.

If you want threads, I/O, expansion, and a long-running service machine, it has real appeal.
If you want a modern platform, strong single-core speed, low hassle, and a good main-machine experience, it probably is not for you.

The shortest conclusion is:

The upside is more threads, more ports, and more expansion. The downside is an old platform, mixed board quality, and more tinkering.

NAS 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