Syncthing on KnightLiブログ

Syncthing で複数デバイスと複数フォルダーを管理する方法：トポロジー、命名、バージョン管理

Sun, 31 May 2026 12:23:55 +0800

Syncthing シリーズ目次

Syncthing はデバイスとフォルダーが増えると、事前に設計しておかない限りすぐに複雑になります。典型的には、スマートフォン、タブレット、ノート PC、デスクトップ、NAS が同時に同期し、フォルダーには写真、仕事用ドキュメント、コード、チャットのバックアップ、電子書籍が混在します。どのデバイスでも変更でき、どのフォルダーも共有されるため、最終的に「このファイルはどこから来て、どこへ同期されるのか」が分かりにくくなります。

Syncthing を安定して使うために重要なのは、クライアントを増やすことではなく、管理ルールを作ることです。

トポロジーはスター型にする。
フォルダー ID とパスを統一する。
デバイス関係には Introducer を使う。
データ方向でバックアップと双方向同期を分ける。
中心ノードでバージョン管理を有効にする。
一時ファイルは Ignore Patterns で除外する。

トポロジー：フルメッシュを避け、スター型を優先する

Syncthing は P2P の対等な構成ですが、すべてのデバイスを相互にペアリングすべきという意味ではありません。

5 台のデバイスをすべて相互接続すると、10 組のデバイス関係を管理する必要があります。新しいフォルダーを追加するたびに、複数のデバイスで受け入れ、パスを設定し、共有を確認しなければなりません。デバイスが増えるほど管理コストは高くなります。

よりおすすめなのはスター型トポロジーです。

常時稼働し、容量が大きく、ネットワークが安定しているデバイスを中心ノードにします。

NAS
Synology
ソフトルーター
ミニ PC
24 時間稼働するパソコン

他のデバイスは中心ノードだけとペアリングします。

Phone ----\
Tablet ----\
Laptop ---- NAS
Desktop ---/

スマートフォンはノート PC を直接追加せず、ノート PC もデスクトップを直接追加しません。スマートフォンの写真をパソコンへ同期したい場合は、まず NAS に同期し、NAS からパソコンへ同期します。

この方法には次の利点があります。

新しいデバイスは NAS とだけペアリングすればよい。
フォルダー関係を NAS で集中管理できる。
NAS でバージョン保持を統一できる。
端末がオフラインでも NAS がバッファーになる。

欠点は NAS の重要性が高くなることです。安定稼働させ、NAS 自体のバックアップも用意する必要があります。

Folder ID はフォルダーラベルより重要

Syncthing で同期フォルダーを本当に識別するのは Folder ID であり、画面に表示されるラベルではありません。

ラベルは表示名にすぎず、デバイスごとに違っていても構いません。Folder ID こそが、複数デバイス上のフォルダーが同じ同期グループに属するかを判断する鍵です。

そのため、最初のデバイスでフォルダーを作るときは、分かりやすい ID を手動で指定することをおすすめします。

例：

notes-main
work-docs
backup-pixel-photos
backup-iphone-photos
media-ebooks
code-projects

自動生成されたランダムな ID や、test、sync、new-folder のように長期運用に向かない名前は避けましょう。

命名ルールはシンプルで十分です。

双方向同期：notes-main、work-docs
スマートフォンのバックアップ：backup-pixel-photos、backup-iphone-photos
資料配布：media-ebooks、media-music
コードディレクトリ：code-projects

後で別のデバイスが共有を受け取るとき、Folder ID を見れば用途をすぐ判断できます。

中心ノードのパスを整理する

NAS や中心となるパソコンでは、Syncthing 用の共通ルートディレクトリを作るのがおすすめです。

例：

/volume1/Syncthing/
├── Phone_Backup/
│   ├── iPhone15_DCIM/
│   └── Pixel7_DCIM/
├── Work/
│   ├── Office_Docs/
│   └── Coding_Projects/
├── Notes/
│   └── Main_Notes/
└── Media/
    └── eBooks/

同期ディレクトリをシステム内のあちこちに散らさないでください。短期的には便利でも、長期的には必ず管理が難しくなります。

おすすめの原則：

Syncthing が管理するすべてのディレクトリを共通ルートの下に置く。
スマートフォンのバックアップ、仕事用ドキュメント、メディアを分ける。
フォルダー名は一時的なデバイス状態ではなく用途を表す。
システムディレクトリやダウンロードキャッシュを長期同期フォルダーにしない。

Syncthing を Docker で動かしている場合は、ホスト側パスとコンテナ内パスの対応にも注意します。

ホスト側のディレクトリ：

`1`	`/volume1/Syncthing/Phone_Backup/iPhone15_DCIM`

コンテナ内では次のようにマウントされることがあります。

`1`	`/var/syncthing/Phone_Backup/iPhone15_DCIM`

Web UI に入力するのはコンテナ内パスであり、ホスト側パスではありません。

Introducer：複数デバイスのペアリング作業を減らす

Syncthing の Introducer は、スター型トポロジーに向いた機能です。

NAS を Introducer に設定します。その後、新しいデバイスは NAS とペアリングするだけで、NAS が既知のデバイスや共有関係を新しいデバイスに紹介できます。これにより、各デバイス間で QR コードを何度も読み取ったり、手動で追加したりする作業を減らせます。

向いているケース：

家に複数のパソコンやスマートフォンがある。
NAS が常時稼働する中心ノードである。
新しいデバイスをよく追加する。
ペアリング操作を減らしたい。

ただし、乱用しないでください。

バックアップと双方向同期を分ける

複数フォルダー管理で最も重要なのは、すべてのディレクトリに Send & Receive を使わないことです。

フォルダーごとにデータの向きは異なります。

スマートフォン写真バックアップ

スマートフォン側：

`1`	`Send Only`

NAS 側：

`1`	`Receive Only`

スマートフォンは写真を送信し、NAS は受信して保存します。スマートフォンの容量整理や NAS 側の整理が、互いに影響しにくくなります。

複数端末のドキュメントとメモ

パソコン側：

`1`	`Send & Receive`

NAS 側：

`1`	`Send & Receive`

スマートフォンを双方向同期に参加させるかは、実際にスマートフォンでそれらのファイルを編集するかによります。閲覧だけなら Receive Only も検討できます。

資料配布

NAS 側：

`1`	`Send Only`

他のデバイス：

`1`	`Receive Only`

電子書籍、インストーラー、参考資料など、中心から配布するフォルダーに適しています。

バックアップディレクトリ

メインデバイス：

`1`	`Send Only`

バックアップ機：

`1`	`Receive Only`

さらにバックアップ側でバージョン管理やスナップショットを組み合わせます。

NAS でファイルバージョン管理を有効にする

複数デバイス同期で最も怖いのは、誤削除と誤上書きです。

例：

あるパソコンで仕事用ドキュメントを誤って削除した。
スマートフォンのクリーンアップツールがアルバムディレクトリを削除した。
2 台のデバイスが同じメモを同時に編集した。
同期ルールを間違えて空ディレクトリを同期してしまった。

そのため、中心ノードではファイルバージョン管理を有効にしておくのが安全です。

NAS の Syncthing Web UI で：

対象フォルダーの設定を開く。
ファイルバージョン管理へ進む。
適切なバージョン戦略を選ぶ。

よく使われるのは Staggered File Versioning です。時間間隔に応じて履歴バージョンを保持し、古いものほど間引いて残します。

より単純な戦略も使えます。

Trash Can File Versioning：ごみ箱のように扱う。
Simple File Versioning：固定数のバージョンを保持する。
Staggered File Versioning：時間段階に応じて保持する。

迷う場合、家庭用 NAS なら Trash Can または Staggered から始めるとよいでしょう。

バージョン管理は完全なバックアップではありませんが、複数デバイス同期における重要な復旧手段です。

Ignore Patterns で一時ファイルを除外する

コードプロジェクト、ドキュメントディレクトリ、チャットバックアップを複数デバイスで同期すると、一時ファイルやキャッシュが問題を起こしやすくなります。

よくある問題：

帯域を大量に使う。
意味のない競合が発生する。
OS ごとに異なるキャッシュファイルが生成される。
ディレクトリ削除時に無視ファイルが残って邪魔をする。

フォルダー設定の Ignore Patterns にルールを追加できます。

汎用の一時ファイル：

1
2
3

(?d).DS_Store
(?d)Thumbs.db
(?d)*~

Node / Python / Java プロジェクト：

(?d)node_modules/
(?d)__pycache__/
(?d).pytest_cache/
(?d)target/

コードプロジェクト自体を Git で管理している場合、通常は Syncthing で .git ディレクトリを同期することはおすすめしません。次のように無視できます。

`1`	`(?d).git/`

(?d) は、ディレクトリ全体を削除するときに、Syncthing がこれらのローカル生成された無視ファイルも削除できることを意味します。残ったキャッシュがディレクトリ削除を妨げにくくなります。

Ignore Patterns は最初から複雑にしすぎないでください。まず明らかなキャッシュと一時ファイルを除外し、実際の競合に合わせて少しずつ調整します。

複数フォルダーの命名例

固定した命名方式を用意できます。

スマートフォン写真：

1
2
3

Folder ID: backup-pixel-photos
Label: Pixel Photos
NAS Path: /volume1/Syncthing/Phone_Backup/Pixel7_DCIM

iPhone 写真：

1
2
3

Folder ID: backup-iphone-photos
Label: iPhone Photos
NAS Path: /volume1/Syncthing/Phone_Backup/iPhone15_DCIM

メインのノート保管庫：

1
2
3

Folder ID: notes-main
Label: Main Notes
NAS Path: /volume1/Syncthing/Notes/Main_Notes

仕事用ドキュメント：

1
2
3

Folder ID: work-docs
Label: Work Docs
NAS Path: /volume1/Syncthing/Work/Office_Docs

電子書籍：

1
2
3

Folder ID: media-ebooks
Label: eBooks
NAS Path: /volume1/Syncthing/Media/eBooks

ID、ラベル、パスに規則があれば、デバイスが増えても管理しやすくなります。

推奨する全体構成

すでに Docker 版 Syncthing を NAS で動かしているなら、次のように設計できます。

NAS を中心ノードにする。
NAS を Introducer に設定する。
すべてのデバイスは NAS とだけペアリングする。
すべての同期ディレクトリを /volume1/Syncthing/ の下に置く。
スマートフォン写真はスマートフォン Send Only、NAS Receive Only にする。
仕事用ドキュメントとメモは Send & Receive にする。
資料配布フォルダーは NAS Send Only、他デバイス Receive Only にする。
NAS 上の重要フォルダーでバージョン管理を有効にする。
コードとキャッシュディレクトリには Ignore Patterns を設定する。
NAS 自体にもスナップショットまたは別場所へのバックアップを用意する。

この構成を作っておけば、新しいデバイスやフォルダーを追加するときも、既存のルールに沿って入れるだけで済みます。同期関係を毎回考え直す必要はありません。

まとめ

Syncthing は自由度が高いツールですが、自由度が高いほどルールが必要です。

複数デバイス、複数フォルダーの環境では、フルメッシュ同期はおすすめしません。より安定するのは、NAS または常時稼働するパソコンを中心ノードにし、Folder ID、パス、バージョン管理を統一し、フォルダー種別でバックアップ、双方向同期、資料配布を分ける方法です。

こうすれば Syncthing の P2P 能力を保ちながら、日常管理を 1 台の中心デバイスに集約できます。デバイスやフォルダーが増えても、同期関係が混乱しにくくなります。

Syncthing で iPhone の写真を PC や NAS に同期する方法

Sun, 31 May 2026 12:21:54 +0800

Syncthing シリーズ目次

iPhone で Syncthing を使って写真を同期する場合、Android とはかなり事情が異なります。

理由は単純です。iOS はより閉じたシステムであり、Syncthing 公式は正式な iOS クライアントを提供していません。iPhone で Syncthing プロトコルを使うには、通常はサードパーティ製の互換クライアントが必要です。

よく使われる選択肢は次の 2 つです。

Mobius Sync：比較的主流で、ネイティブアプリに近い使い勝手です。一部機能は有料解除が必要な場合があるため、現在の App Store の説明を確認してください。
FSync：無料でオープンソースの Syncthing iOS クライアントです。

iPhone の写真ライブラリを PC や NAS に同期する目的なら、Mobius Sync がよく使われます。以下ではこれを例に設定手順を整理します。

まず iOS の制限を理解する

Android では、Syncthing-Fork がバックグラウンドサービス、実行条件、バッテリー最適化の除外などを使って長時間動作できます。しかし iOS は、サードパーティの同期ツールが無制限にバックグラウンド常駐することを許可しません。

つまり、次の点に注意が必要です。

NAS のように 24 時間同期し続けることは期待できません。
App がバックグラウンドに入ると、同期できる時間は短い場合があります。
大量の写真は、手動で App を開いて同期を完了させるのが確実です。
iCloud のストレージ最適化により、元画像の読み取りに影響が出ることがあります。

そのため iPhone 側では、完全に無意識のリアルタイムバックグラウンド同期ではなく、「定期的に App を開いて写真を同期する」運用が向いています。

手順 1：クライアントをインストールして権限を付与する

App Store から Mobius Sync をインストールしたら、初回起動時にいくつかの権限を確認します。

通知権限

通知は許可しておくことをおすすめします。同期状態、接続状態、エラー情報を確認しやすくなります。

ローカルネットワーク権限

この権限は非常に重要です。

iOS は、App がローカルネットワークへアクセスしてよいかを個別に確認します。許可しない場合、iPhone が LAN 内の PC、NAS、Syncthing ノードを検出できないことがあります。

誤って拒否した場合は、iOS の設定から再度有効にできます。

写真ライブラリへのアクセス権限

写真を同期するには、写真ライブラリへのアクセスを許可する必要があります。

推奨される選択は次のとおりです。

`1`	`Full Access to Photos`

限定的な写真アクセスだけを許可すると、Mobius Sync は選択済みの写真しか見られず、後から追加した写真が同期されない可能性があります。

手順 2：iPhone と PC/NAS をペアリングする

Syncthing のペアリングは、デバイス ID を相互に登録する仕組みです。

iPhone 側では：

Mobius Sync を開きます。
Settings に入ります。
Device ID を開きます。
QR コード画面を表示したままにします。

PC または NAS 側では：

Syncthing Web UI を開きます。
Add Remote Device をクリックします。
iPhone 上の QR コードをスキャンするか、デバイス ID を手動入力します。
My-iPhone のような名前を付けます。
保存します。

iPhone に戻り、接続要求の通知を待って Accept をタップします。

ここまでで iPhone と PC/NAS は相互に信頼された状態になりますが、写真ライブラリはまだ共有されていません。

手順 3：iPhone で写真同期用フォルダを作成する

iOS では、Android のように /DCIM/Camera を直接選択する形にはなりません。Mobius Sync はシステム写真ライブラリ向けの専用サポートを持っているため、設定時に写真ライブラリ用のフォルダタイプを選びます。

Mobius Sync で：

Folders に切り替えます。
右上の + をタップします。
新しいフォルダを作成します。

重要な項目：

Folder Type：Camera Roll を選びます。
Folder Label：iPhone_Photos など、識別しやすい名前を入力します。
Folder ID：自動生成のままでもよいですし、安定した英数字 ID を使っても構いません。
Folder Path：デフォルトのままにして、クライアントが iOS の写真ライブラリに関連付けられるようにします。

次に Sharing セクションで、先ほどペアリングした PC または NAS を選択します。

手順 4：iPhone 側を Send Only にする

写真同期は通常、「スマートフォンから NAS へ送る」用途であり、双方向編集ではありません。

そのため iPhone 側のフォルダタイプは次のように設定します。

`1`	`Send Only`

これにより iPhone は写真を送信するだけになり、PC や NAS からの逆方向の変更を受け取りません。

この設定は誤操作のリスクを下げます。たとえば PC 側でバックアップフォルダを整理しているとき、その変更が iPhone の写真ライブラリに影響することを避けられます。

ただし、Syncthing は同期ツールであり、完全なバックアップシステムではありません。長期的に写真を安全に保つには、NAS 側のスナップショット、ファイルバージョン管理、独立したバックアップも必要です。

手順 5：PC または NAS 側で写真を受け取る

iPhone 側で保存すると、PC または NAS の Syncthing Web UI に次のような通知が表示されます。

`1`	`Device My-iPhone wants to share folder iPhone_Photos`

追加をクリックします。

保存先パスを設定します。

Windows なら、たとえば次のようにします。

`1`	`D:\Backups\iPhone_Photos`

Linux または NAS なら、たとえば次のようにします。

`1`	`/volume1/photos/iphone`

Syncthing が Docker 内で動作している場合は、コンテナ内のパスを入力します。たとえばホスト側のマウントが次の場合：

`1`	`- /volume1/photos:/var/syncthing/photos`

Web UI では次のように入力します。

`1`	`/var/syncthing/photos/iphone`

受信側は Receive Only がおすすめ

PC または NAS 側でも、このフォルダタイプは次に設定するのがおすすめです。

`1`	`Receive Only`

これにより受信側は iPhone から送られてくる写真だけを受け取り、ローカル変更を iPhone に同期しません。

これは 2 段目の保険です。

iPhone 側：Send Only
NAS 側：Receive Only

両側を一方向バックアップの考え方で設定することで、写真アーカイブの用途に合いやすくなります。

iOS のバックグラウンド同期の現実的な制限

iOS はバックグラウンド実行に非常に厳しい制限があります。設定が正しくても、Mobius Sync が常にバックグラウンドで黙って動き続けるとは考えないほうがよいです。

よくある動作は次のとおりです。

App を開いている間は通常どおり同期されます。
バックグラウンドに切り替えた後、短時間は同期が続く場合があります。
しばらくすると、システムが一時停止または制限します。
位置情報の変化、システムのスケジューリング、短いバックグラウンド実行枠で再度起動することがあります。

最も確実な運用はシンプルです。

大量の写真を撮った後、Mobius Sync を手動で開きます。
画面を点灯したままにするか、すぐにロックしないようにします。
新しい写真の同期が終わるまで待ちます。
その後 App を閉じるか、画面をロックします。

数日に一度写真バックアップを行う運用なら、この方法は比較的安定しています。

iCloud のストレージ最適化による影響を避ける

iPhone で次の設定が有効になっている場合：

`1`	`Optimize iPhone Storage`

システムはローカルにサムネイルだけを残し、元画像を iCloud に置くことがあります。サードパーティの同期クライアントが写真を読み取るとき、完全な元画像を取得できず、同期失敗、スキップ、またはシステムのダウンロード待ちが発生する可能性があります。

同期バックアップに向いている設定は次です。

`1`	`Download and Keep Originals`

通常の場所は次のとおりです。

`1`	`Settings -> Apple ID -> iCloud -> Photos`

端末容量が足りず、どうしても最適化ストレージを使う必要がある場合は、同期前にシステムの写真 App で対象の写真を開き、iPhone に iCloud から元画像をダウンロードさせてから Mobius Sync を起動するとよいです。

大量写真の初回同期のすすめ

iPhone の写真ライブラリを初めて同期するときは、数千枚から数万枚の写真があるかもしれません。急いで一度に終わらせようとしないほうが安全です。

次のように進めるとよいです。

まず少量の写真でテスト同期します。
NAS のパスが正しいことを確認します。
フォルダタイプが Send Only / Receive Only であることを確認します。
受信側が iPhone に逆方向の影響を与えないことを確認します。
その後、完全な同期を開始します。

初回同期時は、次をおすすめします。

iPhone を電源に接続します。
Wi-Fi を安定させます。
Mobius Sync を前面で実行します。
NAS または PC をオンラインにしておきます。

写真の数が多い場合、同期に時間がかかることがあります。これは正常です。

推奨構成

安定した iPhone 写真同期の構成は次のようになります。

iPhone に Mobius Sync をインストールします。
通知、ローカルネットワーク、写真ライブラリへのフルアクセスを許可します。
iPhone と NAS でデバイス ID を相互登録します。
iPhone 側で Camera Roll フォルダを作成します。
フォルダラベルを iPhone_Photos にします。
iPhone 側のフォルダタイプを Send Only にします。
NAS 側の受信パスを /volume1/photos/iphone にします。
NAS 側のフォルダタイプを Receive Only にします。
NAS 側でファイルバージョン管理またはスナップショットを有効にします。
数日に一度 Mobius Sync を手動で開いて同期を完了させます。

完全自動のバックグラウンド写真バックアップに強く依存する場合、iOS は Android より少し面倒です。iOS の制限により、サードパーティ同期ツールが完全に無意識の常時バックグラウンド動作を実現するのは難しいためです。

まとめ

iPhone は Mobius Sync または FSync を通じて Syncthing エコシステムに参加し、写真を PC や NAS に同期できます。

ただし iOS で重要なのは、バックグラウンド制限と写真ライブラリ権限です。設定時はローカルネットワークと写真ライブラリへのフルアクセスを許可し、フォルダタイプは一方向バックアップとして設計します。iPhone は Send Only、NAS は Receive Only です。iCloud のストレージ最適化を有効にしている場合は、元画像が本当にローカルにあるかも確認してください。

写真アーカイブとして使うなら、定期的にクライアントを手動で開いて同期し、その後 NAS 側でバージョン保持、スナップショット、長期バックアップを担当させるのが最も安定します。

Android で Syncthing を使う方法：Syncthing-Fork の設定と写真バックアップ

Sun, 31 May 2026 12:17:19 +0800

Syncthing シリーズ目次

Android で Syncthing を使う場合、主な選択肢は 2 つあります。

Syncthing 公式の Android クライアント。
コミュニティ版の Syncthing-Fork。

軽く試すだけならどちらでも使えます。ただし、写真、ノート、文書を長期的に同期するなら Syncthing-Fork をおすすめします。Android のバックグラウンド制限、バッテリー、ネットワーク条件への対応が細かく、Wi-Fi のみ、特定 Wi-Fi のみ、充電時のみ実行といった設定ができます。

この記事では Android の基本設定と写真バックアップをまとめます。写真バックアップはスマートフォンで Syncthing を使う代表的な用途ですが、通常の双方向同期フォルダーとして扱うべきではありません。

Syncthing-Fork をすすめる理由

Android はバックグラウンドアプリを積極的に制限します。画面が消えると、ネットワークが止まったり、プロセスが凍結されたり、サービスが終了されたりします。同期アプリがこの制限に対応していないと、「アプリを開いているときだけ同期する」状態になりがちです。

Syncthing-Fork はスマートフォン利用に向いています。

実行条件を設定できる。
Wi-Fi 接続時だけ同期できる。
指定した Wi-Fi だけで同期できる。
充電中だけ同期できる。
Android のバックグラウンド制限に実用的に対応している。

公式クライアントが使えないわけではありません。Syncthing-Fork のほうが、長期的なモバイル同期に合わせやすいということです。

インストール元

Syncthing-Fork の主な入手先は次の通りです。

Google Play
F-Droid
GitHub Releases

信頼している経路を選びます。インストール後、すぐにデバイスを追加するのではなく、まず権限とバックグラウンド実行条件を整えます。

必要な権限

ストレージ権限

Android でファイルを同期するには、アプリが対象ディレクトリを読み書きできる必要があります。

新しい Android では「すべてのファイルへのアクセス」や類似の権限が必要になることがあります。権限がないと、Syncthing-Fork は写真、文書、指定した同期フォルダーを読めない場合があります。

同期先は、内部ストレージ上の普通のディレクトリにするのが安定します。

1
2
3

/storage/emulated/0/SyncData
/storage/emulated/0/SyncData/Notes
/storage/emulated/0/SyncData/Photos

カメラ写真の一般的な場所は次です。

`1`	`/storage/emulated/0/DCIM/Camera`

バッテリー最適化の除外

これは Android で最も重要な設定です。

Syncthing-Fork がバッテリー最適化の対象になっていると、画面ロック後に同期プロセスが止められることがあります。結果として、アプリを開いたときだけ同期が進みます。

システム設定で Syncthing-Fork を最適化対象から外します。端末メーカーによって名称は違います。

最適化しない
バックグラウンド実行を許可
自動起動を許可
バックグラウンド固定
高消費電力を許可

同期が不安定なときは、バッテリー管理と自動起動設定を両方確認します。

NAS や PC とペアリングする

Syncthing は device ID を互いに追加してペアリングします。

スマートフォン側：

Syncthing-Fork を開く。
メニューを開く。
デバイス ID を表示する。
QR コードまたは長い device ID を確認する。

NAS または PC 側：

Syncthing Web GUI を開く。
Add Remote Device をクリックする。
スマートフォンの QR コードを読み取るか、device ID を入力する。
Android-Phone や Pixel-Phone のように分かりやすい名前を付ける。
保存する。

スマートフォン側に接続リクエストが表示されたら承認します。この時点では信頼関係ができただけで、フォルダーはまだ同期されていません。

NAS や PC から共有されたフォルダーを受け取る

PC や NAS がスマートフォンへフォルダーを共有すると、スマートフォン側に通知が出ます。

例：

`1`	`Device NAS wants to share folder Notes`

追加するときに、スマートフォン上のローカルパスを指定します。

`1`	`/storage/emulated/0/SyncData/Notes`

このディレクトリは先に手動で作っておくと安心です。

Markdown ノートを同期する場合は、アプリ設定ディレクトリに注意します。Obsidian の .obsidian にはワークスペース状態、プラグイン設定、キャッシュがあります。Android と PC でプラグイン構成が大きく違う場合は、まず本文と添付だけを同期するほうが安全です。

スマートフォン写真を PC や NAS にバックアップする

スマートフォンで最も多い用途は、写真を NAS や PC へバックアップすることです。

写真バックアップは通常のファイル同期とは違います。多くの場合、欲しいのは「撮影した写真を NAS に送る」ことであり、「スマートフォンで写真を消したら NAS でも消える」ことではありません。そのため、一方向バックアップとして設計します。

おすすめは次の組み合わせです。

スマートフォン側：Send Only
PC または NAS 側：Receive Only

スマートフォンが写真を送り、NAS が受け取って保存します。NAS 側でファイルバージョンやスナップショットを使えば、誤削除のリスクをさらに減らせます。

スマートフォン側でカメラフォルダーを追加する

Syncthing-Fork のフォルダー画面で次のように設定します。

+ をタップする。
新しいフォルダーを作成する。
Pixel_Photos や Huawei_DCIM のような分かりやすいラベルを付ける。
スマートフォンのカメラディレクトリを選ぶ。
共有先として PC または NAS を選ぶ。

一般的なカメラ写真のパス：

`1`	`/storage/emulated/0/DCIM/Camera`

スクリーンショットや WeChat 画像などは別フォルダーにあることがあります。

1
2

/storage/emulated/0/Pictures/Screenshots
/storage/emulated/0/Pictures/WeiXin

端末やアプリによってパスは異なるため、ファイルマネージャーで確認してから選びます。

スマートフォン側を Send Only にする

フォルダー設定で、既定の：

`1`	`Send & Receive`

を次に変更します。

`1`	`Send Only`

これでスマートフォンは写真の送信元になります。新しい写真は NAS へ送られますが、NAS 側の変更はスマートフォンへ戻りません。

ただし Syncthing は同期ツールであり、完全なバックアップシステムではありません。NAS 側のバージョン管理、スナップショット、独立バックアップを組み合わせるべきです。

受信側の保存パスを設定する

スマートフォン側で保存すると、PC や NAS の Web GUI に共有リクエストが出ます。

`1`	`Device Pixel-Phone wants to share folder Pixel_Photos`

追加して保存先を指定します。

Windows の例：

`1`	`D:\Backups\Phone_Photos`

Linux や NAS の例：

`1`	`/volume1/photos/phone`

Docker で Syncthing を動かしている場合は、コンテナ内パスを使います。ホスト側マッピングが次なら：

`1`	`- /volume1/photos:/var/syncthing/photos`

Web GUI では次を指定します。

`1`	`/var/syncthing/photos/phone`

受信側を Receive Only にする

PC や NAS 側のフォルダータイプを次にします。

`1`	`Receive Only`

受信側はスマートフォンからの写真を受け取るだけで、ローカル変更をスマートフォンへ送り返しません。

これにより、NAS 上で整理、移動、誤削除をしても、スマートフォンの元写真に直接影響しにくくなります。ただし Receive Only は NAS 側の履歴機能の代わりではないため、ファイルバージョンやスナップショットも有効にします。

最初は小さくテストする

いきなり数万枚の写真を同期しないほうがよいです。

まず 3-5 枚の写真で試す。
PC や NAS に届くことを確認する。
1 枚追加して自動同期を確認する。
テスト写真をスマートフォンで削除し、NAS 側の挙動を見る。
期待通りなら本番の相冊を同期する。

フォルダータイプと削除動作は誤解しやすいため、小さく試すのが安全です。

実行条件でモバイル通信を防ぐ

Syncthing-Fork では実行条件を設定できます。最低限、次を有効にします。

`1`	`Wi-Fi 接続時のみ実行`

写真は大きくなりやすいため、5G や 4G で勝手に同期しないようにします。

自宅だけで同期したい場合は、特定の Wi-Fi SSID に限定できます。NAS が家庭内 LAN からしか見えない場合にも便利です。

充電時だけ同期する

リアルタイム同期が不要なら、次も有効にできます。

充電中のみ実行

安定した運用例：

日中は普通に写真を撮る。
Syncthing-Fork は常時バックグラウンドで動かさない。
夜に帰宅して家庭内 Wi-Fi に接続する。
充電器につなぐ。
Syncthing-Fork が起動し、その日の写真やファイルを NAS へ同期する。

常時同期より省電力で、スマートフォンの使い方にも合います。すぐに反映したいノートは、充電時のみではなく Wi-Fi のみに留めてもよいです。

Android 11 以降のストレージ制限

Android 11 以降はストレージ制限が厳しくなっています。特に次のディレクトリは安定して読み書きできないことがあります。

1
2

Android/data
Android/obb

SD カードも端末メーカー、Android バージョン、ファイルピッカー権限によって制限されることがあります。

フォルダータイプの選び方

ノートの双方向同期

スマートフォンと PC の両方で Markdown ノートを編集するなら：

`1`	`Send & Receive`

ただし同じファイルを複数デバイスで同時編集しないようにします。

写真を NAS に送る

スマートフォンが主に写真を送るなら：

`1`	`Send Only`

NAS 側でバージョン管理やスナップショットを使います。

スマートフォンで資料を見るだけ

NAS 上の資料をスマートフォンで読むだけなら：

`1`	`Receive Only`

電子書、参考資料、スクリプト例に向いています。

削除の意味を考える

スマートフォンで写真を削除したら NAS でも消えるのか。これはフォルダータイプと同期状態によります。

リスクを下げるには：

スマートフォン側は Send Only。
NAS 側は Receive Only。
NAS 側でファイルバージョンを有効にする。
NAS にスナップショットや別バックアップを用意する。

本当の目的がアーカイブなら、Syncthing は NAS の inbox ディレクトリだけに書き込み、別のタスクでアーカイブへ移す方式もあります。

1
2

/volume1/photos/inbox-phone
/volume1/photos/archive

Syncthing は inbox-phone に書き込み、スクリプトが archive に整理します。

よくある問題

画面ロック後に同期しない

確認する項目：

バッテリー最適化から除外されているか。
バックグラウンド実行が許可されているか。
自動起動が許可されているか。
Wi-Fi のみ、充電時のみの条件が有効ではないか。

多くの場合、Syncthing-Fork の設定ミスではなく Android のバックグラウンド管理が原因です。

相冊ディレクトリが見つからない

ファイルマネージャーで実際の場所を確認します。一般的には：

`1`	`/storage/emulated/0/DCIM/Camera`

サードパーティのカメラや編集アプリは別フォルダーを使うことがあります。

同期が遅い

確認する項目：

スマートフォンと NAS が同じ Wi-Fi にいるか。
relay 経由になっていないか。
NAS 側の 22000/TCP と 22000/UDP が使えるか。
スマートフォンが省電力モードではないか。
小さなファイルが大量にないか。

大量の小ファイルは少数の大きなファイルより遅くなりがちです。初回同期後は増分同期が軽くなります。

スマートフォンで削除した写真が NAS でも消える

削除操作が同期されているということです。Syncthing は同期ツールであり、標準で追記専用バックアップになるわけではありません。

対策：

スマートフォン側と NAS 側のフォルダータイプを確認する。
NAS 側でファイルバージョンを有効にする。
スナップショットや独立バックアップを用意する。
必要なら inbox ディレクトリからアーカイブへ移す運用にする。

まとめ

Android で Syncthing を使うとき、重要なのはアプリのインストールだけではありません。権限、バックグラウンド、バッテリー、ネットワーク条件を整える必要があります。

Syncthing-Fork は長期的なスマートフォン同期に向いています。Wi-Fi、特定 Wi-Fi、充電状態に同期を制限でき、バッテリー消費とモバイル通信を抑えられます。

写真を NAS へバックアップするなら、スマートフォン Send Only、PC または NAS Receive Only の一方向バックアップとして設計し、NAS 側のバージョン管理、スナップショット、独立バックアップで長期的な安全性を確保します。

Syncthing で複数デバイスを構成する方法：ピアネットワーク、スター型トポロジー、Introducer

Sun, 31 May 2026 12:13:57 +0800

Syncthing シリーズ目次

Syncthing は分散型の P2P アーキテクチャを採用しています。従来の意味での Server と Client の区別はなく、プロトコル上はすべてのデバイスが対等なピアです。

ただし実際の運用では、次の二つの形に整理できます。

純粋なピアネットワーク：各デバイスがほかのデバイスと直接ペアリングする。
スター型ネットワーク：NAS、サーバー、常時稼働の PC を中心ノードにし、ほかのデバイスはそれとだけペアリングする。

どちらも Syncthing の設計に合っています。違うのは管理コストと日常の使い勝手です。

まず「対等」と「疑似サーバー」を理解する

Syncthing の各デバイスには固有の device ID があります。二つのデバイスがお互いの ID を追加し、同じフォルダーを共有すれば同期できます。

つまり Syncthing には「サーバー側がすべてのデータを保持しなければならない」という前提はありません。あなたが「サーバー」と呼んでいるものは、多くの場合、運用上中心に置いた常時稼働デバイスです。

たとえば：

NAS は常時稼働し、容量も大きいので中心ノードに向いています。
スマートフォンやノート PC はオフラインになりやすく、エッジデバイスとして扱うのが自然です。
デスクトップ PC は高性能でも、24 時間稼働とは限らないため、通常の同期ノードとして考えます。

この「中心ノード」はプロトコル上のサーバーではありません。トポロジー設計の中で、管理と中継を担わせるデバイスです。

モード 1：純粋な Peer Mesh ネットワーク

純粋なピアモードでは、すべてのデバイスがほかのすべてのデバイスとペアリングします。

たとえば四つのデバイスがあるとします。

NAS
デスクトップ
ノート PC
スマートフォン

この場合、各デバイスは残り三つのデバイスと接続します。これにより、オンラインの任意の二台が直接同期できます。

利点：

転送経路がより直接的です。
一台がオフラインでも、ほかのオンラインデバイス同士は同期できます。
特定の中心ノードに依存しません。

欠点：

デバイスが増えるほど、ペアリング関係が複雑になります。
新しいデバイスを追加するとき、複数の既存デバイスで確認と設定が必要になります。
フォルダー共有の関係が分散しやすくなります。

デバイス数が少ない場合、純粋なピアモードは快適です。たとえば PC 一台とスマートフォン一台、または二台の PC でメモを同期するだけなら、複雑に考える必要はありません。

しかしデバイスが五、六台以上になると、完全接続の関係を手作業で維持するのはだんだん面倒になります。

モード 2：NAS を中心にしたスター型トポロジー

スター型は家庭や個人の生産性用途に向いています。

長時間稼働し、容量が十分で、ネットワークが安定しているデバイスを中心ノードにします。たとえば：

NAS
Synology
ソフトルーター
ミニ PC
自宅 Linux サーバー

そしてほかのデバイスは、その中心ノードとだけペアリングします。

1
2
3

スマートフォン ----\
ノート PC      ---- NAS
デスクトップ   ----/

スマートフォンはノート PC と直接ペアリングする必要がなく、ノート PC もデスクトップと直接ペアリングする必要はありません。すべて NAS を経由して間接的に同期します。

利点：

管理が簡単です。
新しいデバイスは NAS とだけペアリングすれば済みます。
NAS がバージョン保持やバックアップの受け皿になります。
24 時間同期に向いています。

欠点：

NAS がオフラインになると、ほかのデバイス同士は同期を続けられない場合があります。
すべての通信が NAS を通る場合、NAS のネットワーク性能とディスク性能が体験に影響します。
中心ノードの権限管理を慎重に行う必要があります。

すでに NAS や常時稼働の小型サーバーがあるなら、まずスター型トポロジーをおすすめします。Syncthing の P2P の強みを残しつつ、日常管理はかなり中央集約型の同期に近づきます。

複数デバイス設定の基本順序

どのトポロジーを使う場合でも、Syncthing の設定順序は同じです。

先にデバイスをペアリングする。
次にフォルダーを共有する。
最後に受信側でローカルパスを確認する。

最初からあちこちにフォルダーを作らないでください。先にデバイス関係を整理しておくと、後の設定が乱れにくくなります。

ステップ 1：デバイスを接続する

デバイス A とデバイス B を接続するとします。

デバイス A はスマートフォン、デバイス B は NAS や PC だと考えてください。

デバイス A で：

Syncthing Web UI を開きます。
右上の 操作 をクリックします。
ID を表示 を選びます。
device ID をコピーするか、QR コードを表示します。

デバイス B で：

Syncthing Web UI を開きます。
リモートデバイスを追加 をクリックします。
デバイス A の ID を入力します。
My-Phone のような識別しやすい名前を付けます。
保存します。

その後デバイス A に戻ります。通常は、デバイス B が接続しようとしているという通知が表示されるので、承認します。

ここまでで二台のデバイスは対等な関係を確立しました。ただし、まだどのフォルダーも同期していません。

ステップ 2：フォルダーを作成して共有する

デバイス A で フォルダーを追加 をクリックします。

よく使う項目：

フォルダーラベル：自分が見るための名前。例：Notes。
フォルダー ID：デバイス間で識別するための ID。notes のような安定した英語名がおすすめです。
フォルダーパス：このデバイス上の実際のパス。

次に 共有 タブへ切り替え、先ほどペアリングしたデバイス B にチェックを入れます。

保存すると、デバイス A からデバイス B にフォルダー共有の招待が送られます。

ステップ 3：共有を受け入れる

デバイス B の Web UI を開いて数秒待つと、通常は次のような通知が表示されます。

`1`	`デバイス A がフォルダーを共有しようとしています`

追加をクリックし、デバイス B 上のローカル保存先を指定します。

例：

`1`	`/volume1/notes`

Docker デプロイの場合は、コンテナー内パスになります。

`1`	`/var/syncthing/notes`

保存すると同期が始まります。

ここで重要なのは、各デバイスのパスは同じでなくてもよいということです。Syncthing はフォルダー ID で同期関係を識別し、すべてのデバイスに同じローカルパスを要求しません。

スター型トポロジーの設定方法

NAS 中心の構成を使うなら、次のようにします。

まず NAS に Syncthing をデプロイする。
すべてのスマートフォン、PC、サーバーを NAS とだけペアリングする。
NAS 上で主要な同期フォルダーを作成または受け入れる。
新しいデバイスは NAS の device ID だけを追加する。
同期したいフォルダーを、NAS と対象デバイスの間で共有する。

例：

NAS
├── notes       -> デスクトップ、ノート PC、スマートフォン
├── photos      -> スマートフォン、バックアップディスク
├── downloads   -> デスクトップ、NAS
└── scripts     -> デスクトップ、ノート PC

この構造はとても分かりやすいです。NAS を同期関係のコントロールパネルとして扱えます。

Introducer とは何か

Syncthing には Introducer という便利な機能があります。日本語では「紹介者」や「Introducer」と表示されることがあります。

これは複数デバイス環境に向いています。

NAS を Introducer に設定したとします。その後、新しいデバイスが NAS とペアリングすると、NAS は自分が知っているほかのデバイスを新しいデバイスに紹介できます。既存の共有関係の反映にも役立ちます。

これにより、同じクリックや同じペアリング作業を繰り返す必要が減ります。

向いているケース：

家に複数の PC とスマートフォンがある。
NAS が長時間稼働する中心ノードになっている。
新しいデバイスをよく追加する。
デバイス関係の手動メンテナンスを減らしたい。

ただし Introducer は、自動的に確立される関係の範囲を広げます。完全に信頼できないデバイスを Introducer にしないでください。トポロジーを理解しないまま気軽に有効化するのも避けましょう。

より安全な考え方は次の通りです。

NAS またはメインサーバーだけを Introducer にする。
普通のスマートフォンやノート PC は Introducer にしない。
新しいデバイスを追加した後、自動追加されたデバイスとフォルダーを確認する。

フォルダータイプがデータの向きを決める

Syncthing の権限制御は、主にフォルダータイプに現れます。

フォルダー設定を開き、オプション内の Folder Type を調整します。

よく使う三種類があります。

Send & Receive

デフォルトのモードです。双方が変更を送信し、受信できます。

向いている用途：

複数デバイスでノートを編集する。
複数の PC で文書を同期する。
一般的な双方向同期フォルダー。

これは「本当の対等」に最も近いモードです。

Send Only

このデバイスは送信のみ行い、ほかのデバイスからの変更を受け取りません。

向いている用途：

データの発生元。
メインディレクトリをほかのデバイスへ配布する。
リモート側の変更でこのデバイスが影響を受けないようにする。

たとえば NAS 上のソフトウェアインストーラー用ディレクトリを Send Only にし、ほかの PC は受信だけにできます。

Receive Only

このデバイスは受信のみ行い、ローカル変更を外へ送信しません。

向いている用途：

バックアップ機。
読み取り専用ミラー。
ローカルの誤削除が元データへ逆流するのを防ぐ。

たとえば NAS でスマートフォンの写真を受け取る場合、スマートフォン側で写真を削除しても NAS 側まで削除したくないなら、フォルダータイプと削除ポリシーをきちんと設計する必要があります。

フォルダーごとに違うトポロジーを使える

Syncthing のトポロジーは、サイト全体で一つに統一する必要はありません。フォルダー単位で設計できます。

例：

notes：デスクトップ、ノート PC、スマートフォン、NAS がすべて Send & Receive。
photos：スマートフォンが送信し、NAS が受信してバージョンを保持する。
downloads：デスクトップと NAS が同期し、スマートフォンは参加しない。
backup：メイン PC は Send Only、NAS は Receive Only。

すべてのディレクトリを一つのルールに押し込まないでください。複数デバイス同期で本当に重要なのは、デバイス数ではなくデータの流れです。

衝突と誤削除を先に考える

複数デバイス同期でよく起きる問題は、設定失敗ではありません。同期が成功した後の誤削除や競合です。

問題が起きやすい場面：

二台のデバイスが同じファイルを同時に編集する。
スマートフォンアプリがディレクトリを自動クリーンアップする。
一台のデバイスでパスを間違え、空のディレクトリを作って同期してしまう。
キャッシュ、一時ファイル、作業状態ファイルをまとめて同期してしまう。
NAS 側でバージョン保持を有効にしていない。

まとめ

Syncthing は P2P の対等アーキテクチャですが、すべてのデバイスを複雑なメッシュ構造にする必要はありません。

小規模な環境なら純粋なピアモードで十分です。デバイスが多い場合や、NAS あるいは常時稼働ホストがある場合は、スター型トポロジーをおすすめします。NAS に中心ノードと Introducer の役割を持たせ、ほかのデバイスは NAS とだけ関係を作ると、管理がかなり簡単になります。

本当に考えるべきなのは、どのデバイスを信頼するか、どのディレクトリを同期するか、データがどこから来るか、誤削除時にどこがバージョンを保持するかです。トポロジーは手段であり、データの流れこそが設定の核心です。

Docker で Syncthing をデプロイする：Compose、ポート、ディレクトリマッピングの注意点

Sun, 31 May 2026 12:12:05 +0800

Syncthing シリーズ目次

Docker で Syncthing をデプロイする構成は、NAS、家庭用サーバー、VPS によく合います。24 時間稼働する同期ノードとして、写真、文書、Markdown ノート、ダウンロードディレクトリなどを継続的に同期できます。

Docker で Syncthing を動かすときに重要なのは、「コンテナが起動するか」だけではありません。特に次の三点が重要です。

設定ディレクトリを永続化すること。
同期したいデータディレクトリをホストからコンテナにマッピングすること。
ポートと権限を事前に整理しておくこと。

ここを曖昧にすると、コンテナ更新後に設定が消えたり、Web UI に入力したパスが実際のホストディレクトリを指していなかったり、同期時に Permission denied が出たりします。

ディレクトリ設計

まずサーバーまたは NAS 上に専用ディレクトリを用意します。

1
2

mkdir -p ~/syncthing
cd ~/syncthing

このディレクトリに docker-compose.yml を置き、Syncthing の設定はサブディレクトリに保存します。

1
2
3

syncthing/
├── docker-compose.yml
└── config/

同期対象のデータディレクトリは、NAS やホスト上の既存パスを使えます。

1
2

/volume1/downloads
/volume1/photos

設定ディレクトリとデータディレクトリは分けてください。config には Syncthing 自身の設定、鍵、インデックスデータベースが入ります。downloads や photos のようなディレクトリが、実際に同期したいデータです。

方法 1：Docker Compose

長期運用では Docker Compose を使う方が、更新、再起動、移行の見通しがよくなります。

~/syncthing/docker-compose.yml に次の内容を書きます。

version: "3"

services:
  syncthing:
    image: syncthing/syncthing:latest
    container_name: syncthing
    hostname: my-nas-syncthing
    environment:
      - PUID=1000
      - PGID=1000
      - TZ=Asia/Shanghai
    volumes:
      - ./config:/var/syncthing/config
      - /volume1/downloads:/var/syncthing/downloads
      - /volume1/photos:/var/syncthing/photos
    ports:
      - 8384:8384
      - 22000:22000/tcp
      - 22000:22000/udp
      - 21027:21027/udp
    restart: unless-stopped

起動します。

`1`	`docker compose up -d`

状態を確認します。

1
2

docker compose ps
docker logs -f syncthing

Web UI を開きます。

`1`	`http://server-ip:8384`

初回アクセス後は、まず GUI のユーザー名とパスワードを設定してください。

方法 2：docker run

短時間の検証であれば、docker run でも起動できます。

docker run -d \
  --name syncthing \
  --hostname my-nas-syncthing \
  -e PUID=1000 \
  -e PGID=1000 \
  -e TZ=Asia/Shanghai \
  -p 8384:8384 \
  -p 22000:22000/tcp \
  -p 22000:22000/udp \
  -p 21027:21027/udp \
  -v /path/to/config:/var/syncthing/config \
  -v /path/to/data1:/var/syncthing/data1 \
  --restart unless-stopped \
  syncthing/syncthing:latest

/path/to/config と /path/to/data1 は、実際のホストパスに置き換えてください。

例：

1
2

-v /volume1/docker/syncthing/config:/var/syncthing/config
-v /volume1/photos:/var/syncthing/photos

長期的に使うなら Compose に移行しておくと、コンテナを作り直すたびに長いコマンドを組み立て直す必要がありません。

コンテナ内パスとホストパス

Docker で最も混乱しやすいのがパスです。

たとえば Compose に次のように書いたとします。

1
2

volumes:
  - /volume1/photos:/var/syncthing/photos

左側の /volume1/photos はホストパスです。右側の /var/syncthing/photos はコンテナ内パスです。

Syncthing の Web UI で同期フォルダを追加するときは、フォルダパスにコンテナ内パスを入力します。

`1`	`/var/syncthing/photos`

これにより Syncthing が実際に操作するのは、ホスト側の次のディレクトリになります。

`1`	`/volume1/photos`

Web UI に /volume1/photos と入力しても、通常そのパスはコンテナ内には存在しません。エラーになるか、意図しない新しいディレクトリがコンテナファイルシステム内に作られる可能性があります。

設定ディレクトリは必ず永続化する

次の行は非常に重要です。

`1`	`- ./config:/var/syncthing/config`

Syncthing の設定ファイル、デバイス鍵、インデックスデータベースは設定ディレクトリに保存されます。これをホストにマウントしないと、コンテナの削除や再作成でデバイス ID が変わり、既存のペアリング関係が失効することがあります。

設定ディレクトリは、次のような安定したパスに置くのがおすすめです。

`1`	`/volume1/docker/syncthing/config`

一時ディレクトリには置かず、同期データのディレクトリとも混在させないでください。

ポートとファイアウォール

よく使うポートは次の通りです。

8384/TCP   Web UI 管理画面
22000/TCP デバイス間同期トラフィック
22000/UDP QUIC 同期トラフィック
21027/UDP ローカルネットワーク検出

Syncthing を家庭用 NAS にデプロイする場合は、通常次を確認します。

NAS のファイアウォールでこれらのポートが許可されているか。
Docker ブリッジのポートマッピングが正しいか。
ルーターが Wi-Fi と有線ネットワークを分離していないか。
スマートフォンとコンピューターが同じサブネットにいるか。

クラウドサーバーにデプロイする場合は、クラウド事業者のセキュリティグループも確認します。特に 22000/TCP と 22000/UDP が許可されていないと、他のデバイスは relay 経由でしか接続できず、速度が大きく低下します。

8384 は管理画面のポートです。インターネットに直接公開するのは避けてください。どうしてもリモート管理が必要な場合は、少なくとも強いパスワードを設定し、できればリバースプロキシ、HTTPS、アクセス制御、VPN と組み合わせます。

権限問題：PUID と PGID

Syncthing の Web UI は開けるのに、同期ディレクトリで次のようなエラーが出る場合があります。

`1`	`Permission denied`

多くの場合、コンテナプロセスにホストディレクトリの読み書き権限がありません。

まずホストで現在のユーザーの UID と GID を確認します。

id

出力例：

`1`	`uid=1000(user) gid=1000(user) groups=1000(user)`

Compose の環境変数を対応する値にします。

1
2
3

environment:
  - PUID=1000
  - PGID=1000

同時に、ホスト側ディレクトリ自体がそのユーザーに読み書きを許可しているか確認します。

`1`	`ls -ld /volume1/photos`

必要であれば所有者や権限を調整します。

`1`	`sudo chown -R 1000:1000 /volume1/photos`

NAS では、共有ディレクトリ全体に対して安易に再帰的な権限変更をしないでください。複数人で使っている共有では特に危険です。Syncthing 専用の同期ディレクトリを用意するか、NAS の権限管理画面で該当ユーザーに権限を付与する方が安全です。

Web UI の初回セキュリティ設定

コンテナ起動後、次にアクセスします。

`1`	`http://server-ip:8384`

初回アクセス時、Syncthing は通常 GUI のユーザー名とパスワード設定を促します。この手順は省略しないでください。

推奨設定：

すぐに GUI ユーザー名と強いパスワードを設定する。
8384 をインターネットに公開しない。
リモートアクセスは VPN、SSH トンネル、制御されたリバースプロキシを優先する。
リバースプロキシを使う場合は Web UI のみを代理し、不要なポートを誤って開放しない。

管理画面を第三者に操作されると、デバイスの追加、共有フォルダの変更、同期関係の変更が可能になります。Syncthing の同期データ転送は暗号化されていますが、管理入口そのものは別途保護が必要です。

Web UI で同期ディレクトリを追加する

写真ディレクトリを例にします。Compose ではすでに次のようにマウントしています。

`1`	`- /volume1/photos:/var/syncthing/photos`

Web UI でフォルダを追加するときは、次のように設定します。

Folder Label：Photos など。
Folder ID：photos のような安定した英数字 ID。
Folder Path：/var/syncthing/photos。
Sharing：共有先のデバイスを選択。
Folder Type：用途に応じて Send & Receive、Send Only、Receive Only を選択。

この Docker ノードが NAS の中心ノードであれば、よくある設定は次の通りです。

通常の文書：Send & Receive
スマートフォン写真の集約：NAS 側で Receive Only
配布用ディレクトリ：NAS 側で Send Only

どれを選ぶかはデータの流れで決めます。すべてのフォルダを何も考えず双方向同期にするのは避けましょう。

コンテナの更新

Compose を使っている場合、更新は通常次のように行います。

1
2

docker compose pull
docker compose up -d

設定ディレクトリとデータディレクトリが正しくマウントされていれば、コンテナを更新してもデバイス ID、ペアリング関係、同期フォルダ設定は失われません。

更新前に設定ディレクトリをバックアップしておくこともできます。

`1`	`tar -czf syncthing-config-backup.tar.gz ./config`

設定ディレクトリにはデバイス秘密鍵が含まれます。バックアップファイルを公共の場所へ安易にアップロードしないでください。

よくある問題

Web UI が開けない

まずコンテナが動作しているか確認します。

1
2

docker ps
docker logs syncthing

次にポートマッピングを確認します。

`1`	`docker port syncthing`

コンテナが正常でも開けない場合は、ホストのファイアウォール、NAS のファイアウォール、クラウドサーバーのセキュリティグループを確認します。

追加したディレクトリが存在しないと言われる

Web UI に入力したパスがコンテナ内パスか確認してください。

たとえばホストパスが次の場合：

`1`	`/volume1/downloads`

コンテナ内パスが次の場合：

`1`	`/var/syncthing/downloads`

Web UI には後者を入力します。

Relay 経由のみで速度が遅い

まず次を確認します。

22000/TCP が許可されているか。
22000/UDP が許可されているか。
ルーターのポート転送が正しいか。
クラウドサーバーのセキュリティグループが TCP と UDP の両方を許可しているか。
ローカルファイアウォールが Docker のマッピングポートをブロックしていないか。

Relay は接続性を高めますが、大量の同期トラフィックを長期的に任せる用途には向きません。

同期後のファイル権限がおかしい

まずコンテナの実行ユーザーが正しいか確認し、次にホストディレクトリの権限を確認します。Linux、NAS、Windows 共有フォルダでは権限モデルが異なります。Syncthing を権限修復ツールとして使わないでください。

複数 OS 間で同期する場合は、通常のファイルとディレクトリを対象にし、複雑な ACL、所有者、拡張属性に依存するシステムディレクトリは避けるのが無難です。

より安定した使い方

NAS やサーバーを中心ノードとして使うなら、次のように設計できます。

NAS 上で Docker により Syncthing を実行する。
設定ディレクトリを /volume1/docker/syncthing/config にマウントする。
データ種別ごとに個別にマウントする。例：/volume1/photos、/volume1/notes。
スマートフォンやコンピューターから NAS のデバイス ID を追加する。
重要なディレクトリでは NAS 側でファイルバージョン管理を有効にする。
Web UI は LAN または VPN 内からのみアクセスする。
NAS 自体にも独立したバックアップを用意し、同期を唯一のバックアップにしない。

この構成では、Syncthing がデバイス間同期を担当し、NAS が常時稼働とバージョンの緩衝役を担います。本当のバックアップは、スナップショット、外付けディスク、オフサイトバックアップに任せます。

まとめ

Docker で Syncthing をデプロイするときの要点は、「コンテナのライフサイクル」と「同期データのライフサイクル」を分離することです。

コンテナはいつでも更新、再作成、移行できます。しかし設定ディレクトリとデータディレクトリは、ホスト上に安定して保持する必要があります。Web UI ではコンテナ内パスを入力し、ホスト側の権限は PUID、PGID、ディレクトリ権限で処理し、ポートは実際のネットワーク環境に合わせて開放します。

このあたりを明確にしておけば、Syncthing は NAS、サーバー、個人デバイス間の軽量な同期レイヤーとして非常に使いやすくなります。

Syncthing の使い方：デバイスのペアリングからファイル同期までの実用メモ

Sun, 31 May 2026 11:59:09 +0800

Syncthing シリーズ目次

Syncthing は、複数デバイス間でファイルをピアツーピア同期するのに向いています。従来型のクラウドドライブではなく、すべてのデータをいったん中央サーバーへアップロードしてからダウンロードする仕組みでもありません。許可されたデバイス同士が直接ファイルを交換します。

Markdown ノート、写真バックアップ、設定ファイル、家庭内 NAS のディレクトリを同期したい場合、まず考えるべきなのは「同期できるか」だけではありません。デバイス、フォルダ、デバイス ID、同期方向、検出方法、競合処理を理解しておく必要があります。

Syncthing が解決すること

Syncthing の中心的な用途は、2 台以上のデバイスで特定のディレクトリを同じ状態に保つことです。

典型例は次の通りです。

Windows デスクトップとノート PC の間で作業資料を同期する。
スマートフォンと NAS の間で写真や文書を同期する。
複数の Linux サーバー間で設定例、スクリプト、小規模な資料ディレクトリを同期する。
Obsidian、Joplin の外部添付、Markdown ノートディレクトリを複数デバイスで同期する。

Syncthing は、自分でデバイスとデータを管理したい場面に向いています。複数人の権限管理、Web プレビュー、共有リンク、共同編集が必要なら、従来のクラウドドライブや文書コラボレーションサービスのほうが合います。

初回起動で何が起きるか

公式の入門ドキュメントでは、2 台のマシンを並べて設定する流れが紹介されています。Syncthing では、1 台のマシンを 1 つの device と考えます。いま設定しているマシンが local device、同期相手が remote device です。

初回起動時、Syncthing は設定ファイル、暗号鍵、デバイス ID を生成します。既定ではローカルで Web GUI を開きます。

`1`	`http://127.0.0.1:8384/`

Web GUI は日常的な設定入口です。既定で Default Folder が作成されることもあり、多くの場合はユーザーディレクトリ配下の Sync フォルダに対応します。まずテストに使ってもよいですし、後で削除して自分のフォルダを追加してもかまいません。

デバイス ID がペアリングの基本

Syncthing は device ID でデバイスをペアリングします。

各デバイスは初回起動時に自分の鍵を生成します。デバイス ID は、そのデバイス証明書の読みやすいフィンガープリントのようなものです。2 台のデバイスは、互いの device ID を追加して初めて接続し、同期できます。

一般的な手順は次の通りです。

両方のデバイスで Syncthing を起動する。
それぞれで Web GUI を開く。
A に B の device ID を追加する。
B に A の device ID を追加する。
共有するフォルダを選ぶ。
保存して接続を待つ。

device ID はパスワードのように秘匿する必要はありませんが、同期トポロジーを不必要に公開するべきではありません。本当に保護すべきなのは、デバイスの秘密鍵、Web GUI の管理権限、同期対象のディレクトリです。

フォルダは自動で全体同期されない

Syncthing が同期するのは、明示的に追加した folder だけです。デバイス全体を既定で同期することはありません。

各フォルダには、パス、ID、共有先デバイス、同期タイプがあります。用途ごとに分けるのが扱いやすいです。

notes/：Markdown ノート。
photos-inbox/：スマートフォン写真の取り込み。
docs/：複数デバイスで使う文書。
scripts/：小さなスクリプトや設定例。

最初から巨大なシステムディレクトリ、ダウンロードディレクトリ、雑多なディレクトリを同期しないほうがよいです。ディレクトリが複雑になるほど、競合、無視ルール、権限差、スキャンコストが長期的な負担になります。

よく使う 3 つのフォルダタイプ

公式ドキュメントではフォルダタイプが明確に整理されています。実用上はまず次の 3 つを理解すれば十分です。

Send & Receive

既定のモードです。このフォルダはローカルの変更を送信し、他のデバイスの変更も受信します。

向いている用途：

複数の PC でノートを編集する。
複数デバイスで文書を管理する。
一般的な双方向同期ディレクトリ。

2 台のデバイスが同じファイルを同時に変更した場合、Syncthing は片方を黙って上書きせず、競合ファイルを作成します。

Send Only

このモードでは、ローカルフォルダが基準コピーのように扱われます。他のデバイスへ変更を送信しますが、他のデバイスから来た変更は適用しません。

向いている用途：

主デバイスからバックアップ先へ配布する。
あるマシンのディレクトリ状態を基準にしたい。
リモート側の変更でローカルが影響を受けてほしくない。

リモート側で変更が発生すると、ローカル側は out of sync と表示される場合があります。このとき Web GUI に Override Changes が表示され、ローカル状態をクラスタ全体へ押し出せます。慎重に使うべき操作です。

Receive Only

Send Only の逆です。クラスタ内の変更は受信しますが、ローカル変更は他のデバイスへ送信しません。

向いている用途：

バックアップ先。
読み取り専用ミラー。
ローカルの誤操作で主同期ディレクトリを汚したくないデバイス。

ローカル変更があると、Web GUI に Revert Local Changes が表示され、クラスタの状態へ戻せます。

ファイアウォールとポートを先に確認する

Syncthing は discovery、NAT、relay などでデバイスを見つけられますが、ネットワークを理解しているほど接続は安定します。

公式のファイアウォール文書にある重要なポートは次の通りです。

1
2
3

22000/TCP
22000/UDP
21027/UDP

それぞれの役割は次の通りです。

22000/TCP は TCP 同期トラフィック。
22000/UDP は QUIC 同期トラフィック。
21027/UDP はローカル検出。

同じ LAN 内にいるのにデバイスが見つからない場合は、まずローカルファイアウォール、ルーターの隔離設定、Wi-Fi と有線 LAN が別セグメントになっていないかを確認します。

インターネット越しや NAT 越しでは、ポート転送できるなら直接接続のほうが relay より速いことが多いです。ポート転送できない場合でも relay で接続できることはありますが、速度は落ちます。

Linux で ufw を使い、対応するプロファイルが入っている場合は次のように設定できます。

1
2

sudo ufw allow syncthing
sudo ufw status verbose

Web GUI は既定で 127.0.0.1:8384 のみをリッスンします。0.0.0.0:8384 に変更すると管理画面が外部から到達可能になるため、パスワード、HTTPS、リバースプロキシ、SSH トンネルを考慮する必要があります。家庭用途では SSH トンネルのほうが安全です。

`.stignore` は同期ルートに置く

同期したくないファイルがある場合は、同期フォルダのルートに .stignore を作成します。

注意点：

.stignore は同期フォルダのルートに置く。
ルールは同期ルートからの相対パスで解釈される。
.stignore 自体は他のデバイスへ同期されない。
ファイルは UTF-8 で保存する。

簡単な例：

(?d).DS_Store
node_modules
*.tmp
cache/**
!/cache/keep.txt

(?d) は、無視されたファイルがディレクトリ削除を妨げる場合に Syncthing が削除してよいことを示します。.DS_Store のような自動生成ファイルに向いています。

! は否定ルールで、特定ファイルを再び同期対象に含めます。ただし複雑な否定ルールは、本来無視されるディレクトリを Syncthing に走査させることがあります。まずは単純なルールから始めるのが無難です。

ファイルバージョンはローカル Undo ではない

Syncthing はファイルバージョン管理に対応していますが、意味を誤解しやすい機能です。

公式ドキュメントでは、バージョン管理は「リモート変更を受信してローカルの古いファイルが置き換えられるとき、その古いファイルを保存する」ものだと説明されています。B がファイルを変更して A に同期した場合、A は置き換えられる前のファイルを保存できます。しかし A がローカルでファイルを編集した場合、その編集前の状態を Syncthing が保存するわけではありません。

代表的な方式：

Trash Can File Versioning：削除・置換されたファイルを .stversions に移動する。
Simple File Versioning：固定数の履歴を保持する。
Staggered File Versioning：最近は細かく、古いものは粗く保持する。
External File Versioning：外部スクリプトへ処理を渡す。

重要な文書を同期するなら、少なくともバックアップ先で simple または trash can のバージョン管理を有効にするのがおすすめです。完全なバックアップではありませんが、誤削除や誤上書きの被害を減らせます。

同期競合はどう起きるか

Syncthing は競合を検出します。2 台のデバイスが同じファイルを同時に別内容へ変更すると、次のような競合ファイルが作られることがあります。

`1`	`filename.sync-conflict-date-time-modifiedBy.ext`

黙って上書きされるより安全ですが、競合ファイルは定期的に整理する必要があります。

競合が起きやすい場面：

複数デバイスで同じ Markdown ノートを同時に開く。
アプリが同じ状態ファイルを自動更新する。
.obsidian/workspace.json のようなデバイス固有状態ファイルを同期する。
Windows、macOS、Android 間でファイル名の大文字小文字差が出る。

ノートを同期する場合は、本文、添付、テンプレートをまず同期対象にします。ワークスペース状態、キャッシュ、プラグインの一時ファイルは慎重に扱い、必要なら .stignore に入れます。

セキュリティ境界

Syncthing のセキュリティ目標の一つは、許可されていないデバイスが同期クラスタに参加できず、通信中のファイル内容が第三者に読まれないことです。

公式のセキュリティ文書によると、デバイス間通信は TLS で保護され、接続時にはデバイス証明書のフィンガープリントが許可リストにあるか確認されます。つまり、双方が互いの device ID を設定して初めて同期関係が成立します。

ただし、Syncthing を使っている事実まで完全に隠れるわけではありません。

グローバル discovery を有効にすると、デバイス ID とリッスンアドレスが discovery server に通知される。
ローカル discovery は LAN 内にブロードキャストまたはマルチキャストする。
relay server は device ID を知るが、同期内容は復号できない。
Web GUI を外部公開すると、そのマシンで Syncthing が動いていることが分かる。

実用的な安全策：

認証と暗号化をきちんと設定しない限り、Web GUI をインターネットへ公開しない。
信頼できるデバイスだけを追加する。
重要なディレクトリはディスク暗号化や別バックアップと組み合わせる。
必要なければ global discovery、relay、自動アップグレードを無効化できるが、接続の便利さは下がる。

信頼しない暗号化デバイス

Syncthing には Untrusted / Encrypted Devices もあります。信頼できないデバイスに暗号化済みデータだけを保存させる機能です。

典型例は、クラウドサーバーや外部マシンを同期・バックアップに参加させたいが、平文ファイルは見せたくない場合です。信頼済みデバイスはフォルダパスワードで暗号化して送信し、同じパスワードを持つ別の信頼済みデバイスがそこから同期して復号できます。

ただし公式ドキュメントでも、この機能は beta / testing として扱われています。明確な目的がある場合に慎重に使う機能で、最初の主同期方式にはしないほうがよいです。

覚えておきたい点：

ファイルデータ、ファイル名、時刻、ハッシュ、ディレクトリ構造は保護される。
フォルダ ID、ラベル、おおよそのファイルサイズは完全には隠れない。
パスワードと folder ID は確実に保存する。
信頼しないデバイス側のフォルダタイプは Receive Encrypted にする。

家庭内 NAS、自分の PC、スマートフォン間の同期なら、通常は信頼済みデバイスとして使い、OS ログイン、ディスク暗号化、バックアップを整えるほうが維持しやすいです。

実用的な設定方針

Syncthing でノートや文書を長期同期するなら、次のように考えると扱いやすくなります。

データ種別ごとにフォルダを分け、大きな混在ディレクトリにしない。
主力 PC は Send & Receive にする。
NAS やバックアップ機は Receive Only とバージョン管理を検討する。
スマートフォンでは必要なディレクトリだけを同期する。
.stignore でキャッシュ、一時ファイル、ワークスペース状態を除外する。
LAN 内では 22000/TCP、22000/UDP、21027/UDP を使えるようにする。
Web GUI はなるべくローカルに限定し、遠隔管理は SSH トンネルや VPN を優先する。
重要データは同期だけに頼らず、独立したバックアップを用意する。

向いている場面、向いていない場面

Syncthing が向いている場面：

データを主に自分のデバイス上に置きたい。
デバイスのペアリング、同期ディレクトリ、競合処理を理解できる。
NAS、家庭内サーバー、複数の個人デバイスがある。
Markdown、写真の取り込み、スクリプト、軽量文書を同期したい。

あまり向いていない場面：

複数人でオンライン共同編集したい。
Web プレビューや共有リンクが必要。
細かなチーム権限管理が必要。
ネットワーク、ファイアウォール、競合問題を一切扱いたくない。

Syncthing は完全なクラウドドライブ製品ではなく、信頼できるデバイス間同期レイヤーとして理解するのがよいです。うまく使えば NAS、PC、スマートフォンを自分で制御できるデータネットワークにできます。雑に使うと、競合、誤削除、無視ルール、ネットワーク設定が維持負担になります。

Syncthing on KnightLiブログ

Syncthing で複数デバイスと複数フォルダーを管理する方法：トポロジー、命名、バージョン管理

Syncthing シリーズ目次

トポロジー：フルメッシュを避け、スター型を優先する

Folder ID はフォルダーラベルより重要

中心ノードのパスを整理する

Introducer：複数デバイスのペアリング作業を減らす

バックアップと双方向同期を分ける

スマートフォン写真バックアップ

複数端末のドキュメントとメモ

資料配布

バックアップディレクトリ

NAS でファイルバージョン管理を有効にする

Ignore Patterns で一時ファイルを除外する

複数フォルダーの命名例

推奨する全体構成

まとめ

Syncthing で iPhone の写真を PC や NAS に同期する方法

Syncthing シリーズ目次

まず iOS の制限を理解する

手順 1：クライアントをインストールして権限を付与する

通知権限

ローカルネットワーク権限

写真ライブラリへのアクセス権限

手順 2：iPhone と PC/NAS をペアリングする

手順 3：iPhone で写真同期用フォルダを作成する

手順 4：iPhone 側を Send Only にする

手順 5：PC または NAS 側で写真を受け取る

受信側は Receive Only がおすすめ

iOS のバックグラウンド同期の現実的な制限

iCloud のストレージ最適化による影響を避ける

大量写真の初回同期のすすめ

推奨構成

まとめ

Android で Syncthing を使う方法：Syncthing-Fork の設定と写真バックアップ

Syncthing シリーズ目次

Syncthing-Fork をすすめる理由

インストール元

必要な権限

ストレージ権限

バッテリー最適化の除外

NAS や PC とペアリングする

NAS や PC から共有されたフォルダーを受け取る

スマートフォン写真を PC や NAS にバックアップする

スマートフォン側でカメラフォルダーを追加する

スマートフォン側を Send Only にする

受信側の保存パスを設定する

受信側を Receive Only にする

最初は小さくテストする

実行条件でモバイル通信を防ぐ

充電時だけ同期する

Android 11 以降のストレージ制限

フォルダータイプの選び方

ノートの双方向同期

写真を NAS に送る

スマートフォンで資料を見るだけ

削除の意味を考える

よくある問題

画面ロック後に同期しない

相冊ディレクトリが見つからない

同期が遅い

スマートフォンで削除した写真が NAS でも消える

おすすめ構成

まとめ

Syncthing で複数デバイスを構成する方法：ピアネットワーク、スター型トポロジー、Introducer

Syncthing シリーズ目次

まず「対等」と「疑似サーバー」を理解する

モード 1：純粋な Peer Mesh ネットワーク

モード 2：NAS を中心にしたスター型トポロジー

複数デバイス設定の基本順序

ステップ 1：デバイスを接続する

ステップ 2：フォルダーを作成して共有する

ステップ 3：共有を受け入れる

スター型トポロジーの設定方法

Introducer とは何か

フォルダータイプがデータの向きを決める

Send & Receive

Send Only

Receive Only

フォルダーごとに違うトポロジーを使える

`.stignore` は同期ルートに置く