TrueNAS + Syncthing: sync large datasets without public cloud

The safest way to sync a large workstation dataset to TrueNAS is to mount a dedicated dataset into the Syncthing app, make the workstation Send Only, make TrueNAS Receive Only, enable file versioning on TrueNAS, and add ZFS snapshots outside Syncthing. The crucial path detail is that Syncthing must use the container mount path—such as /data/family—not the TrueNAS host path such as /mnt/tank/syncthing/family. This gives you continuous device-to-device transfer without paying a public-cloud storage bill. It does not, by itself, give you a backup: corruption and deletion can still propagate. This guide uses the current TrueNAS Stable app and Syncthing 2.1.2, then separates our tested sync behavior from the TrueNAS UI steps we verified through official documentation.

The architecture to use

For a workstation-to-NAS copy where files are normally edited on the workstation, start with this layout:

Layer	Setting	Purpose
Workstation	Send Only	Treats the workstation as the reference copy and rejects remote changes
TrueNAS Syncthing folder	Receive Only	Accepts workstation changes without sending local NAS edits back
Syncthing on TrueNAS	File Versioning enabled	Retains replaced or deleted files for short-term recovery
TrueNAS dataset	Scheduled ZFS snapshots	Gives you point-in-time rollback outside Syncthing’s live state
Second system or offline target	Replication or backup	Protects against pool loss, theft, and a compromised NAS

This is intentionally not a two-way collaborative setup. If users must edit the same files through an SMB share on TrueNAS, use Send & Receive and accept that conflict handling becomes part of operations. For storage design underneath the dataset, start with our 4-bay ZFS pool guide and NAS drive buying guide.

Syncthing’s own FAQ says it is not an ideal backup application because modifications and deletions propagate to peers. A recent r/Syncthing discussion reaches the same practical split: versioning makes a synchronized NAS copy more recoverable, but it does not replace snapshots or a separate backup system.

Versions, price, and what we actually tested

Checked on August 1, 2026:

• TrueNAS lists the Stable Syncthing app at 2.1.2, last updated July 8, 2026, and requiring TrueNAS 24.10.2.2 or newer.
• Syncthing 2.1.2 is open-source software with no subscription price. TrueNAS Community Edition and this app do not add a per-terabyte cloud-storage charge; your real costs are hardware, power, networking, and the second copy you still need.
• Our test environment was Windows 11 10.0.26200, Syncthing 2.1.2, and two isolated nodes connected directly over TCP on 127.0.0.1.

We did not run TrueNAS hardware locally. The app-installation and ACL steps below follow the current TrueNAS catalog and host-path documentation. Our firsthand result covers Syncthing’s large-folder behavior, change propagation, deletion propagation, and destination versioning.

Reproducible TopInsight test

We created a fixed workload:

• 2,000 deterministic 4 KiB files
• one 256 MiB file
• 2,001 files and 276,627,456 bytes total
• source folder set to Send Only
• destination folder set to Receive Only with Simple File Versioning, keep 5
• global discovery, relays, and NAT disabled so both nodes used direct loopback TCP

The results:

Check	Result
Initial sync	15.823 seconds on loopback
Initial integrity	PASS; per-file SHA-256 manifests matched
Rewrite 1 MiB at the 128 MiB offset of the large file	PASS; both copies ended at SHA-256 f4378065…09d426e4d
Delete one 4 KiB source file	PASS; deletion propagated
Destination versioning after deletion	PASS; one deleted copy retained in .stversions
Final integrity	PASS; active-file manifests matched

Do not use 15.823 seconds as a TrueNAS speed claim. A loopback test removes real NIC, switch, pool, recordsize, disk, and CPU constraints. It shows that the selected folder modes and versioning behaved correctly under a mixed large-file/small-file workload. On a NAS, Syncthing must hash files with SHA-256, encrypt transport, maintain its index, and write to ZFS; the official FAQ notes that the CPU can become the bottleneck on lower-powered NAS hardware.

To reproduce the test, use Syncthing 2.1.2 and create the same file set, then:

1. Configure two devices with static direct TCP addresses.
2. Share one folder as Send Only on the source and Receive Only on the destination.
3. Enable Simple File Versioning with five versions on the destination.
4. Wait until both nodes report 2,001 global files and 276,627,456 global bytes.
5. Compare sorted per-file SHA-256 manifests.
6. Rewrite 1 MiB in the large file, rescan, and compare its hash.
7. Delete one source file, rescan, verify destination removal, then verify a matching file in .stversions.

Install the TrueNAS app without mixing up paths

In TrueNAS, open Apps → Discover Apps, select Syncthing (Stable), and review the version plus Run As Context before installing. The catalog can change how an app runs, so use the identity shown for your installed chart rather than copying an old UID from a forum post.

Create a dedicated dataset first, for example:

Host dataset: /mnt/tank/syncthing
TrueNAS app mount path: /data
Syncthing folder path: /data/family

These three paths are not interchangeable:

• Host Path is the real TrueNAS dataset path.
• Mount Path is where that dataset appears inside the container.
• Folder Path in Syncthing must be the mount path, optionally with a child directory.

The current TrueNAS app form describes Mount Path as “the path inside the container.” A recurring r/truenas failure is entering /mnt/tank/… again in the Syncthing GUI; the app then tries to create a path that does not exist inside its container and returns permission denied or folder-path-missing errors.

For configuration storage, the default ixVolume is acceptable. For the data you care about, use Additional Storage → Host Path, point it at the dedicated dataset, and give it a short container mount such as /data. This keeps the Syncthing database/config separate from the files you may also expose through SMB.

Set ACLs before you add the folder

TrueNAS host paths require an ACL entry for the app’s current run-as identity. In the app storage form:

1. Enable ACL for the host path.
2. Use the user or group ID shown in the app’s Run As Context.
3. Grant the least access the folder mode needs: read/traverse for a source-only path, or modify/traverse for a receiving path.
4. Apply inheritance to the dedicated dataset before copying data into it.

Do not solve this with chmod 777. A 2025 r/truenas thread shows why that advice is incomplete: Syncthing-created files can still interact badly with SMB ownership and ACL expectations. If the same dataset is an SMB share, use a shared group and inherited ACL entries for both the Syncthing app identity and SMB users.

Syncthing’s Ignore Permissions option can prevent it from trying to synchronize permission bits, which helped some mixed Windows/SMB users. It does not grant TrueNAS filesystem access and it does not repair an incorrect dataset ACL. Treat it as a cross-platform metadata choice after the app can already read and write the mount.

Pair devices and choose folder modes deliberately

Install Syncthing on the workstation, copy its Device ID, and add it as a Remote Device on TrueNAS. Then add the TrueNAS Device ID on the workstation. Both sides must approve the relationship; a leaked Device ID alone is not enough to join a folder.

For a one-way NAS mirror:

• Workstation: Send Only
• TrueNAS: Receive Only
• TrueNAS versioning: Staggered or Simple

Send Only does not silently discard remote divergence: it marks the folder out of sync and exposes Override Changes. That button is destructive because it enforces the source state, including deletions. Receive Only likewise preserves unexpected local changes until you explicitly revert them. These states are safeguards, not a substitute for monitoring.

Use Send & Receive only when both devices are legitimate editing locations. If one side is a mobile device that should upload photos but never receive deletions back, define that as a separate folder with its own policy rather than overloading the archive folder.

Versioning and ZFS snapshots are separate controls

Enable versioning on the TrueNAS destination, not only on the workstation. Syncthing archives a file when a remote change replaces or deletes it; the default version directory is .stversions inside the synchronized folder. If you choose a custom version path, Syncthing recommends keeping it on the same filesystem so the move does not fail across filesystems.

Then create a TrueNAS periodic snapshot task for the dataset. A practical starting policy for active documents is:

• hourly snapshots for 24 hours
• daily snapshots for 30 days
• monthly snapshots for 12 months

Adjust retention to dataset churn and available space. Versioning helps recover individual remote changes; ZFS snapshots give a coherent dataset-level point in time. Neither protects you if the only pool is lost, so replicate snapshots or back up to another machine or offline disk.

Seed multi-terabyte datasets before the first scan

For several terabytes, copying every byte through Syncthing may be unnecessary. Syncthing documents a supported pre-seeding workflow:

1. Stop writes to the source during the seed.
2. Copy the data to the TrueNAS dataset with SMB, rsync, or a physically attached disk.
3. Add the Syncthing folder on both devices with the same Folder ID.
4. Wait for both initial scans to complete before resuming writes.
5. Confirm the destination says Up to Date and spot-check hashes.

Syncthing will hash the pre-seeded data and transfer only differences. The scan can still take significant time because every file enters the index. Large counts of tiny files often cost more CPU and metadata I/O than a few large media files of the same total size.

Avoid nested Syncthing folders and never remove .stfolder as housekeeping. Syncthing uses that marker to distinguish an unavailable mount from a genuine deletion event.

Network and security settings

Keep the Web UI on a trusted LAN or VPN. Syncthing’s own documentation warns that binding the GUI to 0.0.0.0 makes it reachable beyond localhost; if you do that, set a strong GUI password, enable HTTPS, and enforce source access with a firewall.

For remote sites, prefer a private path such as Tailscale instead of forwarding the Web UI to the internet. Our Tailscale vs Cloudflare Tunnel homelab guide explains why Tailscale is the more natural fit for direct device-to-device sync.

When transfer is unexpectedly slow, first check Syncthing’s connection type. A relay protects data in transit but is commonly slower than a direct TCP or QUIC connection. Then check CPU use during hashing, disk write latency, and small-file count before changing ZFS settings.

A minimal .stignore

Place .stignore at the synchronized folder root. Patterns are relative to that root and the file itself is not synchronized.

// OS metadata that should not block directory deletion
(?d).DS_Store
(?d)Thumbs.db

// Temporary partial downloads
*.part
*.tmp

Do not copy a broad ignore list without checking your applications. Ignoring database sidecars, project lockfiles, or photo metadata can create a destination that looks complete but cannot be restored correctly.

Operational checklist

Before calling the setup finished:

• Both devices show Up to Date and a direct connection where expected.
• TrueNAS can create, modify, and delete a test file through the container mount.
• SMB users can edit a Syncthing-created test file if the dataset is shared.
• A source deletion appears in TrueNAS .stversions.
• A ZFS snapshot contains the pre-deletion file and has been restored once.
• The Syncthing config directory is backed up with the device keys.
• A second backup exists outside the TrueNAS pool.

For the underlying platform choice, see TrueNAS Scale vs Core. The short version is that this workflow targets the current Apps-based TrueNAS path; the broader OS decision still depends on whether you need Linux apps and container support.

Bottom line

TrueNAS plus Syncthing is a strong replacement for the transfer and live-copy part of a public-cloud workflow. The reliable configuration is asymmetric folder modes, a dedicated host-path dataset, correct container mount paths, explicit ACLs, destination versioning, and ZFS snapshots. Our Syncthing 2.1.2 test verified that mixed file sizes, an in-place large-file change, deletion propagation, and version retention behave as expected.

The dangerous configuration is the easy-looking one: two-way sync everywhere, no versioning, no snapshots, and a mount path copied from the TrueNAS host into the container GUI. Fix those four choices before moving terabytes.