コミュニティソリューション

ZimaOSアプリがメインストレージに書き込めない:フォルダーの所有権とアプリ固有の権限を分離

A January 2026 thread where a first community reply blamed general ZimaOS storage ownership and suggested recreating folders in Files. The original poster disproved that as a universal fix with SFTPGo and Navidrome, leading the responder to revise the diagnosis to application-specific permission and feature behavior.

このスレッドは、「アプリがRAIDに書き込めない」という問題を、すぐにZimaOSの権限バグだと判断すべきではない理由を示しています。最初のコミュニティ返信では、App Storeのコンテナは通常、独自のAppData以外には読み取り専用でアクセスし、Filesを使ってフォルダーを作成または「操作」しない限り書き込めないと説明されていました。投稿者はその方法を実際に試しましたが、それでもSFTPGoのフォルダーを作成できず、Navidromeから音楽を削除することもできませんでした。

こうした反例を受けて、回答者は説明を改めました。ファイルシステムの所有権は、あくまで1つの層にすぎません。各アプリには、独自のコンテナユーザー、想定される内部パス、そして機能上の制限もあります。後から修正されたこの説明こそが、より信頼できる教訓です。

権限には3つの異なる層があります

  • ZimaOSのホストストレージ: 実際のRAIDまたはディスク上のフォルダーと、その所有者およびモード。
  • Dockerボリュームのマッピング: ホストフォルダーがコンテナ内にマウントされているか、またマウントが読み取り専用かどうか。
  • アプリケーションの動作: アプリがどのユーザーで実行されるか、そしてソフトウェア自体がファイルの作成、削除、名前変更に対応しているかどうか。

どの層で失敗しても、「権限が拒否されました」と表示されることがあります。

Filesでフォルダーを作成しても、万能な解決策にはなりません

最初の提案は、所有権が正しく適用されるよう、ZimaOS Filesを使って対象フォルダーを作成または移動することでした。投稿者はRAID上にsrv/dataを作成してSFTPGoに指定しましたが、それでも権限拒否のエラーが表示されました。

したがって、Filesを使う方法をすべてのアプリに対する確実な解決策として説明することはできません。

SFTPGoには、実行ユーザーと設定に合った書き込み可能なパスが必要です

SFTPGoは独自の権限と、仮想フォルダーおよびホームディレクトリーのルールに従って動作します。ホスト上にディレクトリーが存在して表示されていても、SFTPGoのプロセスからは書き込めない場合があります。

現在の環境で確認する際は、ホストフォルダー、Dockerのマウントモード、コンテナのUID/GID、そしてSFTPGoユーザーに設定されたホームディレクトリーまたは仮想フォルダーを、まとめて確認してください。

元の回答者は、ライブラリ管理においてNavidromeは読み取り専用として扱うべきであり、その環境ではNavidrome内から楽曲を削除する機能はサポートされていないと説明しました。したがって、曲を削除できなかったことは、RAIDの権限が全般的に壊れていることを示す十分な証拠ではありません。

特定の現行Navidromeバージョンでファイル変更機能がサポートされていると明記されていない限り、元の音楽ファイルはFilesなど別のファイル管理ツールで管理してください。

Dockerボリュームが読み取り専用でマウントされていないか確認する

ボリュームのマッピングでは、読み取り専用モードが明示的に指定されている場合があります。アプリがファイルを変更する必要がある場合、ホストフォルダーは読み書き可能としてマッピングされ、プロセスの実行ユーザーにはホストのファイルシステム上での書き込み権限が必要です。

現在のZimaOSでは、アプリケーション設定からアプリのボリュームマッピングを確認および編集できます。

現在のZimaOSでは、ホストパスとコンテナパスの関係がより明確になっています

IceWhaleは現在、/config/mediaなどのアプリ側のパスと、それらを実際に支えているストレージフォルダーとの関係を文書化しています。

ファイルシステムの権限に対する最初の対応として再帰的なchmod/chownを実行する前に、現在のZimaOSのアプリパスモデルを確認してください。

診断の近道としてchmod 777を使わないでください

広範囲に書き込み権限を与えると、本当の問題が隠れてしまい、無関係なプロセスから共有データにアクセスされるおそれがあります。また、アプリが意図的にボリュームを読み取り専用で開いている場合や、独自の設定によってパスへのアクセスを拒否している場合にも、問題は解決しません。

アプリに必要な最小限の所有権またはグループ権限だけを変更してください。

より適切な診断手順

  1. ZimaOS上の正確なホストフォルダーを確認します。
  2. アプリのボリュームが、そのフォルダーを想定されるコンテナパスにマッピングしていることを確認します。
  3. マッピングが読み取り専用になっていないか確認します。
  4. コンテナがどのUID/GIDまたはユーザーで実行されているかを確認します。
  5. そのユーザーがホストフォルダーに書き込めることを確認します。
  6. アプリケーション自体が、実行しようとしている操作に対応していることを確認します。

アプリストレージの権限に関するよくある質問

ZimaOS Filesでフォルダーを作り直せば、元のSFTPGoの問題は解決しましたか?

いいえ。投稿者はその方法を試しましたが、それでも権限拒否が表示されました。

読み取り可能なRAIDフォルダーは、自動的にすべてのアプリ内で書き込み可能になりますか?

いいえ。Dockerのマウントモード、コンテナのUID/GID、アプリケーションの動作も影響します。

Navidromeを汎用ファイルマネージャーとして使うべきですか?

いいえ。現在のアプリケーションがファイル変更を明示的にサポートしていない限り、音楽ソースはNavidromeの外部で管理してください。