この資料は、苛立たしい権限問題から始まり、最終的に再現可能な解決策へと発展しました。SyncthingはWindows側のピアと通信でき、デフォルトのAppDataの場所には同期できましたが、マウントされたNASパス（たとえば /media/raid/NAS/Music が発生しました 権限が拒否されました および フォルダーパスがありません エラー。
2025年8月、あるコミュニティユーザーが、自分にとって有効だった方法を投稿しました。Syncthingをカスタムインストールで再インストールし、実際のZimaOSユーザーのPUID／PGIDを使用し、適切な同期ルートを選択して、Syncthingに独自の同期先フォルダーを作成させるという方法です。その後、別の2人のユーザーがこの方法で動作したことを明確に確認しました。IceWhaleの現在の公式Syncthingガイドでも、基本的に同じ設定が説明されています。
元のSyncthingはデフォルトのAppDataパスにしか書き込めなかった
ソースユーザーには次の内容を入力できました。
/DATA/AppData/syncthing/config/Syncしかし、Files、Jellyfin、Navidromeからはアクセスできたにもかかわらず、目的のハードドライブ上の音楽パスを使用できませんでした。これは、ディスクの障害ではなく、コンテナのIDまたは権限の不一致であることを強く示しています。
rootとしてSyncthingを実行する方法が提案されましたが、現在推奨されている解決策ではありません
初期のコミュニティ回答では、PUID／GUID 0が提案されていました。ファイル同期サービスをrootとして実行すると、多くの権限問題を回避できますが、コンテナに必要以上に広範な書き込み・削除権限を与えることにもなります。
現在のIceWhaleのガイダンスでは、代わりに実際のユーザーのIDを使用するよう明確に推奨しています。
カスタムインストールを使用する
実際のZimaOSユーザーのPUIDとPGIDを確認する
現在の公式ガイダンスでは、次を使用します。
id -u username
id -g username置き換え ユーザー名 同期ファイルの所有・管理者となるZimaOSアカウントで実行し、返された数値IDをSyncthingの環境変数にコピーします。
マウントされたディスクのルートをSyncthingフォルダーとして使用しない
IceWhaleの現在のドキュメントでは、マウントされたディスクのルートや、Gallery／Media／DocumentsなどのシステムフォルダーをSyncthingのフォルダーパスとして直接使用しないよう説明しています。通常、これにはルートレベルの権限が必要になるためです。
代わりに、適切な専用サブフォルダーを作成または使用してください。
Syncthingに同期先フォルダーを作成させる
コミュニティの解決策では、ZimaOSのファイルブラウザーから同期先を事前に作成しないよう、ユーザーに明確に注意していました。現在の公式ドキュメントでも同じベストプラクティスが繰り返し示されています。同期先はSyncthingで定義し、Syncthingに作成させてください。
このコミュニティによる修正は、現在の公式ZimaOSドキュメントに反映されています。
現在のZimaOS Syncthingセットアップを使用してください。
誤ったIDでは再インストールが必要になる場合がある理由
最初のインストールで誤ったIDの下に設定やフォルダーが作成された場合、後から1つの値を変更するだけでは、以前の所有権が残ることがあります。そのため現在の案内では、インストール前にPUID/PGIDを慎重に確認するよう求めています。
クリーンな再インストールのためにAppDataを削除する前に、重要なデバイスやフォルダーの関係が含まれている場合はSyncthingの設定をバックアップしてください。
まずは小さな使い捨てフォルダーでテストする
大容量の音楽ツリーやドキュメントツリーを指定する前に、小さなテストフォルダーを同期し、有効にした場合は双方向の動作を確認し、NAS上の所有権を確認してから、本番フォルダーを追加してください。
すべての権限レイヤーが一致したため修正が機能する
Syncthingが正常にファイルを作成するには、4つの条件が一致している必要があります。ZimaOSホスト上のフォルダーが存在し、意図したユーザーまたはグループによる書き込みが可能であること、Dockerがそのホストフォルダーをコンテナ内にマッピングしていること、Syncthingが一致するPUID/PGIDで実行されていること、そしてSyncthing内で設定したフォルダーパスがコンテナ側のマウント先を指していることです。いずれか1つでも不一致があると、同じ「permission denied」という症状に見えることがあります。
マウントしたディスクのルートを同期先にするのが推奨されない理由
マウントしたディスクのルートには、システム管理用ディレクトリ、共有メタデータ、または複数のサービスで使用するための権限が含まれていることがよくあります。同期エンジンにそこへの広範な書き込み権限を与えると、誤削除や設定ミスの影響範囲が広がります。専用のサブフォルダーを使えば、所有権やバックアップポリシーをはるかに簡単に管理できます。
双方向同期を有効にする前にSyncthingの削除動作を確認する
Syncthingは、フォルダーのモードに従って変更を反映します。送受信設定では削除も反映されます。大容量の音楽ライブラリやドキュメントライブラリを指定する前に、使い捨てファイルで作成・名前変更・削除の動作をテストし、誤ったリモート削除からの復旧が重要な場合はSyncthingのバージョン管理を検討してください。
ZimaOS上のSyncthing FAQ
後のユーザーは、PUID/PGIDの方法が機能したことを確認しましたか？
はい。少なくとも後の2人の情報提供者が、投稿された方法で問題が解決したと明確に述べています。
ディスクにアクセスするために、Syncthingをrootとして実行すべきですか？
現在のIceWhaleの案内では、実際のZimaOSユーザーのPUID/PGIDと、適切なサブフォルダーを使用することを推奨しています。
先にZimaOSの「ファイル」で保存先フォルダーを作成すべきですか？
現在のIceWhaleドキュメントでは、Syncthingに保存先フォルダー自体を作成させるよう案内しています。
