Ubuntu 24.04에서 No space left on device 오류가 발생할 때 원인을 확인하는 방법

적용 환경

가장 먼저 확인할 항목

오류가 발생한 직후에는 파일을 무작정 삭제하지 말고 디스크 블록과 inode 사용량을 함께 확인합니다.

df -hT
df -iT

df -hT에서는 Use%와 Avail을 확인하고, df -iT에서는 IUse%와 IFree를 확인합니다.

오류가 발생한 파일시스템 확인

루트 파일시스템에 여유 공간이 있어도 오류가 발생한 경로가 별도의 디스크나 파티션에 마운트되어 있다면 해당 파일시스템만 가득 찰 수 있습니다. 예를 들어 오류가 /var/lib/mysql에서 발생했다면 다음과 같이 확인합니다.

findmnt -T /var/lib/mysql -o SOURCE,FSTYPE,SIZE,USED,AVAIL,USE%,TARGET

오류가 발생한 경로가 다르다면 해당 경로로 바꿉니다. 이후 df도 그 경로를 기준으로 확인합니다.

df -hT /var/lib/mysql
df -iT /var/lib/mysql

이렇게 하면 루트 파티션 전체가 아니라 실제 오류가 발생한 파일시스템의 블록과 inode 상태를 정확히 확인할 수 있습니다.

실제 디스크 용량 부족 확인

Use%가 100%에 가깝고 Avail이 거의 없다면 실제 저장 공간이 부족한 상태입니다. 먼저 동일 파일시스템 안에서 어떤 상위 디렉터리가 큰지 확인합니다.

sudo du -xhd1 / 2>/dev/null | sort -h

-x는 다른 파일시스템으로 넘어가지 않도록 제한합니다. 예를 들어 /var가 큰 것으로 확인되면 한 단계 더 좁힙니다.

sudo du -xhd1 /var 2>/dev/null | sort -h

특정 디렉터리에서 대용량 파일을 확인하려면 검색 범위를 충분히 좁힌 뒤 다음과 같이 확인할 수 있습니다.

sudo find /var/log -xdev -type f -size +100M -printf '%s %p\n' 2>/dev/null | sort -n

대용량 파일을 찾은 뒤에는 파일의 소유 서비스와 보존 필요성을 확인해야 합니다. 데이터베이스 파일, 컨테이너 데이터, 활성 로그를 단순 삭제하지 마십시오.

inode 부족 확인

디스크 용량은 남아 있는데 df -iT의 IUse%가 100%에 가깝거나 IFree가 0이라면 작은 파일이 너무 많이 생성되어 inode가 소진된 상태입니다.

df -iT
sudo du --inodes -x -d1 / 2>/dev/null | sort -n

inode 사용량이 큰 경로를 찾았다면 같은 방식으로 하위 디렉터리를 좁혀갑니다.

sudo du --inodes -x -d1 /var 2>/dev/null | sort -n

inode 부족은 별도의 지구 IDC 문서에서 정리 방법과 ext4 파일시스템 확장까지 상세히 다루고 있으므로, inode가 직접 원인으로 확인되었다면 해당 문서를 참고하는 것이 좋습니다.

삭제했는데 공간이 늘지 않는 경우

Linux에서는 프로세스가 파일을 연 상태에서 파일을 삭제하면 디렉터리에서는 보이지 않지만 해당 프로세스가 파일을 닫을 때까지 디스크 블록이 계속 사용됩니다. 이런 경우 df와 du의 사용량 차이가 크게 나타날 수 있습니다.

lsof가 설치되어 있다면 링크 수가 0인 열린 파일을 확인합니다.

sudo lsof +L1

출력에서 COMMAND, PID, SIZE/OFF, NAME을 확인합니다. 특히 수 GB 이상의 삭제된 로그나 데이터 파일을 계속 잡고 있는 프로세스가 있는지 확인합니다.

해당 PID가 어떤 서비스인지 확인합니다.

ps -p PID -o pid,ppid,user,etime,cmd

별도 마운트와 tmpfs가 가득 찬 경우

서버의 루트 파일시스템에는 여유 공간이 있어도 /var, /home, /tmp, /run, 컨테이너 볼륨 등이 별도 파일시스템이면 그 영역만 가득 찰 수 있습니다.

findmnt -D
df -hT / /var /tmp /run 2>/dev/null

/run과 일부 임시 경로는 메모리 기반 tmpfs일 수 있습니다. tmpfs가 가득 찬 경우 물리 디스크에 여유 공간이 있어도 해당 경로에는 새 파일을 만들 수 없습니다.

오류가 발생한 정확한 경로를 findmnt -T 경로로 확인하는 것이 가장 중요합니다.

systemd journal과 로그 사용량 확인

웹 서버, 데이터베이스, 애플리케이션 오류가 반복되면 로그가 빠르게 증가할 수 있습니다. 먼저 /var/log의 상위 디렉터리별 사용량을 확인합니다.

sudo du -xhd1 /var/log 2>/dev/null | sort -h
sudo journalctl --disk-usage

journalctl --disk-usage는 활성 journal과 보관 journal이 사용하는 전체 용량을 표시합니다. journal 사용량이 비정상적으로 크다면 먼저 어떤 서비스가 로그를 반복 생성하는지 확인해야 합니다.

sudo journalctl -p warning --since "1 hour ago" --no-pager

단순히 로그를 삭제하는 것보다 로그 폭증을 발생시키는 서비스 오류를 먼저 해결하고, 필요하면 별도의 systemd-journald 용량 제한 정책을 적용하는 것이 좋습니다.

Docker를 사용하는 서버에서 확인할 항목

Docker가 설치된 서버에서는 이미지, 중지된 컨테이너, 빌드 캐시, 컨테이너 로그와 writable layer가 많은 공간을 사용할 수 있습니다. Docker 자체 명령으로 사용량을 확인합니다.

sudo docker system df -v

Docker 데이터 디렉터리가 별도 파일시스템인지도 확인합니다.

findmnt -T /var/lib/docker
df -hT /var/lib/docker
df -iT /var/lib/docker

디스크가 남아 있는데 애플리케이션에서 ENOSPC가 발생하는 경우

파일시스템 블록과 inode에 충분한 여유가 있는데도 개발 도구, 파일 감시 프로그램, Node.js 애플리케이션 등의 로그에서 No space left on device가 발생한다면 Linux inotify 한도에 도달한 경우도 확인해야 합니다.

현재 per-user inotify 제한 값을 확인합니다.

sysctl fs.inotify.max_user_watches
sysctl fs.inotify.max_user_instances
sysctl fs.inotify.max_queued_events

Linux의 inotify_add_watch()는 사용자별 watch 한도에 도달하거나 필요한 커널 자원을 할당하지 못한 경우에도 ENOSPC를 반환할 수 있습니다. 따라서 디스크와 inode가 모두 정상인 상황이라면 오류를 낸 애플리케이션이 파일 감시 기능을 사용하는지 확인해야 합니다.

원인 확인 후 재검증

원인에 맞는 조치를 수행한 뒤에는 동일 파일시스템의 블록과 inode 사용량을 다시 확인합니다.

df -hT
df -iT

오류가 발생했던 경로에서 새 파일 생성이 가능한지도 확인할 수 있습니다. 아래 예시는 /var/tmp가 문제 파일시스템에 포함된 경우에만 사용합니다.

TEST_FILE=$(mktemp /var/tmp/no-space-test.XXXXXX)
ls -l "$TEST_FILE"
rm -f "$TEST_FILE"

서비스가 중단되었던 경우 서비스 상태와 최근 로그를 함께 확인합니다.

sudo systemctl status SERVICE_NAME --no-pager
sudo journalctl -u SERVICE_NAME -n 100 --no-pager

SERVICE_NAME은 실제 서비스명으로 변경하고, 로그에서 No space left on device가 더 이상 반복되지 않는지 확인합니다.

상황별 원인 정리

관련 지구 IDC 기술자료

• Ubuntu 24.04에서 디스크 inode 부족 문제를 해결하는 방법
• Ubuntu 24.04에서 systemd-journald 로그 용량을 제한하는 방법

공식 참고자료

자주 묻는 질문

디스크 용량이 남아 있는데도 No space left on device가 발생할 수 있나요?

가능합니다. inode가 모두 사용되었거나, 오류 경로가 별도의 가득 찬 파일시스템에 있거나, 애플리케이션이 inotify watch 한도에 도달한 경우에도 비슷한 ENOSPC 오류가 발생할 수 있습니다.

파일을 삭제했는데 df 사용량이 줄지 않는 이유는 무엇인가요?

프로세스가 해당 파일을 계속 열고 있으면 파일 이름은 사라져도 디스크 블록은 해제되지 않습니다. sudo lsof +L1로 삭제됐지만 열린 파일을 확인하십시오.

df와 du의 사용량이 크게 다른 것은 왜 그런가요?

df는 파일시스템이 실제로 할당한 블록을 기준으로 보고하고, du는 현재 디렉터리 트리에서 접근할 수 있는 파일을 기준으로 합산합니다. 삭제됐지만 열린 파일이 크면 두 값이 크게 차이날 수 있습니다.

/var/log를 통째로 삭제해도 되나요?

권장하지 않습니다. 활성 로그, 서비스 전용 디렉터리, 감사 로그가 포함되어 있을 수 있습니다. 먼저 du와 journalctl --disk-usage로 원인을 확인하고 서비스별 logrotate 또는 공식 정리 방법을 사용하십시오.

재부팅하면 공간 부족 문제가 해결되나요?

삭제됐지만 열린 파일이 원인이라면 재부팅으로 파일 핸들이 닫히면서 공간이 반환될 수 있지만, 근본 원인을 확인하지 않은 재부팅은 권장하지 않습니다. 실제 디스크 용량이나 inode가 가득 찬 상태라면 재부팅 후 서비스가 시작되지 않을 수도 있습니다.