Syncthing ではフォルダーが同期済みと表示されるのに、ファイルが Docker の overlay2 内に現れる場合、保存先のパスが実際にはコンテナへマウントされていません。 これが、2025年6月のこのスレッドにおける重要な技術的手がかりです。docker inspect に期待された FileDrop のバインドマウントがなかったため、Syncthing は使い捨てのコンテナファイルシステム内に書き込んでいました。
このスレッドは元の ZimaOS インストール上では解決されず、ユーザーは最終的に Debian/CasaOS へ移行しました。そのため、記事では元の構成が修復されたかのように扱わず、この診断内容を使用してください。
UI のマッピングと実行中のコンテナが一致していなかった
ユーザーの ZimaOS アプリフォームには FileDrop のマッピングが表示されていました。しかし、docker inspect big-bear-syncthing にはそのマウントが表示されませんでした。この不一致により、Syncthing は独自の書き込み可能なコンテナレイヤー内に /FileDrop を作成したのです。
永続的な同期データにとって overlay2 は警告サイン
.docker/overlay2/.../diff/FileDrop 内のファイルは、コンテナのファイルシステム内にあります。コンテナを再作成または置き換えると、そのレイヤーが削除される可能性があります。同期したデータは、永続的なバインドマウントまたは名前付きボリュームに保存してください。
現在のZimaOS Syncthing ガイドでは、フォルダーのパス、PUID、PGID を含む、サポート対象のセットアップ手順が説明されています。
/DATA と /media/ZimaOS-HD は同じストレージルートだった
/media/ZimaOS-HD と /DATA が同じ ZimaOS ストレージルートを参照していることを示しました。 出典：IceWhale Community Forum。IceWhale は、そのシステムでは /media/ZimaOS-HD が /DATA を指していると説明しました。したがって、パスのエイリアス自体が、ファイルが overlay2 に保存された主な原因ではありません。
本当に確認すべきなのは、正確なホストフォルダーが、想定されるコンテナ側のターゲットとともに、コンテナの Mounts リストに表示されているかどうかです。
現在の Syncthing フォルダーのルールを使用する
現在の公式ガイドでは、専用の Syncthing フォルダーのパスを使用し、正しい PUID/PGID の値を設定し、このワークフローでは ZimaOS のファイルブラウザーから手動で作成するのではなく、Syncthing を通じて保存先フォルダーのパスを作成することを推奨しています。
Syncthing デプロイガイドでは、より広範なストレージ構成の背景を説明しています。
要点
同期したファイルが Docker の overlay2 に保存される場合は、Syncthing のピア接続のデバッグを中断し、コンテナのマウントを確認してください。保存先のホストフォルダーが実際にマウントされていることを確認し、Syncthing ではコンテナ側のパスを使用します。また、PUID/PGID を書き込み可能なホスト側の所有権に合わせ、保存された UI 定義と実行中のコンテナが一致しない場合は、アプリを再作成してください。
