Syncthing ‘The Device Is Not Ready’: Drive and Mount Checks

What to check for The device is not ready

The message alone does not establish a failed disk or an offline remote Syncthing device. First check whether the configured folder path points to the actual data volume. If a drive or mount is unavailable, restore the correct storage and verify the expected files before resuming. Creating a marker in an empty path can let deletions propagate.

For a folder with a custom Marker Name, check the configured marker instead of the default .stfolder. The marker commands below use the default name; substitute the recorded name when customized. The recovery conditions for correct storage with only the marker missing are covered separately below.

Before recovery: pause the affected folder in the Syncthing UI and back up its settings and data. Keep it paused while restoring the mount or marker so automatic sync does not resume before you compare the actual volume and expected data.

Verify the storage before recreating the marker

Syncthing stops a folder when its default root .stfolder marker disappears. The official FAQ explains that this protects against treating an empty mount point as the real folder and propagating deletions after storage is unmounted. Recreating the marker inside an empty directory only removes that protection.

On Windows, The device is not ready can appear when a drive is unavailable or the path no longer points to the intended volume. On Linux and NAS systems, a failed mount can leave an empty mount point with a similar symptom. In every environment, verify expected data and storage identity before resuming.

Require three matches before resuming

Condition	Evidence	Action on mismatch
Storage identity	Drive label, volume, filesystem, and mount source	Mount the correct device first.
Folder contents	Expected files and directories exist	Do not resume from an empty mount point.
Folder marker	The exact root contains .stfolder	Consider marker repair only after storage matches.

Inspect a Windows drive

$folder = 'E:\Sync'
Get-Volume
Test-Path $folder
Get-ChildItem $folder -Force | Select-Object -First 20 Name,Length,LastWriteTime
Get-Item (Join-Path $folder '.stfolder') -Force -ErrorAction SilentlyContinue

A removable drive can receive another drive letter after reconnection. Compare its label and filesystem with the previous record and confirm that E:\Sync contains the real data volume. If the directory is unexpectedly empty, do not create a marker; inspect Disk Management and the storage connection first.

Inspect a Linux or NAS mount

findmnt -T /volume1/sync
df -T /volume1/sync
ls -la /volume1/sync | head -n 20
stat /volume1/sync/.stfolder

If findmnt shows only a parent filesystem or an unexpected source, do not resume the service. For a Syncthing package or container on a NAS, inspect both the host mount and container bind mount. A path visible in the container can still be an incorrect empty host directory.

A tested preflight: reject an empty path even when a marker exists

On 2026-10-22, we ran the following Python 3 code against temporary directories on Ubuntu 24.04. No Syncthing instance or real sync folder was touched. Save it as path-preflight.py and supply the root, actual Marker Name, and the relative path of a file known to exist on the correct volume. It reads at most one byte and prints presence checks; it creates or changes no files, settings, or markers.

from pathlib import Path
import json
import sys

root = Path(sys.argv[1])
marker = sys.argv[2]        # Actual Marker Name from folder settings
known_file = sys.argv[3]    # A file known to exist on the correct volume
checks = {
    "root_directory": root.is_dir(),
    "configured_marker": (root / marker).exists(),
    "known_file_readable": False,
}
try:
    with (root / known_file).open("rb") as stream:
        stream.read(1)
    checks["known_file_readable"] = True
except OSError:
    pass
print(json.dumps(checks, sort_keys=True))
sys.exit(0 if all(checks.values()) else 2)

python3 path-preflight.py /path/to/sync .stfolder known-file.txt

Temporary directory condition	Observed result	Exit code
Correct root + default marker + known file	All true	0
Empty path + no marker	Marker and known file false	2
Empty path + marker only	Known file false	2
Correct root + custom marker + known file	All true	0

Exit code 0 does not authorize resuming sync or prove volume identity. A mistakenly copied directory can contain the same file. Separately compare Linux findmnt or Windows volume information with the previous record, and run the reads as the actual Syncthing service user when possible. Check the production folder before creating any marker.

The third result demonstrates what a marker-only check misses. This experiment tested the path-checking code only. It did not reproduce a Windows device error, a real mount failure, Syncthing deletion propagation, or successful sync recovery. One known file cannot establish that all data is complete.

Select recovery from the observed state

• The storage is unmounted: mount the original device at the expected path and verify its data. The existing marker usually returns with the storage.
• The folder moved: move it back or reconfigure the folder at the new path. Do not edit a live config.xml without following the configuration procedure.
• The data is correct and only the marker is absent: determine whether a cleaner removed the empty marker directory. Restore it only after confirming the complete folder contents.
• The path is empty and the original storage is unavailable: do not resume. Pause changes on remote devices and prioritize backup and storage recovery.
• Permissions hide the marker: identify the actual Syncthing service account and mount permissions. Avoid a blanket recursive chown across shared data.

Understand remove and re-add

The Syncthing FAQ describes removing and re-adding a folder at the same path when its state is uncertain. This recreates marker and database state, but it also makes the folder appear new and merges its contents with remote devices. Review conflict direction before using it as a repair.

Record folder ID, type, shared devices, versioning, ignore patterns, and path before removal. Recreating a send-only or receive-only folder as the default send-receive type changes the data policy during recovery.

Verification and rollback

After confirming storage and marker, resume the folder and inspect local additions and deletions from the first scan. If an unexpected bulk deletion appears, pause immediately and recheck the path. Compare every device sharing the folder rather than treating one remote device as proof of completion.

If the folder was re-added at the wrong path, stop synchronization, remove the incorrect entry, and restore the recorded settings. Check versioning storage and backups first; do not assume a rescan reverses deletions already propagated to peers.

Related guides

• WordPress and NAS troubleshooting
• Server and Linux troubleshooting
• All troubleshooting topics

Official references

• Syncthing FAQ – missing folder marker, unmounted storage, and re-add consequences
• Syncthing GUI guide – folder paths and missing-marker state
• Syncthing configuration – folder paths, configuration locations, and folder settings
• Syncthing database status endpoint – official API for scan and local state

Earlier verification notes preserved from this article

Verification level: official documentation checked

Syncthing’s missing-marker protection and re-add consequences were checked against official documentation. No specific storage failure was reproduced, so the guide does not infer a drive or filesystem root cause.

Writing and correction policy · Report an error