“Built-in storage almost full” is a symptom, not a single ZimaOS bug. This source thread exposed at least three different causes: a Backup task whose USB destination disappeared and was effectively recreated under local /DATA, 519GB까지 커진 폭주 Docker JSON 로그, 그리고 다른 시스템에서 발생한 사례가 있었습니다. “내장 저장 공간이 거의 가득 참”은 단일 ZimaOS 버그가 아니라 증상입니다. 이 원문 스레드에서는 최소 세 가지 원인이 드러났습니다. USB 대상이 사라져 로컬에 사실상 다시 생성된 백업 작업, /DATA/.media 409GB가 사용되었습니다.
가장 안전한 대응은 먼저 용량을 측정하고, 해당 데이터를 소유한 서비스를 식별한 뒤, 기록 작업을 중지하고, 확인된 데이터만 정리하는 것입니다. 크기가 크다는 이유만으로 /DATA/.docker, .media 또는 AppData를 재귀적으로 삭제하지 마세요.
/DATA 대용량 데이터 풀이 여전히 수TB의 여유 공간을 보유하고 있었음에도,앱 데이터를 마이그레이션해도 이후의 모든 쓰기 작업이 /DATA 외부에서 이루어진다는 보장은 없습니다.
읽기 전용 du 검사로 가장 큰 디렉터리 찾기
원문 사용자가 공유한 내용은 다음과 같습니다.
sudo du -x -h --max-depth=1 /DATA 2>/dev/null | sort -hr이 명령은 파일을 수정하지 않습니다. 의심스러운 디렉터리에 반복 실행하여 가장 큰 하위 트리를 좁혀 갈 수 있습니다.
연결이 끊긴 백업 대상이 최초로 확인된 원인이었습니다.
Cobblerkid는 백업 작업이 외장 USB 드라이브를 대상으로 설정되어 있었다는 사실을 발견했습니다. 드라이브를 분리한 후 백업 구조가 /DATA 그리고 예약 작업은 로컬 저장 공간이 가득 찰 때까지 계속 기록했습니다.
Zima-Jerry는 이것이 문제로 보인다는 데 동의하고 내부적으로 전달했습니다. 따라서 이는 단순한 커뮤니티의 추측을 넘어섭니다.
또 다른 사용자는 519GB에 달하는 컨테이너 JSON 로그를 발견했습니다.
두 번째 참여자는 Docker 컨테이너 디렉터리 하나를 검사한 결과, *-json.log 약 519GB 크기의 파일이 Home Assistant 컨테이너에서 생성된 것으로 추정되었습니다.
사용자는 컨테이너를 제거하여 공간을 확보했습니다. 이를 “Docker 로그를 수동으로 삭제하라”고 일반화해서는 안 됩니다. 먼저 로그를 과도하게 생성하는 컨테이너를 식별하고, 로그를 검사한 다음, 로그를 반복해서 생성하는 오류를 수정해야 합니다.
세 번째 시스템에서는 /DATA/.media 아래에서 409GB가 발견되었습니다.
다른 사용자는 일반 AppData가 약 225GB였던 용량 내역을 게시했습니다. .docker 3.5GB에 불과했지만, .media 409GB가 사용되었습니다. 이는 하나의 정리 명령으로 모든 “디스크가 가득 참” 문제를 해결할 수 없는 이유를 보여줍니다.
현재 ZimaOS는 더 많은 앱 저장 공간 및 캐시 제어 기능을 제공합니다
현재 IceWhale 문서에 따르면 설정 → 앱에서 App data 위치와 앱별 사용량/캐시 정리를 확인할 수 있습니다. AppData를 주 스토리지 어레이에 유지하면 작은 시스템 드라이브의 부담을 줄일 수 있습니다.
셸 정리를 시도하기 전에 현재 ZimaOS 앱 스토리지 제어 기능을 사용하세요.
더 안전한 복구 순서
- 여전히 데이터를 생성 중인 작업/앱을 중지하세요.
- 측정하세요.
/DATA읽기 전용으로 실행하세요. - 정확한 파일/폴더와 소유자를 식별하세요.
- 중요한 AppData/구성을 백업하세요.
- 가능하면 지원되는 앱/캐시 제어 기능을 사용하세요.
- 삭제 가능한 데이터 또는 오류가 확인된 데이터만 제거하세요.
- 재부팅 후에도 사용 가능한 공간이 안정적으로 유지되는지 확인하세요.
docker image prune이 모든 Docker 공간 문제를 해결하지는 않습니다
소스에서 raller1028은 다음을 언급했습니다 docker image prune -a 컨테이너에서 사용하지 않는 이미지를 제거하는 방법입니다. 사용하지 않는 이미지 레이어를 회수할 수 있지만, 519GB에 달하는 활성 컨테이너 JSON 로그, 계속 증가하는 Backup 대상 또는 사용자 데이터 문제는 해결하지 못합니다. .media.
먼저 용량 스캔으로 범주를 식별하세요. 잘못된 범주를 대상으로 한 정리 명령은 거의 공간을 확보하지 못하면서 새로운 위험을 만들 수 있습니다.
거대한 JSON 로그는 컨테이너의 오류 루프가 여전히 문제라는 뜻입니다
문제를 일으킨 컨테이너를 제거하면 한 사용자의 공간은 확보되었지만, 더 중요한 장기적 질문은 애플리케이션이 왜 수백 GB의 로그를 기록했는가입니다. 동일한 작업을 다시 설치하기 전에 최근 로그에서 반복 오류, 재시작 루프, 사용할 수 없는 장치 또는 구성 문제를 확인하세요.
새로 만든 컨테이너가 즉시 로그를 다시 생성하기 시작하면 디스크 가득 참 상태가 재발합니다.
.media를 삭제 가능한 캐시가 아닌 관리되는 스토리지로 취급하세요
409GB /DATA/.media 이 예에는 임시 캐시가 아니라 실제 관리되는 마운트/파일 데이터가 포함되어 있을 수 있습니다. 그곳의 항목을 삭제하기 전에 어떤 스토리지/공유 폴더/앱이 소유하는지 식별하고 동일한 파일이 다른 위치에도 존재하는지 확인하세요.
내장 스토리지 가득 참 FAQ
소스에서 AppData 마이그레이션 자체가 실패했다는 사실이 입증되었나요?
아니요. 원 게시자는 관리되는 범주를 이전했으며, 확인된 용량 증가는 연결이 끊긴 Backup 대상에서 발생했습니다.
전체 .docker 디렉터리를 삭제해도 안전한가요?
아니요. 활성 컨테이너 상태, 로그, 이미지 및 애플리케이션 종속성이 포함될 수 있습니다.
소스에서 가장 먼저 실행할 명령은 무엇인가요?
읽기 전용 du 용량 스캔 /DATA 실제 대형 하위 트리를 식별하려면
