ZimaOS 데이터 마이그레이션 후 Docker가 시작되지 않을 때는 로그의 마지막 줄이 오해를 불러일으킬 수 있습니다. 이 2026년 2월의 사례에서 Docker는 결국 overlay2 스토리지 드라이버가 지원되지 않는다고 보고했습니다. 몇 줄 위를 읽으면 실제 실패 원인이 드러납니다. 시스템 디스크에 임시 파일을 만들거나 오버레이 스토리지를 테스트할 공간이 없었던 것입니다.
사용자에게는 180GB ZimaOS SSD가 있었고, 여기에 계속 증가하는 Immich 데이터베이스를 실수로 남겨 두었습니다. 마이그레이션을 시도할 때쯤에는 제대로 이동을 완료할 여유 공간이 부족했습니다. 여러 차례 시도하고 로그를 수동으로 삭제한 후 AppData가 마이그레이션된 것처럼 보였지만, 시스템 디스크는 여전히 100%에 도달했고 재부팅 후 Docker를 더 이상 초기화할 수 없었습니다.
Immich가 마이그레이션 전에 작은 시스템 SSD를 가득 채웠습니다
사용자는 데이터베이스를 시스템 드라이브에서 옮기지 않은 채 Immich를 설치했습니다. 사진 스택이 커지면서 디스크가 가득 찼고 ZimaOS에서 오류가 보고되기 시작했습니다.
이는 현재 IceWhale의 지침과 일치합니다. 사진 라이브러리, 미디어 메타데이터, 문서 색인, 데이터베이스, 캐시는 빠르게 증가할 수 있으므로 애플리케이션 데이터는 작은 시스템 디스크가 아니라 주 저장 공간에 배치해야 합니다.
마이그레이션 자체에도 작업 공간이 필요했습니다
사용자는 시스템 디스크가 이미 심각하게 가득 찬 후에야 ZimaOS 마이그레이션 워크플로를 시도했습니다. 첫 번째 마이그레이션 시도는 작업을 임시 저장할 여유 공간이 부족해 실패했다고 말했습니다.
이는 중요한 운영상의 교훈입니다. Docker와 마이그레이션 서비스가 작업 공간 부족으로 이미 중단된 후가 아니라, 시스템 디스크에 남은 공간이 몇 GB에 불과해지기 전에 AppData를 이동하세요.
Docker 소켓 메시지는 단지 증상일 뿐이었습니다
애플리케이션에서 다음을 보고했습니다.
unix:///var/run/docker.sock의 Docker 데몬에 연결할 수 없습니다.
Docker 데몬이 실행 중인가요?이 메시지는 Docker 데몬을 사용할 수 없다는 의미입니다. 데몬이 실패한 이유를 알려 주지는 않습니다.
저널이 실제 근본 원인을 밝혀냈습니다
중요한 줄은 다음과 같습니다.
장치에 남은 공간이 없습니다
기본 AppArmor 프로필을 로드하지 못했습니다
mkdir /var/lib/docker/overlay2/check-overlayfs-support...: no space left on device
데몬 시작 실패: graphdriver 초기화 오류Docker는 임시 데이터를 쓸 수 없어서 처음 실패했습니다. 이후 드라이버가 지원되지 않음 이 메시지는 저장소 드라이버 초기화 실패의 결과이며, 마이그레이션 후 실행 중인 커널이 갑자기 overlay2 지원을 잃었다는 증거가 아닙니다.
Docker를 재시작해도 문제가 해결되지 않은 이유
사용자는 재시작을 시도했습니다. docker.service 그리고 docker.socket 수동으로 실행했지만 Access denied가 발생했습니다. 커뮤니티의 한 답변은 이를 ZimaOS의 어플라이언스 스타일 서비스 제어 방식과 연결했습니다.
서비스 재시작이 허용되었더라도 여유 디스크 공간이 생기지는 않았을 것입니다. 데몬은 다시 동일한 쓰기 오류에 도달했을 뿐입니다.
Docker 임시 파일을 삭제해도 충분한 공간이 확보되지 않음
커뮤니티에서는 먼저 디스크 공간을 확인한 다음 임시 Docker 파일을 삭제해 보라고 제안했습니다. 원래 사용자는 이를 시도했지만 시스템 드라이브가 여전히 100% 가득 차 있고 Docker도 여전히 시작되지 않는다고 답했습니다.
이 부정적인 결과는 유용한 정보를 제공합니다. 시스템 디스크가 계속 완전히 포화된 상태라면, 소규모 임시 정리만으로는 저장소 설계를 해결할 수 없습니다.
원 게시자는 백업과 Factory Restore를 선택했습니다
정리 작업이 실패한 후, 사용자는 백업하기로 결정했습니다. /DATA/AppData ZimaOS를 재설치하고 복원하는 방법입니다. 커뮤니티 답변자는 설치된 앱을 기록한 뒤 Factory System Restore를 사용하고, 앱 관련 저장소를 대용량 디스크로 마이그레이션한 다음 앱을 재설치하라고 권장했습니다.
공개 스레드는 사용자가 그렇게 하겠다고 말한 뒤 종료됩니다. 복원 후 확인 게시물은 없으므로, 이 페이지에서는 해당 사용자의 재설치를 검증된 최종 해결책으로 표시해서는 안 됩니다.
현재 ZimaOS 데이터 마이그레이션은 이동 가능한 항목을 더 명확하게 구분합니다
현재 ZimaOS는 다음과 같이 별도의 마이그레이션 범주를 제공합니다.
- Docker 이미지;
- Docker 애플리케이션 데이터;
- Gallery, Downloads, Documents, Media, Backup 같은 사용자 데이터베이스.
이 내용은 이전 스레드의 중요한 업데이트입니다. 이전 논의에서는 때때로 “AppData 마이그레이션”이 모든 Docker 저장소를 자동으로 포함하는 것처럼 다뤄졌습니다.
소형 시스템 디스크가 심각하게 가득 차기 전에 현재 ZimaOS 데이터 마이그레이션 범주를 사용하세요.
앱 데이터 위치를 미리 설정하여 문제를 예방하세요
현재 ZimaOS에서는 설정 > 앱에서 앱 데이터 위치도 지정할 수 있습니다. IceWhale은 처음부터 모든 영구 앱 데이터가 시스템 장치에서 계속 증가하도록 두기보다 스토리지 어레이를 지정할 것을 권장합니다.
ZimaOS 앱이 영구 데이터를 저장하는 위치에 대한 현재 설명이 가장 유용한 예방 참고 자료입니다.
용량과 아이노드를 모두 확인하세요
파일 시스템은 여유 블록이 없거나 아이노드가 모두 소진되면 새 파일 생성을 거부할 수 있습니다. 원본 문제 해결 과정에서는 두 항목을 모두 확인할 것을 제안했습니다. 이 사례의 로그는 일반적인 용량 부족을 강하게 시사하지만, 두 값을 모두 확인하는 것은 여전히 유용한 읽기 전용 진단입니다.
재설치가 합리적인 경우
시스템 디스크가 100% 가득 차 Docker 스토리지 메타데이터가 손상되고 데몬을 시작할 수 없으며 안전한 정리로 충분한 작업 공간을 확보할 수 없다면, Docker의 overlay 메타데이터를 수동으로 편집하는 것보다 제어된 시스템 복원이 더 빠르고 안전할 수 있습니다.
먼저 AppData와 사용자 데이터를 보호하고, 복원 과정에서 어떤 디스크에 영향을 미치는지 파악하며, 애플리케이션 데이터베이스의 유일한 복사본을 삭제하지 않도록 하세요.
마이그레이션 후 Docker FAQ
원본 하드웨어에서 overlay2가 실제로 지원되지 않았나요?
로그에는 먼저 디스크가 가득 차 Docker가 overlay2 테스트 파일을 생성하지 못한 내용이 표시됩니다. 드라이버 메시지는 그 실패 이후에 나타났습니다.
Docker tmp를 비워서 원본 시스템 문제가 해결되었나요?
아니요. 원 게시자는 OS 드라이브가 100% 가득 찬 상태로 유지되었다고 말했습니다.
현재 ZimaOS에서는 AppData와 Docker 이미지를 별도로 이동할 수 있나요?
예. 현재 데이터 마이그레이션에서는 Docker 이미지와 Docker 애플리케이션 데이터가 별도의 이동 가능한 범주로 나열됩니다.
스레드에서 공장 초기화가 성공적으로 완료되었다는 확인이 있었나요?
아니요. 사용자는 이를 진행하겠다고 했지만, 공개 스레드는 복원 후 결과가 게시되기 전에 끝납니다.
