기술 · 실용 가이드
df에는 여유가 있는데 Docker가 ‘no space left’를 표시하나요? 실제 저장 경로부터 확인하세요
Docker가 다른 마운트에 쓰거나 inode 또는 선택한 Buildx 캐시를 소진했을 수 있습니다. 정리나 이전 전에 실제 경로를 파일시스템에 연결하세요.
호스트 전체 df가 정상이어도 Docker 쓰기 대상 파일시스템은 가득 찰 수 있습니다. 실패한 pull, build, 컨테이너 쓰기가 별도 마운트, inode 고갈 또는 확인하지 않은 Buildx 빌더에 속할 수 있습니다.
실패 명령과 오류를 보존하고 실제 데몬, 저장 경로, 선택한 빌더를 확인합니다. 각 경로를 하나의 파일시스템에 매핑하고 원인과 소유자가 일치한 뒤 정리합니다.
실패 작업과 컨텍스트 보존
ENOSPC가 pull, BuildKit 단계, 시작, 애플리케이션 쓰기, 로그 중 어디서 발생했는지와 오류의 전체 경로를 기록합니다. 저장 주체가 다른 문제는 한 가지 정리로 해결되지 않을 수 있습니다. pull 캐시 정리가 bind mount의 애플리케이션 디렉터리까지 고친다는 뜻은 아닙니다. 컨테이너 쓰기 계층과 접근 가능한 모든 호스트 경로는 같은 저장 주체가 아닙니다.
docker context show, docker info, docker buildx ls로 데몬, Docker Root Dir, 드라이버, 빌더를 확인합니다. 원격 컨텍스트나 Docker Desktop에 로컬 /var/lib/docker를 가정하지 마세요. 이 경우 로컬 경로 가정을 멈추고 실제 데몬 문서의 저장소 보기를 이용하세요.
실제 경로를 파일시스템에 매핑
각 경로에 findmnt --target PATH --output SOURCE,FSTYPE,SIZE,USED,AVAIL,USE%,TARGET를 사용합니다. Engine 29에서는 /var/lib/containerd도 확인합니다. 이 추가 검사는 containerd 이미지 저장소를 쓰는 새 설치에 해당합니다. 현재 Docker 문서는 data-root가 해당 이미지와 스냅샷 저장소를 이전하지 않는다고 명시합니다.
경로 이름으로 마운트를 추정하지 마세요. 하위 디렉터리가 별도 볼륨이나 네트워크 파일시스템에 있을 수 있으며 bind mount와 애플리케이션 경로도 따로 매핑해야 합니다. 마운트 대상과 원본을 기록해 정리 전후 측정이 같은 파일시스템을 가리키게 하세요.
블록과 inode 고갈 분리
df -h PATH와 df -i PATH를 실행합니다. 바이트가 남아도 inode가 없으면 파일을 만들 수 없고, inode가 많아도 블록 부족을 해결하지 못합니다. 쿼터, 읽기 전용, I/O 오류는 별도 문제입니다. 예약 공간도 별도로 살펴야 하며 ENOSPC만으로 Docker 객체가 원인이라고 단정하지 않습니다.
바이트 부족이면 큰 소유자를, inode 부족이면 파일 수를 측정합니다. Docker, containerd, 빌더, bind mount 또는 로그와 연결하기 전에는 낯선 트리를 삭제하지 마세요. 큰 사용량을 찾을 때 관계없는 마운트로 넘어가지 않도록 하고 상태를 가진 데이터를 보존하세요.
Prune 전에 소유권 측정
docker system df -v로 데몬 객체를 보고, 실패한 빌더에 docker buildx du --builder NAME을 실행해 회수 가능·공유·변경 가능·사용 중 레코드를 구분합니다. Docker 문서는 사용 중인 레코드를 --all로도 삭제하지 않는다고 설명합니다. 공유·변경 가능 표시는 무조건 삭제해도 된다는 뜻이 아닙니다.
확인된 중지 컨테이너, 미사용 이미지 또는 제한된 캐시부터 처리합니다. system prune은 범위가 넓고 볼륨은 명시 옵션이 필요하므로 Compose, 백업, 복구 요구를 먼저 점검하세요. 명명된 볼륨과 영구 데이터도 점검하고 모든 파괴적 작업 전에 백업과 롤백 요구를 확인하세요.
가득 찼다고 증명한 저장소만 이전
보존 요구가 실제 파일시스템 용량보다 클 때는 유지보수 시간에 이전을 계획합니다. 쓰기를 멈추고 설정과 백업을 보존하며 파일 소유권과 권한을 확인한 뒤 실제 데몬 또는 containerd의 현재 문서를 따릅니다. data-root만 바꿔서는 Engine 29의 containerd 이미지 저장소가 이동하지 않습니다.
작업 후 같은 경로에서 findmnt와 두 df 검사를 다시 하고 원래 pull, build 또는 write를 재실행합니다. 이미지, 컨테이너, 볼륨, 애플리케이션 데이터가 남았는지도 확인하세요. 데몬 재시작이나 오류가 사라진 사실만으로는 부족합니다. 원래 작업과 대상 파일시스템에서 모두 의도한 결과를 확인해야 합니다.
