従来の Linux インストーラーが /app ディレクトリを要求するからといって、ZimaOS ホスト上に書き込み可能な /app ディレクトリを作成してはいけません。ZimaOS は設計上、ルートファイルシステムを読み取り専用にしています。Docker アプリケーションでは、ホスト側の永続ストレージを /DATA から、コンテナが必要とする書き込み可能なパスへマッピングしてください。
2026年1月のこのスレッドでは、ユーザーが変更可能な Debian／RPM 方式のシステムを前提としたホストインストーラーで ONLYOFFICE Workspace をインストールしようとしていました。このインストール方式は ZimaOS には適していませんでした。
アプリデータの保存先として / が不適切な理由
コミュニティからの回答では、ホストとコンテナのパスが正しく区別されています。Docker イメージはコンテナ内で /app を使用できますが、ホスト側に物理的な /app ディレクトリが存在する必要はありません。バインドマウントを使用すれば、ZimaOS 上の /DATA/AppData/onlyoffice のようなパスを、コンテナ内の /app にマッピングできます。
不変の ZimaOS ガイドでは、SSH／パッケージマネージャーの観点から、同じアプライアンス型の境界について説明しています。
プロジェクトが対応している場合は Docker Compose を使用する
その後、ユーザーは上流の Docker Compose プロジェクトを見つけました。これは ZimaOS ではより自然な方法です。Compose ファイルをインポートする前に、ホストのすべてのバインドマウント、ポート、環境変数、特権要件を確認してください。
Compose インポートガイドでは、現在の ZimaOS における Compose の動作と、よくあるバインドマウントのミスについて説明しています。
従来のホストインストーラーを ZimaOS に無理に適用しない
インストーラーがパッケージ、サービス、アプリケーションデータをホストのルートパス直下に直接書き込もうとする場合、そのインストーラーは不変の NAS OS と互換性がない可能性があります。ルートファイルシステムを再マウントして書き込み可能にしたり、従来の Linux の構成を手動で再現したりすると、アップグレードやシステム復旧の前提を壊すおそれがあります。
上流プロジェクトが保守されたコンテナースタックを提供している場合は、それを使用してください。従来の変更可能な Linux ホストにしか対応していない場合は、VM を互換性の境界として利用するほうが適切です。
ONLYOFFICE Workspace と DocumentServer は異なるデプロイメント
「Docker 上の ONLYOFFICE」といっても、すべての ONLYOFFICE 製品でボリューム構成が同じだとは考えないでください。Workspace には、スタンドアロンのドキュメントサーバーよりも多くのサービスと前提条件が含まれています。デプロイする製品に対応した上流の Compose 定義に従ってください。
ONLYOFFICE Docker リポジトリは、Debian や RPM システム向けに設計されたホストインストールスクリプトよりも信頼できる情報源です。
要点
ZimaOS のルートファイルシステムには手を加えないでください。永続データは /DATA 配下に保存し、アプリケーションが必要とするパスへコンテナ内でマッピングしてください。上流ソフトウェアが変更可能なホストを前提としている場合は、Compose または VM を使用します。問題は書き込み可能なルート機能がないことではなく、インストール方式の不一致です。
