現在の回答：まだ ZimaOS 1.7.0 を使用している場合は、これらの不具合を再診断する前に 1.7.1 へ更新してください
このスレッドでは多くの障害が一括して扱われていましたが、後にいくつかは個別に特定されました。アプリのアンインストールで AppData が削除される可能性、ファイル操作で異常に多くのメモリを消費する問題、Docker の起動や App Store の動作改善の必要性、そして同じリリース時期に発生した USB／RAID／バックアップ関連の問題などです。ZimaOS 1.7.1 は、セキュリティおよび安定性の修正リリースとして公開され、これらの問題のいくつかに直接対応しました。
ZimaOS 1.7.1 の変更点には、アプリ設定の削除に関する修正に加え、Docker と App Store の改善が含まれています。
1.7.0 で何かをアンインストールする前に AppData をバックアップする
元の事例で確認された最も重大な設計上の欠陥は、アプリを削除すると設定フォルダーまで削除されることでした。IceWhale はこの問題を再現し、後に 1.7.1 で修正しました。古い 1.7.0 のインストール環境を復旧している場合は、Plex などのサービスをアンインストールまたは再インストールする前に、重要な AppData とデータベースをコピーしてください。
ZimaOS のバックアップは、適切な安全策です。永続化パスを確認していない状態で、コンテナの再インストールが無害だと決めつけないでください。
可能な場合は、古いネイティブ sysext ではなく App Store の Tailscale を使用する
元のシステムではコミュニティ製のネイティブ Tailscale システム拡張を使用しており、サービスの起動時に /DATA の準備が完了していなかったため、早期起動時の競合が発生しました。これはコミュニティ製 sysext の設計に固有の問題であり、現在の ZimaOS 上の Tailscale が本質的に信頼できないことを示すものではありません。
現在の ZimaOS は、App Store で Tailscale を正式に提供しています。ZimaOS の Tailscale セットアップを使用すれば、カスタムの早期起動サービスを維持する必要がありません。Tailscale の要件では、アプリ側の情報を確認できます。
サーバーをリセットする前に、新しいアプリ体験を更新してキャッシュを検証する
「再起動後に古いアプリ体験が戻った」という症状は、後にブラウザーを更新すると解消しました。このことから、クライアント側のキャッシュや状態が原因だった可能性があります。UI の表示が古く見えるという理由だけでサービスを再インストールする前に、強制更新またはプライベートブラウザーウィンドウで確認してください。
誤ったアプリ更新には API の証拠が必要
システムには 6 件の更新が繰り返し表示され、その後更新一覧が消え、再び表示されて「更新を読み込み中…」で停止しました。UI のバッジだけでは 6 件の実際のイメージ更新が存在することを証明できないため、IceWhale は apps/upgradable のネットワークレスポンスを確認するよう依頼しました。
:latest のような可変 Docker タグを使用している場合、タグ名だけではローカルイメージが最新であることは確認できません。Docker のイメージの固定では、可変タグによって更新の比較が複雑になる理由が説明されています。
ディスク速度と Files アプリの速度を分けて考える
ユーザーは RAID に直接書き込むと約 196 MB/s を測定できた一方、Files アプリでは 6 GB のコピーに約 1 時間かかり、CPU 使用率も高くなりました。これは有益な証拠です。ディスク経路自体ははるかに高いスループットに対応できていたため、ボトルネックは物理 RAID よりもファイルサービスまたは UI 操作にある可能性が高くなります。
dd if=/dev/zero of=/media/STORAGE/test.img bs=1M count=2000 status=progress conv=fdatasyncZimaOS 1.7.1 では、特定のファイル操作における異常なメモリ使用量が修正されましたが、すべての Files のコピー性能問題が解決したとは考えないでください。1.7.1 で同じ負荷を再テストしてください。
実際に壊れているアプリだけを再インストールする
Plex は最終的に、再インストールして AppData を復元することで動作しました。より広範なアプリ UI の問題が解消すると、Pi-hole のタイル表示も正常に戻り、Uptime Kuma のチェックにはブリッジの再作成が必要でした。これらは別々の問題です。1 つの問題を再インストールで解決できたからといって、すべてのコンテナを再インストールする理由にはなりません。
ZimaOS アプリの要件を確認すると、各アプリの依存関係を明確に管理できます。
診断の分岐ごとに問題を 1 つに分ける
1.7.x の有用なトラブルシューティング記録では、Tailscale の起動、App Store の UI、個々のコンテナの起動、更新検出、Files の性能、USB の自動マウント、AppData の動作を分けて扱う必要があります。それぞれについて再現手順と証拠を記録してください。「1.7 ですべてが壊れた」という報告は感情的には理解できますが、体系的に修正するのは困難です。
復旧にかかるコストが分かるまでダウングレードしない
1.7.1 にはファイルサービスのセキュリティ修正が含まれているため、1.7.0 を長期的な回避策として使い続けるのは適切ではありません。バックアップを取り、1.7.1 に更新して各問題を再テストしてください。そのうえで、特定のリグレッションが再現する場合に限り、ロールバックまたは再インストールを検討してください。
よくある質問
ZimaOS 1.7.1 で AppData の削除は修正されましたか？
アプリをアンインストールするとアプリ設定フォルダーが削除される可能性がある問題が修正されました。
ZimaOS で、消えるアプリ更新が表示されるのはなぜですか？
バッジには、アプリ管理のメタデータや可変イメージタグが反映されることがあります。すべてのバッジが実際の更新だと判断する前に、アップグレード可能 API のレスポンスと実際のイメージ状態を取得してください。
Tailscale sysext を使い続けるべきですか？
コミュニティ製のネイティブ拡張を特に必要とし、維持管理できる場合を除き、現在の App Store 版 Tailscale を使用してください。
RAID のベンチマークは速いのに、Files が遅いのはなぜですか？
これは物理ディスクと、より上位のファイルサービスを切り分けるものです。同じ負荷を CLI、SMB、Files 経由で比較し、どの層が遅いのかを特定してください。
1.7.0 からダウングレードすべきですか？
現在の 1.7.1 には重要なセキュリティおよび安定性の修正が含まれています。まずバックアップを取り、更新してから、再現可能なリグレッションが残っているかを評価してください。
