CLOUD BACKUP & PHOTO LIBRARIES
A Syncthing container can look healthy while its files live in the wrong place. Start with persistent configuration and explicit data mounts so a container replacement does not create a new device identity or lose the folder mapping.
Quick answer
Use the project’s current Docker example, persist its configuration and mount each intended host data directory. Pair a second device by its device ID, then share a small test folder before introducing an existing library.
Steps to follow
-
Before you start
Keep the original data available while following this procedure. Record the application version, account, source path and destination you are actually using. If an error is involved, save its exact wording. Use a small, non-sensitive sample first so that an unexpected result is easy to inspect without disturbing your working library.
-
Set up the right scope
Read the official image example for the installed release. Map configuration and data to separate persistent host locations, record container paths and give the container user only the required read/write permissions. Keep the management interface reachable only by trusted users.
-
Apply the relevant settings
Open the web interface, set its access protection and pair the second device by checking its full device ID. Add a test folder using the container path, accept its share on the other device and choose the destination explicitly.
-
Complete the first run
Create and edit a sample file at each end, wait for both devices to report completion and compare its contents. Restart the container and verify that the same device identity and folder survive before adding more data.
Decisions and checks
The limitation that matters
Docker bridge networking can affect local discovery. A reachable sync address or another documented discovery route may be needed; publishing the management interface to the internet is not a discovery fix. Synchronised deletions still reach peers unless a separate recovery system protects them.
How to verify the result
Test a remote edit and a restart, then recover a deliberately changed sample through versioning or an independent backup. A green status proves agreement between devices, not protection from a mistaken deletion.
Keep the result reliable
After the first successful check, repeat the process with an ordinary working session or scheduled run. Record the date and the recovery location. Revisit the setup after changing devices, accounts, storage paths or software versions; yesterday’s successful job does not prove that a new configuration is covered.
Compare the options
| Situation / component | Purpose / action | What to check |
|---|---|---|
| Input | Preserve an unchanged sample | Know which account and location contain the original |
| Operation | Follow the procedure for your installed version | Review errors and skipped items, not only the completion message |
| Result | Open the resulting file or test the documented recovery route | Confirm that the content, version and access rights are correct |
Frequently asked questions
Can I remove the original immediately?
Keep it until you have verified the intended result and have an independent recovery copy where the data matters. A visible file name, a green icon or a completed task alone does not show that every needed item is recoverable.
What information helps if this fails?
Record the version, exact error, affected file type, available space and whether the same small sample works elsewhere. Share sanitized details through the official support route; passwords, recovery keys and private documents are not needed for an initial diagnosis.
Official documentation
This guide combines current official documentation with practical recovery checks. It does not claim hands-on testing of your installation. Menu labels and supported procedures can vary by release; follow the documentation for your installed version.