科技 · 實用指南
Docker 顯示「裝置沒有剩餘空間」，但 df 仍有餘量？先查真正的儲存路徑
Docker 可能寫入另一個掛載點、耗盡 inode，或塞滿特定 Buildx 建置器。清理或搬移前先對應實際檔案系統。
主機整體 df 看起來健康，不代表接收 Docker 寫入的檔案系統仍有容量。失敗的拉取、建置或容器可能位於不同掛載點，也可能是 inode 耗盡或另一個 Buildx 建置器的快取。
先保留完整命令與錯誤，再確認目前守護程式、實際儲存路徑與所選建置器。逐一路徑對應檔案系統，證據一致後才清理。
保留失敗操作並確認上下文
記錄 ENOSPC 出現在 pull、建置、啟動、應用程式寫入或日誌，並保存錯誤中的完整路徑。不同操作可能有不同儲存擁有者。 清理拉取快取不一定修復綁定掛載的應用目錄；容器可寫層也不同於它能存取的每個主機路徑。
以 docker context show、docker info 與 docker buildx ls 確認實際守護程式、Docker Root Dir、驅動與建置器。遠端上下文或 Docker Desktop 不可直接套用本機路徑。 遇到這些情況先停止套用本機假設，使用該守護程式文件描述的儲存視圖。
把真正路徑對應到檔案系統
對每個路徑使用 findmnt --target PATH --output SOURCE,FSTYPE,SIZE,USED,AVAIL,USE%,TARGET。Engine 29 另需檢查 /var/lib/containerd。 這項額外檢查限於使用 containerd 映像儲存的全新安裝；Docker 文件明確說明 data-root 不搬移該映像與快照存放區。
不要從路徑名稱猜測掛載點；子目錄可能位於獨立磁碟區或網路檔案系統。綁定掛載或應用程式目錄也要單獨對應。 保存來源與掛載目標，讓後續清理前後量測指向同一檔案系統。
分開檢查區塊與 inode
執行 df -h PATH 與 df -i PATH。剩餘位元組很多時仍可能沒有 inode；inode 足夠也無法補償區塊耗盡。配額、唯讀與 I/O 錯誤應另行診斷。 保留空間亦屬獨立分支；僅憑 ENOSPC 不能證明 Docker 物件就是原因。
位元組滿時找出最大擁有者；inode 滿時量測檔案數量。未先確認與 Docker、containerd、建置器、綁定掛載或日誌的關係，不要刪除陌生目錄。 找最大占用時不要意外跨入無關掛載點，並保留所有帶狀態的資料。
Prune 前確認物件歸屬
用 docker system df -v 查看守護程式物件；對失敗建置使用的建置器執行 docker buildx du --builder NAME，辨識可回收、共享、可變與使用中記錄。 Docker 說明使用中記錄即使指定 --all 也不會刪除；共享或可變標記也不是可無條件刪除的證明。
先刪除已確認無用的單一物件或指定快取。system prune 範圍較大；Volume 需明確選項，執行前要檢查 Compose、命名卷、備份與回復需求。 優先考慮已確認停止的容器、未使用映像或限定建置快取；卷可能含持久資料，無引用狀態不代替備份判斷。
只搬移已證實已滿的儲存
容量確實不足時，安排維護窗口，停止寫入並保存設定與備份；依實際守護程式或 containerd 文件搬移。只改 data-root 不會搬移 Engine 29 的 containerd 映像儲存。 核實檔案擁有者及權限。
完成後重查相同路徑的 findmnt、df -h 與 df -i，再重跑原 pull、build 或寫入，並確認映像、容器、Volume 與應用資料都仍存在。 單純重啟或錯誤消失不足以驗證：原操作與目標檔案系統都須顯示預期結果。
