Prepare the marker for a read-only TrueNAS migration source

Bottom line: Prepare the remote marker before starting the read-only ingest. Keep the source’s read-only boundary intact and resolve marker creation through the documented source-owner or existing-marker branch.

Source fact: what the authority says

The TrueNAS 25.10 third-party migration guide scopes ingest to Enterprise customers with TrueNAS 24.04 or newer and the appropriate application license. The guide requires one-way migration with remote shares mounted read-only and excludes read-write or bidirectional synchronization. Syncthing needs a source marker to confirm the mounted volume, but the read-only SMB mount prevents creating its default .stfolder there. Its alternatives are a source-authorized client creating .stfolder at the share root, or the ingest instance’s Marker Name pointing to an existing source file or folder.

What the source does not establish

This article covers the marker prerequisite in the licensed migration workflow. It does not approve a general-purpose two-way sync, prove metadata completeness or replace the guide’s identity, SMB and destination-permission prerequisites.

Applicability questions

• Does this deployment meet the licensed Enterprise migration workflow’s prerequisites?
• Which remote share root is actually mounted by the ingest instance?
• Who may create a source marker through an authorized client?
• If an existing marker is chosen, what exact file or folder will be referenced?

DSE recommendation: controlled next steps

The following steps are DSE recommendations based on the cited source.

DSE recommends resolving the marker plan before starting an ingest trial. Record the remote share, mounted root and ingest instance together. Confirm the licensing, SMB, identity and destination-permission prerequisites through the complete guide rather than treating the marker fix as approval for an otherwise unreviewed migration design.

Choose one documented marker branch with the source owner. For a newly created marker, use an expressly authorized source client and record the intended share-root location. For an existing object, agree the exact reference and its owner. Avoid granting the ingest mount write access merely to bypass the prerequisite.

Use a small disposable remote share for the initial exercise. Include harmless representative data and identify the marker separately from the data intended for migration. Keep the read-only one-way requirement explicit, and do not extend this procedure to bidirectional synchronization or general-purpose shared-folder administration.

Review the ingest instance’s actual mount and marker setting together before the trial. Preserve the source’s original configuration and agree who controls cleanup of any temporary marker. Keep the broader migration acceptance plan, including identity and metadata checks, independent of a successful marker observation.

Verification and evidence

Proposed verification: inspect the remote mount and selected marker reference, then observe the ingest instance’s actual synchronization status in the disposable exercise. Compare a missing-marker case with the approved configured-marker case without modifying important source data. Record the actual messages and the precise selected path for each observation.

Confirm that the trial still follows the approved read-only one-way design. Have the source owner account for any temporary marker and retain redacted mount and setting evidence. Treat successful synchronization startup as one prerequisite result, not proof that all files, permissions or migration objectives have been accepted.

Official references

• TrueNAS — Third-Party Data Migration — official product documentation; confirm the installed release and configuration.

Source review completed October 30, 2026. Recheck the official documentation and deployment-specific applicability before a production change.