ZimaOSアプリストアの設定フォームでパスがバインドされない問題の修正

ZimaOSのApp Storeが設定フォームをスキップし、バインドパス不足で失敗する：2025年のスレッドが証明したこと

A November 2025 thread where App Store installs skipped the settings/configuration form and failed with Docker bind-source-path-does-not-exist errors. Community replies first blamed stale AppData, but the original poster later said deleting AppData no longer helped and even first-time app installs were affected, while YAML installations still worked. The thread ended without an IceWhale-confirmed root cause.

この問題は当初、古いAppDataが残っていることが原因だと考えるのが妥当に思われました。しかし、最後の投稿を見ると、その説明だけでは不十分です。以前削除したアプリがセットアップフォームを表示せず、存在しないバインドパスを再利用しようとしたため、bind source path does not existのようなDockerエラーが発生していました。コミュニティからは、古いAppDataフォルダーを削除または名前変更して、ZimaOSにアプリを新規インストールとして扱わせる方法が提案されました。

投稿者はその方法が一度は有効だったものの、後には役に立たなくなったと報告しました。さらに重要なのは、初回インストールの新しいアプリでも設定フォームが表示されず、100%で停止するようになった一方で、YAML経由のインストールは引き続き機能していたことです。このことから、最も疑わしい原因は特定のアプリディレクトリではなく、App Storeの従来のUI・設定処理そのものへと移ります。

Dockerエラーは実際に発生していたが、根本原因ではなかった

表示されたエラーは次のようなものでした。

Error response from daemon:
invalid mount config for type "bind":
bind source path does not exist: [EXPECTED PATH]

Dockerは、ホスト側のソースディレクトリが存在しないバインドマウントを正しく拒否していました。問題は、通常ならユーザーがパスを選択または作成できる設定フォームを表示するはずのApp Storeが、なぜそのパスを生成または再利用したのかという点です。

古いAppDataはコミュニティによる仮説だった

gelbuildingは、/DATA/AppData/<app-name>を削除または名前変更して、ストアに新規インストールとして扱わせることを提案しました。別のコミュニティメンバーも、同じ方法を使ったと述べています。

これはIceWhaleスタッフによる診断ではなく、その後の投稿者の検証からも、より広範な問題には十分でないことが示されました。

初回インストールのアプリでもフォームが表示されないことで、診断は変わる

過去のローカルAppDataが存在しない新しいアプリでも設定がスキップされるなら、古いフォルダーを繰り返し削除するのは適切なトラブルシューティングではありません。ユーザーは、再起動、フォルダー削除、再インストールを行っても同じ状況になったと明確に述べています。

YAMLインストールが機能したことは重要な証拠だった

ユーザーによると、アプリはYAMLから引き続きインストールできました。これはDocker自体が完全に壊れていたわけではないことを示しており、当時の問題がストアのアプリ定義・設定・表示処理に関連していた可能性を高めます。

ZimaOS 1.7でApp Storeのアーキテクチャが刷新された

ZimaOS 1.7.0では、再設計された検索・管理UIと、YAMLのネイティブ編集・解析機能を備えたApp Store 2.0が導入されました。その後、ZimaOS 1.7.1ではDocker、AppData、WebUI、YAMLに関する追加の修正が行われました。

現在のApp Store 2.0の基準を参照してください。

現在の切り分け手順

現在の安定版ZimaOSに更新する。
これまで一度もインストールしたことのない、公式またはシンプルなアプリを1つテストする。
見つからないホスト側バインドパスを正確に記録する。
そのフォルダーが存在するか、どのストレージに属しているかを確認する。
同じ目的のパスを指定して、YAMLインストールが成功するか確認する。
設定フォームに問題が残る場合は、App Storeとコンテナのログを収集する。

状態を保持するアプリのAppDataを不用意に削除しない

AppDataフォルダーには、データベース、設定、鍵、ライブラリ、ユーザー状態などが含まれている場合があります。テスト中は削除よりも名前変更のほうが安全であり、重要なデータは事前にバックアップしてください。

設定フォームが表示されない場合のFAQ

古いAppDataを削除すれば、元の問題は恒久的に解決しましたか？

いいえ。投稿者は、一度は効果があったものの、その後は機能しなくなったと述べています。

初回インストールのアプリも影響を受けましたか？

はい。最後の投稿では、新しいアプリでも設定フォームが表示されず、インストールが停止したと説明されています。

YAMLインストールは引き続き機能しましたか？

はい。これは、当時の問題がDocker自体の完全な停止ではなく、App Store経由の処理に関連していたことを示す最も有力な手がかりの1つでした。