Syncthing / Troubleshooting
Syncthing Reports “Folder Marker Missing”
Treat .stfolder as a safety guard: prove the configured path, expected filesystem, and expected local data are present before recreating the marker or considering a folder reset in Syncthing 2.1.3.
Syncthing uses .stfolder as a safety check that the configured folder is actually present and readable. The official FAQ specifically warns that a missing marker can indicate an unmounted filesystem, a moved folder, or software that removed the marker.[1][2]
Recreating the marker before proving the expected filesystem is mounted can be dangerous: an unintended empty mount point can make local files appear missing and those changes may propagate as deletions. The storage state must be proven before any marker restoration.[1][2]
Applicability
- Products
- Syncthing
- Scope
- For Syncthing v2.1.3 when an existing configured folder stops with the exact “folder marker missing” condition. The page is scoped to the missing .stfolder safety marker and the storage/path conditions that can make it disappear; database corruption, relay connectivity, conflict resolution, and general sync performance are separate diagnoses.[1][2][4]
- Last verified
Symptoms
Quick diagnosis
Prove the expected filesystem and data are present before recreating .stfolder or resetting folder state.
Record the configured folder path and current Syncthing state
Capture the folder ID, configured path, current error, and any mount/device expectations before touching .stfolder or removing the folder from Syncthing.[1][2]
Prove the expected filesystem is actually mounted
Check the filesystem/mount identity and confirm it is the storage normally used by this Syncthing folder. A path existing as an empty directory is not proof that the expected disk or share is mounted.[1]
Confirm the expected local data is present before marker work
Inspect the folder contents and verify they match the expected local dataset. If the directory is unexpectedly empty or different, stop before recreating .stfolder.[1][2]
Interactive troubleshooter
Your answers stay in this browser tab. The tool does not connect to your systems or send diagnostic results.
Guided check / step 1
Safe diagnostic guidanceDoes Syncthing report “folder marker missing” for this configured folder?
Use the exact marker error as the scope gate.[1]
Read the complete diagnostic tree without using the controls
- Does Syncthing report “folder marker missing” for this configured folder?
Use the exact marker error as the scope gate.[1]
- Yes — folder marker missing → Does the configured folder path exist?
- No — different Syncthing error → Different Syncthing diagnosis
- Does the configured folder path exist?
A missing path must be corrected before marker restoration.[1]
- Yes — path exists → Is the expected filesystem or mount actually present at that path?
- No — configured path is missing → The configured folder path is missing or moved
- Is the expected filesystem or mount actually present at that path?
Path existence alone is not proof that the intended storage is mounted.[1][2]
- Yes — expected storage is mounted → Does the folder contain the expected local data?
- No — expected storage is not mounted → The expected filesystem is not mounted
- Does the folder contain the expected local data?
Unexpectedly empty or different data is a stop condition before recreating the marker.[1][2]
- Yes — expected data is present → Is .stfolder actually absent on the proven correct storage?
- No — data is missing or unexpected → The path does not contain the expected local dataset
- Is .stfolder actually absent on the proven correct storage?
Only this branch permits safe marker restoration.[2]
- Yes — marker is absent → The correct storage and data are present; only .stfolder is missing
- No — marker is present → The marker is present, so another condition is blocking the folder
- Different Syncthing diagnosis
Use the error-specific path for database, permissions, relay, or general synchronization failures.[1]
- The configured folder path is missing or moved
Find the intended dataset and correct the path before creating any marker.[1]
- The expected filesystem is not mounted
Restore the intended storage first and leave .stfolder untouched in the empty mount point.[1][2]
- The path does not contain the expected local dataset
Stop synchronization changes and resolve the storage/data discrepancy before marker restoration.[1][2]
- The correct storage and data are present; only .stfolder is missing
This is the safe branch for documented marker restoration followed by a carefully observed rescan.[1][2]
- The marker is present, so another condition is blocking the folder
Preserve the current folder state and capture the exact Syncthing error before another change.[1]
Detailed diagnosis
1. Verify the exact folder-marker error
Confirm Syncthing is reporting the missing folder marker for this folder rather than a path, permissions, database, or connectivity error with different remediation.[1]
2. Check whether the configured folder path exists
If the configured path is gone, do not create .stfolder in a replacement directory. Determine why the path moved or disappeared first.[1]
3. Verify the expected filesystem or mount identity
For removable, network, or separately mounted storage, prove that the expected filesystem is mounted at the configured path. An unmounted filesystem is one of the official causes of the marker error.[1]
4. Verify the expected data is present
Before marker restoration, confirm the local files that should exist are present. Unexpectedly empty storage is a stop condition because Syncthing can interpret missing local files as deletions once synchronization resumes.[1][2]
5. Check .stfolder only after storage identity is proven
If the correct filesystem and expected data are present, inspect whether the .stfolder marker itself is absent. Cleaning software or manual changes can remove it; do not use recursive chmod/chown as a default fix.[1][2]
Supported scenarios
These observations narrow the next investigation; they do not establish a unique cause.
The expected filesystem is not mounted
Syncthing documents an unmounted filesystem as a reason the marker can disappear from the configured path, protecting against synchronization into the wrong local directory.[1][2]
How to check: Verify the mount/device identity rather than trusting that the path itself exists.[1]
The configured folder moved or the path changed
If the folder was moved, the configured path no longer contains the expected marker and data. Creating a new marker at the old path would validate the wrong location.[1]
How to check: Compare the configured Syncthing path with the actual location of the expected dataset.[1]
The correct storage is present but .stfolder was removed
The Syncthing FAQ identifies cleaning software or other external removal as a supported reason for the marker to disappear even when the folder data remains intact.[1][2]
How to check: Only after the filesystem and expected data are proven, verify that .stfolder alone is missing.[2]
Next actions and procedure boundaries
Restore the expected filesystem before touching the marker
If the expected disk or share is not mounted, keep Syncthing stopped on this folder and restore the intended storage path first. Do not create .stfolder in the empty mount point.[1][2]
Recreate .stfolder only after the correct filesystem and data are proven
When the intended storage is mounted, the configured path is correct, and the expected local data is present, restore the missing .stfolder marker according to the documented marker semantics, then watch the first rescan carefully.[1][2]
Use remove/re-add only as a last-resort state reset with a recovery plan
The official FAQ describes removing and re-adding the folder as a way to recreate the marker and reset database state. Treat this as a potentially disruptive recovery action: preserve the folder configuration and local data, ensure the expected filesystem is mounted, and understand that the re-added folder is reconciled as new state rather than promising that no files can be overwritten or deleted.[1][2]
Before changing anything
- Risk
- Removing and re-adding the folder resets its local database state and can cause remote and local differences to be reconciled in ways that propagate deletions or replacements.[1][2]
- Safer check
- Verify the intended filesystem and expected data, record the folder ID/path/type and sharing configuration, and preserve a backup where there is any uncertainty about current state.[1][2]
- Expected result
- The folder is re-added with the intended configuration, the safety marker is recreated, and synchronization resumes only after the operator has reviewed the resulting state.[1][2]
- Backup / recovery access
- Preserve the local dataset and record the existing folder configuration before removing the folder from Syncthing.[1]
- Rollback
- If reconciliation is unexpected, stop synchronization and restore from the preserved data/configuration rather than forcing an override.[1][2]
Warnings and boundaries
Sources
Links were reviewed on 2026-09-08. Reachability and automated validation do not replace editorial verification of each claim.
- Syncthing FAQ
Syncthing project · Tier A · accessed 2026-09-08 - Syncthing folder marker documentation
Syncthing project · Tier A · accessed 2026-09-08 - Syncthing releases
Syncthing project · Tier B · accessed 2026-09-08 - Syncthing Versions and Releases
Syncthing project · Tier A · accessed 2026-09-08