元のユーザーはスマートフォンの写真同期でSyncthingを動作させていましたが、ファイルはストレージ ディスクではなくシステム ドライブに保存され続けていました。FilesアプリからパスをコピーしてSyncthingに直接貼り付けたことで、Syncthingは同じように見えるディレクトリ ツリーを自身のコンテナ ファイルシステム内に再作成しました。
最終的な解決策は、魔法のようなファイルシステム コマンドではなく概念的なものでした。Dockerにはホスト側のパスとコンテナ側のパスがあります。Syncthingでは、CasaOSまたはZimaOSから見える生のパスではなく、コンテナ内から見えるパスを使用する必要があります。
外部パスが間違った場所に再作成されていた理由
Syncthingに実際には認識できないパスを指定すると、そのパスが自身の書き込み可能なファイルシステム内、またはマッピングされた設定場所内に作成される場合があります。元のユーザーはフォルダー名を外付けディスクのパスとして解釈しましたが、コンテナはそれを自身のファイルシステムからの相対パスとして解釈しました。
実際のホスト マウント ポイントを確認する
コミュニティでは lsblk 外付けドライブがオペレーティング システムによってどこにマウントされたかを特定するために使用しました。回答者の例では、ドライブは次のようなパスに表示されました。 /media/devmon/...元の投稿者のドライブは後に /mnt/Storage1 および /mnt/Storage2.
これらの正確な過去のマウント パスはCasaOS/ZimaBladeの例であり、現在のZimaOSで普遍的に使えるパスと見なすべきではありません。
ホスト ドライブをSyncthingにマッピングする
回答者は /DATA Syncthing側のパスとして指定します。このマッピングが存在すれば、Syncthingはその配下のフォルダーを参照します。 /DATA 元のホストのマウント パスではなく、
ユーザーは最初、Syncthing内にホスト側のパスを入力した
その後Syncthingは、その内部パスがマッピングされたボリュームに対応していなかったため、権限またはパスのエラーを返しました。
最終的に動作したパスは/DATA/Documentsだった
回答者は、ホストのドライブを /DATAを、Syncthingでは次のように指定します。
/DATA/Documentsまたは同等のパス ~/Documents Syncthingのホームがそのマッピングされたデータの場所を指している場合の省略表現です。
元の投稿者は翌日に戻り、成功したことを確認しました。
再帰的なchownはコミュニティの手順の一部であり、根本的な修正ではない
このスレッドでは再帰的な chown 外付けドライブ上で。Linuxが所有するファイルシステムでは適切な場合がありますが、ターゲット全体の所有権が変更されるため、IceWhaleが作成した要件ではありません。
既存の共有ディスクに対して再帰的な所有者変更を行う前に、その権限に依存しているユーザーやアプリケーションを把握してください。
現在のZimaOSではアプリストレージのマッピングが容易になっている
現在のZimaOSでは、アプリケーション設定にホストとコンテナのパスが直接記載されており、アプリデータを管理ストレージに設定して、アプリケーションがシステムドライブを使い果たさないよう推奨しています。
Syncthingストレージの設定では、古いCasaOSのマウント場所に頼るのではなく、現在のZimaOSのDockerボリューム用アプリパスモデルを使用してください。
元のユーザーはSyncthingを再インストールし、マッピングを再構築した
最初の試行後も混乱が続いたため、投稿者はSyncthingを新規インストールし、ストレージドライブを再追加して、マッピングを設定しました /mnt/Storage1 ホスト上の から /DATA コンテナ内。今回のクリーンな再テストにより、古いコンテナ設定が原因の切り分けから除外されました。
ホスト側の権限だけでは、誤ったコンテナパスを機能させられなかった
ユーザーはストレージドライブにSSH接続してディレクトリを作成できましたが、Syncthingに次のパスを使用させようとすると失敗しました /mnt/Storage1/Documents 内部で。これは重要な失敗結果です。ホストユーザーとして書き込みできても、コンテナから同じ名前空間を参照できるとは限りません。
権限を調整して問題を解決するには、まずコンテナから正しく参照できる状態にする必要があります。
現在のZimaOSでは、管理ストレージパスを優先する
このスレッドは、CasaOS形式のストレージパスで出荷されたZimaBladeに関するものです。現在のZimaOSでは、管理ストレージの動作が異なり、アプリケーションボリューム用のインターフェースも明確になっています。現在のサーバーでは、パスを推測せず、ZimaOSで選択したストレージパスを使用してください /mnt/Storage1 または /media/devmon 存在します。
アプリに実際に必要な権限だけを変更する
Syncthingは通常、同期フォルダーへの読み取りおよび書き込みアクセスを必要とします。マッピングされたフォルダーが表示されても書き込みできない場合は、その特定のフォルダーの所有者とグループ権限を確認してください。他のサービスがそのドライブを使用している場合は、それらへの影響をすべて確認するまで、用途が複数あるドライブ全体に対して再帰的な所有者変更を行わないでください。
Syncthing外付けHDDに関するFAQ
なぜSyncthingは外付けドライブのパスをシステムディスク内に作成したのですか？
ホストのパスは、Syncthingがコンテナ内から参照できるパスではありませんでした。
ドライブを /DATA にマッピングした後、機能したパスは何でしたか？
元のユーザーが確認しました /DATA/Documents 機能しました。
再帰的なchownだけが解決策でしたか？
いいえ。決め手となった理解は、ホストのパスとコンテナのパスの違いでした。
