別のドライブでCasaOSのSyncthingフォルダーが機能しない

重要な結論：これは、Syncthing が動作するまで chmod を変更し続ける問題ではない可能性が高いです。より強い手がかりは、Syncthing から直接見えるパス上ではフォルダーが動作するのに、シンボリックリンクが別の物理ドライブへまたがると失敗することです。CasaOS では、まずコンテナのマウントパス、次に UID/GID の権限を確認する必要があります。

「権限は最後まで設定済みです。/DATA/AppData/ を対象にすると動作しますが、リンクが別の物理ドライブを指すと動作しません。」このテスト結果は、元の権限エラーよりも有用です。問題をストレージパスに絞り込めるからです。

シンボリックリンクを最初に疑う理由

Syncthing は、シンボリックリンクを「ターゲットへ移動して、そこにあるものを同期する」という意味では扱いません。文書化されているSyncthing のシンボリックリンク動作では、シンボリックリンクは同期されることはあっても、リンク先をたどることはありません。また、フォルダー設定では実デバイス上のパスが想定されています。Syncthing のフォルダーパスは、ハードドライブ上のフォルダーへの物理パスです。

そのため、次のようなパスは疑わしいものです。

/DATA/Documents/Syncthing/SyncFiles → シンボリックリンク → /some/other/physical/drive

Syncthing が Docker 内で実行されている場合、ホストではそのリンクを解決できても、コンテナからは参照先がまったく見えないことがあります。

CasaOS の Syncthing アプリから分かる、2 台目のドライブが見えなくなる理由

Syncthing の公式 CasaOS App Store 定義は、この点で非常に参考になります。その compose ファイルでは、ホスト上の 2 つのパスをコンテナ内にバインドマウントしています。

/DATA/AppData/$AppID/config → /config
/DATA                      → /DATA

実際のボリュームマッピングは、CasaOS Syncthing の compose ファイルで確認できます。

つまり、ホスト上の /DATA ツリー内に物理的に存在するターゲットは、Syncthing コンテナ内の /DATA からも見えるはずです。ただし、シンボリックリンクの最終的な参照先がそのツリー外にあるホストマウントの場合、実際の参照先に対する個別のバインドマウントがコンテナに必要です。Docker のバインドマウントでは、ホスト上のディレクトリを明示的にコンテナへマウントする必要があります。

Use this test to distinguish a path problem from a permission problem

このテストを使って、パスの問題と権限の問題を切り分けます

次の順序で確認を実行してください。別の再帰的なchmodから始めないでください。

1. CasaOSホスト上で実際のパスを解決する

readlink -f "/DATA/Documents/Syncthing/SyncFiles" /DATAコマンドが「外部」のパスを返す場合

2. Syncthingコンテナが同じ対象を参照できるか確認する

docker exec syncthing ls -ld "/DATA/Documents/Syncthing/SyncFiles"

次に、コンテナ内に存在するはずの解決後の宛先をテストします。ホストでは一覧表示できるのにコンテナではできない場合、主な問題はまだ権限ではありません。そのパスがコンテナの名前空間に存在していないのです。

3. 実際のコンテナマウントを確認する

docker inspect syncthing

を確認してください マウント セクション。同期対象のドライブについて、ホスト側のソースとコンテナ側の宛先を特定できるはずです。

より適切な修正方法は、実際のドライブをバインドマウントし、そのコンテナパスを使用することです

外付けドライブが /DATAそれをSyncthingから直接参照できるようにし、シンボリックリンクの背後に隠さないでください。概念的には、composeのエントリは次のようになります。

volumes:
  - type: bind
    source: /real/host/path/to/external-drive
    target: /sync-drive

次に、Syncthingのフォルダーのパスを、たとえば次のように明示的に設定します。

/sync-drive/Dev Files

これは特別なパスではありません。composeの設定に合う宛先を選択してください。重要なのは、コンテナが実際のホストディレクトリをマウントされたボリュームとして受け取ることです。

上流のLinuxServer Syncthingイメージも同じモデルを使用しており、/path/to/data1:/data1や/path/to/data2:/data2のように、ホストからコンテナへのデータマッピングを個別に設定する方法を説明しています。また、そのSyncthingのPUID/PGIDマッピングでは、コンテナのIDをホストボリュームの所有権に合わせる方法も説明されています。

マウントが正しいことを確認してから、所有権と権限を修正してください

元のトラブルシューティングには、次のような提案が含まれていました。

sudo chmod -R 770 /path/to/folder

770 は一部の構成では適切ですが、Syncthingが実際にそのディレクトリを所有するユーザーまたはグループ、あるいはそのグループに属するユーザーとして実行されている場合にのみ効果があります。CasaOSアプリは PUID および PGID LinuxServerのイメージに取り込む。LinuxServerの公式ドキュメントでは、ホストボリュームの所有権を設定したPUID/PGIDに合わせる必要があると説明されています。

ユーザー名を推測するのではなく、IDを確認してください casaos で十分です：

docker exec syncthing id
stat -c '%u:%g %a %n' /real/host/path/to/external-drive

数値のUID/GIDが一致しない場合は、意図を明確にしたうえで所有権またはグループメンバーシップを変更してください。避けてください chmod -R 777; これでは本当の問題が隠れ、アクセス制御が弱くなります。

「file exists」エラーが実際に伝えていること

メッセージ：

mkdir /DATA/Documents/Syncthing/SyncFiles: file exists

最終的に 開発用ファイル ディレクトリが問題です。Syncthingはフォルダーのルートを準備している段階で失敗しています。親パスがシンボリックリンクであるか、コンテナ内で別の場所に解決される場合、アプリケーションは通常のディレクトリパスを想定していた場所で、ファイルシステムオブジェクトに遭遇することがあります。

したがって、最も迅速な診断方法は同じディレクトリを削除して再作成することではありません。次の項目を比較してください。

ホスト上で解決されるパス
コンテナ内から見えるパス
コンテナのバインドマウント
宛先の所有権に対する数値のPUID/PGID

クリーンな基準状態を確認するには、CasaOSのSyncthingセットアップで、複数ドライブ向けにカスタマイズする前の通常の同一パス同期フローを確認できます。代替のバックアップやファイル同期ツールを比較する際には、ZimaOSアプリプラットフォームが役立ちます。シンボリックリンクで複数の物理ドライブをつなぐのではなく、それらを統合することが最終目的なら、ZimaCube 2はストレージに重点を置いたハードウェアの選択肢です。

FAQ

所有者をrootからcasaosに変更して解決すべきですか？

それだけでは解決しません。所有権が重要になるのは、コンテナから実際の宛先パスを参照できるようになった後です。まずバインドマウントと数値のPUID/PGIDを確認してください。

別のドライブへのシンボリックリンクは失敗するのに、直接パスは機能するのはなぜですか？

ディレクトリにマウントされた直接パスは、両方のファイルシステムに存在します。一方、シンボリックリンクは、コンテナにマウントされていないホスト上の場所を指すことがあり、その場合、Syncthingはたどれないパスを参照することになります。

Syncthingは、同期対象ディレクトリへのシンボリックリンクをたどりますか？

いいえ。Syncthingのドキュメントには、シンボリックリンクは決して追跡されないと記載されています。Syncthingプロセスから見える実際のフォルダーのパスを使用してください。

最初に何を変更すべきですか？

シンボリックリンクを解決し、Syncthingコンテナのマウントを確認して、実際の外付けドライブのディレクトリをバインドマウントします。その後、PUID/PGIDと権限を確認してください。