Disk-usage tools can be misleading on a NAS because a directory may be either ordinary local storage or the place where another filesystem is mounted. This January 2026 thread began with a 1 TB ZimaOS drive showing roughly 915 GB used even though the user believed only about 450 GB of media existed. The first assumption was Docker cache. The command output instead pointed toward /DATA/.mediaバックアップとリモートストレージのマウントポイントが関係していたケースです。
Dockerを削除する前に容量を測定する
最初のコミュニティ回答では、最大のフォルダーを調べることが提案されました /DATA 最大のフォルダーを調べ、Docker独自の使用量も確認しました。これは妥当な対応でしたが、ユーザーの結果ではDockerツリーの下は約2.1 GB、AppDataは約2 GBしかありませんでした。
したがってDockerでは、数百GBに及ぶ不足分を説明できませんでした。
/DATA パーティションはほぼ満杯でした。最初のユーザーは、/DATA/.media/UNTITLED 2の下に424 GBあることを発見しました
サイズスキャンでは、通常のメディアが約419 GB、さらにその下に約424 GBあることが示されました /DATA/.media/UNTITLED 2. そのユーザーは、その名前が以前ZimaOSのバックアップ先として使っていたSSDのものだと認識しました。
混乱を招いたのは、物理バックアップドライブがすでに接続されていなかったことです。
マウントポイントが通常のローカルフォルダーになることがある
Linuxのマウントポイントはディレクトリです。USBドライブやSMB共有をマウントすると、そのディレクトリへのアクセスは外部ファイルシステムに到達します。外部ファイルシステムが切断された後もアプリケーションが同じディレクトリへの書き込みを続けると、その書き込みは下層にあるローカルファイルシステムに保存される可能性があります。
これにより、「バックアップ先は外部なのに、なぜシステムディスクがいっぱいになったのか」という典型的な障害が発生します。
マウントされているか確認するまで、.mediaディレクトリを削除しないでください
元のトラブルシューティングでは、マウント状態を確認した後に破壊的な削除コマンドを実行することが提案されていました。この順序が重要です。バックアップ先が実際にマウントされた状態でファイルを削除すると、ローカルの隠しデータを取り戻すどころか、実際の外部バックアップを消去する可能性があります。
削除コマンドはIceWhaleのサポート指示ではなくコミュニティの案内だったため、このページでは一般的なクリーンアップ手順として紹介していません。
停電後、別のユーザーが同じパターンを再現
スレッドの後半では、小容量のZimaOS-HDシステム／データパーティションを使用していた別のユーザーが、停電によってバックアップ処理が中断された後、残っていた空き容量をすべて失いました。そのユーザーの生データ du 出力が非常に大きく見えたのは、マウントされたRAIDとSMBデータも下位に含めてカウントされていたためです /DATA/.media.
ローカルデータとマウントを切り分けるため、同一ファイルシステムだけをスキャンする
コミュニティは次の方法を推奨しました du 同じファイルシステム上に限定するスキャンで、マウントされたネットワーク共有を除外します。2つ目のケースでは、これにより、内部のIP名ディレクトリ配下にある、実際にローカルに保存された約30GBのデータが明らかになりました。 /DATA/.media.
2人目のユーザーは30GBを取り戻した
IP名のディレクトリが実際のSMBマウントではないことを確認し、マウントポイントの配下に残されたローカルデータだと特定した後、ユーザーは不要な内容を削除し、30GBを取り戻したと報告しました。
これがスレッドで確認された中で最も確かな結果です。
コミュニティの見解は、保存先がアンマウントされた状態でバックアップが書き込まれたというものだった
回答者は、共有が正しくマウントされていないときに、バックアップ処理が想定されたSMBパスへの書き込みを続けたため、Linuxが代わりにローカルディレクトリへ書き込んだと考えました。
確認された30GBの復旧は、マウントポイント配下にローカルファイルが存在していたことを裏付けていますが、正確なバックアップ処理の競合については、このスレッド内のコミュニティによる推測であり、IceWhaleの技術者による投稿ではありません。
現在のZimaOSではバックアップとストレージの扱いが変わっている
現在のZimaOSでは、管理対象のバックアップタスクと、より広範なストレージ管理機能が文書化されています。新しいジョブには現在のZimaOSバックアップワークフローを使用し、大容量の書き込みを開始する前に、意図した保存先が実際にマウントされていることを確認してください。
より安全な容量不足の調査手順
- 使用
dfどのローカルファイルシステムが満杯なのかを確認するために。 - 同じファイルシステムだけをスキャンし、SMB、USB、RAIDのマウントによって合計容量が膨らまないようにします。
- DockerとAppDataは個別に確認してください。
- 調査
/DATA/.media実際のローカルファイルを含むマウントポイントディレクトリの場合。 - マウントポイント配下のものを削除する前に、対象がマウントされていないことを確認してください。
- クリーンアップ後、空き容量を確認し、バックアップ先を再度テストしてください。
最初のユーザーの424GBのケースは、後の30GBのケースより曖昧だった
投稿者は、接続解除されたバックアップ用SSDの名前が付いたディレクトリ内に約424GBあることを確認し、それが重複データだと考えました。その後、マウントの確認や削除案について議論が進みましたが、スレッドで最も明確に検証された復旧事例は、後のユーザーが30GBを取り戻したケースでした。
この違いが重要なのは、 /DATA/.media ライブマウント、古いマウントポイント、または実際のローカルファイルを表すことがあります。同じように見えるパスでも、すべてのシステムで同じ安全なクリーンアップ方法が使えるとは限りません。
dfとduは異なる問いに使い分ける
df 「実際にどのファイルシステムが満杯なのか」に答える一方で、 du 「どの見えているディレクトリにファイルが含まれているか」に答えます。ネストされたマウントがあるNASでは、2つのツールが食い違って見えることがあります。これは、 du 指示がなければ、他のファイルシステムまで対象にしてしまうことがあります。
ローカルのZimaOS-HDファイルシステムと、マウントされたSMBおよびRAIDの内容を切り分けてトラブルシューティングした後、スレッドの内容はようやく明確になりました。
予期しない電源喪失によりマウントポイントの問題がさらに危険になる
後の30 GBの事例は、バックアップの実行中に停電が発生した後に始まりました。起動後にリモート保存先が正しく再マウントされず、それでもバックアップジョブが再開または再起動された場合、そのパスは通常のローカルディレクトリとして存在し続ける可能性があります。
重要なバックアップジョブでは、古いパスが引き続き外部ターゲットを指していると決めつける前に、再起動や電源イベントの後で保存先がマウントされ、書き込み可能になっていることを確認してください。
Dockerのoverlay2を手動で削除して容量を取り戻さない
スレッドの初期には、ファイルシステムの出力でDockerのoverlayパスが目立って見えました。コミュニティは、任意のファイルを overlay2。Dockerのストレージレイヤーは、ランダムなレイヤーディレクトリを削除するのではなく、Dockerまたはアプリケーションのライフサイクルを通じて管理する必要があります。
現在のZimaOSではアプリのストレージ使用量も確認できる
現在のZimaOSのアプリ設定では、アプリケーションのストレージ使用量を確認でき、対応しているアプリではキャッシュを削除できます。ターミナルを開く前に、通常のアプリケーションの増加分とマウントポイント配下のデータを区別するのに役立ちます。
現在のZimaOSアプリケーションがデータとキャッシュを保存する場所についての説明は、ファイルシステムを安全に確認するための最初の手がかりになります。
容量不足に関するよくある質問
Dockerのoverlay2が、最初のユーザーで数百GBの容量が不足していた原因でしたか？
いいえ。投稿された出力では、Dockerが使用済み容量に占める割合はごくわずかでした。
なぜ、はるかに小さいローカルディスク上で、duがテラバイト単位の容量を報告することがあるのですか？
スキャンをローカルファイルシステムに限定しない限り、マウントされたリモートファイルシステムやRAIDファイルシステムを再帰的にカウントすることがあります。
回収は確認されましたか？
はい。後のユーザーは、SMBマウントポイントのディレクトリ下に保存されていたローカルデータから30 GBを回収しました。
