ZimaOSのFilesでError Loadingと表示されても、WindowsからSMBアクセスが引き続き機能している場合は、RAIDやデータが消失したとすぐに判断しないでください。これは2026年2月のスレッドで見られたパターンです。1.5.4へのアップデート後にFilesのUIが機能しなくなった一方で、他のアプリやSambaによるファイルアクセスは引き続き正常に動作していました。
その後、IceWhaleのスタッフが最も重要な根本原因の範囲を示しました。raller1028氏によると、ZimaOS 1.5.4では、システムディスクがいっぱいになるとFilesサービスが正常に動作しなくなることがあります。公式の復旧方法は、システムディスクの空き容量を確保し、icewhale-filesを再起動することでした。コミュニティで共有された別のデータベース名変更による回避策で複数のユーザーが復旧しましたが、IceWhaleはこれを第一選択の修正方法として案内していません。
SMBが機能しているなら、データとマウントが残っている有力な証拠
元の投稿者は、WindowsのSamba共有を通じて引き続きファイルにアクセスできました。これは、FilesのWebアプリケーションがファイルを表示できなくても、ホストのストレージとデータパスは正常に機能していたことを意味します。
これは、次の問題を区別するうえで重要です。
- ストレージやデータの消失;
- Filesサービスの障害;
- ブラウザーやUIの障害。
Filesは通常のApp Store Dockerコンテナではない
そのため、docker psにFilesコンテナが表示されないのは想定どおりです。無関係なDockerコンテナを再起動しても、ネイティブのFilesサービスは修復できません。
IceWhaleは、システムストレージの容量不足を1.5.4の発生要因として特定した
2月26日、IceWhaleのraller1028氏は、この問題はバージョン1.5.4でシステムディスクがいっぱいになったことが原因である「可能性が高い」と説明しました。
公式の復旧手順は次のとおりです。
- コマンドラインからシステムディスクの空き容量を確保する;
- Filesサービスを再起動する:
systemctl restart icewhale-filesコマンドラインでのクリーンアップに不慣れなユーザーには、ファイルを無闇に削除せず、サポートに連絡するよう案内されました。
システムディスクがいっぱいでも、なぜSMBは機能するのか
ネイティブサービスは、データベース、状態情報、一時ファイル、ログ、サービス処理のために作業用の空き容量を必要とします。別のストレージアレイ上にある大容量のユーザーデータは無傷のままでも、小容量のシステムパーティションが使用率100%に達すると、特定のサービスだけが障害を起こすことがあります。
そのため、「RAIDには空き容量がある」ことだけを確認しても十分ではありません。
増え続けるアプリデータをシステムドライブから移動する
現在のZimaOSドキュメントでは、Dockerのデータベース、サムネイル、キャッシュによってシステムディスクがいっぱいにならないよう、アプリケーションデータをシステムドライブではなく実際のストレージ領域に移動することを推奨しています。
別の原因によるシステムドライブの圧迫を防ぐには、現在のZimaOSアプリストレージガイドを利用してください。
コミュニティのfiles.db名変更で複数のユーザーが復旧した
後日、コミュニティのユーザーが次の手順を投稿しました。
mv /var/lib/casaos_data/.casaos/files.db /var/lib/casaos_data/.casaos/files.db.bak
systemctl restart icewhale-files複数の参加者が、これでFilesが復旧したと返信しました。
ただし、これはコミュニティによる二次的な復旧方法として扱うべきです。IceWhaleのスタッフはすぐに、Filesデータベースを削除することの意味を尋ねており、公式の「システムの空き容量を確保してサービスを再起動する」という案内をこのコマンドに置き換えてはいません。
データベース名の変更は削除より安全だが、アプリケーションの状態は変わる
コミュニティのコマンドは、データベースを消去せず、.bakのコピーを残します。これはロールバックの点では優れていますが、Filesデータベースを再構築すると、インデックス化されたメタデータやその他のサービス状態が変わる可能性があります。
システムディスクが単にいっぱいになっている場合は、最初の対応として実行しないでください。
現在のZimaOSでも1.5.4のバグが続いているとは限らない
現在のZimaOSは1.7.xで、Files、ストレージ、メモリ、セキュリティ、アプリストレージに関する修正が継続的に提供されています。この過去の問題が役立つのは、サービス障害とデータ消失を区別する方法を学べるからであり、現在発生するすべてのFilesエラーが同じ原因だからではありません。
現在この問題が再発した場合は、まずシステムの現在の空き容量、バージョン、サービスの状態、そしてSMBやその他のファイルアクセスが引き続き機能しているかを確認してください。
空き容量は慎重に確保する
不明なシステムディレクトリに対して、範囲の広いクリーンアップスクリプトを実行しないでください。容量の大きいアプリキャッシュ、Dockerデータ、バックアップ、ログを特定し、可能な場合は現在のZimaOSのクリーンアップ機能や移行機能を使用してください。
Filesの「Error Loading」に関するFAQ
元のケースではSMBは機能していましたか?
はい。これは、データとマウントが残っていることを強く示していました。
IceWhaleのスタッフは、1.5.4の問題を何だと説明しましたか?
システムディスクがいっぱいになり、Filesサービスが正常に動作しなくなる問題です。
公式のサービス再起動コマンドは何ですか?
systemctl restart icewhale-filesです。
files.dbの名前変更は公式の第一選択の案内でしたか?
いいえ。これは複数のユーザーが有効だと確認したコミュニティの回避策です。IceWhaleが第一選択として案内したのは、空き容量を確保してFilesサービスを再起動する方法でした。
