ZimaOS Files에 Error Loading이 표시되지만 Windows SMB 액세스는 여전히 작동한다면, RAID 또는 데이터가 사라졌다고 즉시 단정하지 마세요. 2026년 2월 이 스레드에서도 같은 패턴이 나타났습니다. 1.5.4 업데이트 후 Files UI가 작동하지 않았지만 다른 앱과 Samba 파일 액세스는 계속 정상적으로 작동했습니다.
이후 IceWhale 직원이 가장 중요한 근본 원인의 범위를 설명했습니다. raller1028은 ZimaOS 1.5.4에서 시스템 디스크가 가득 차면 Files 서비스가 제대로 작동하지 않을 수 있다고 밝혔습니다. 공식 복구 방법은 시스템 디스크의 공간을 확보한 다음 icewhale-files를 다시 시작하는 것이었습니다. 별도의 커뮤니티 데이터베이스 이름 변경 우회 방법도 여러 사용자에게 도움이 되었지만, IceWhale은 이를 첫 번째 해결 방법으로 제시하지 않았습니다.
SMB가 작동한다는 것은 데이터와 마운트가 여전히 존재한다는 강력한 증거입니다
원글 작성자는 Windows Samba 공유를 통해 파일에 계속 액세스할 수 있었습니다. 이는 Files 웹 애플리케이션이 파일을 표시하지 못하더라도 호스트 스토리지와 데이터 경로는 정상적으로 작동하고 있었다는 뜻입니다.
이는 다음 항목을 구분하는 데 중요합니다.
- 스토리지/데이터 손실
- Files 서비스 오류
- 브라우저/UI 오류
Files는 일반적인 앱 스토어 Docker 컨테이너가 아닙니다
따라서 docker ps에 Files 컨테이너가 표시되지 않는 것은 정상입니다. 임의의 Docker 컨테이너를 다시 시작해도 기본 제공 Files 서비스는 복구되지 않습니다.
IceWhale은 시스템 스토리지 부족을 1.5.4의 원인으로 확인했습니다
2월 26일 IceWhale의 raller1028은 버전 1.5.4에서 시스템 디스크가 가득 찬 것이 문제의 원인일 “것”이라고 밝혔습니다.
공식 복구 순서는 다음과 같습니다.
- 명령줄을 통해 시스템 디스크의 공간을 확보합니다.
- Files 서비스를 다시 시작합니다.
systemctl restart icewhale-files명령줄 정리에 익숙하지 않은 사용자는 파일을 무작정 삭제하지 말고 지원팀에 문의하라는 안내를 받았습니다.
시스템 디스크가 가득 차면 SMB는 작동하는데 Files가 중단될 수 있는 이유
기본 제공 서비스는 데이터베이스, 상태 정보, 임시 파일, 로그 또는 서비스 작업을 위해 사용 가능한 공간이 필요합니다. 대용량 사용자 데이터가 다른 스토리지 어레이에 그대로 남아 있더라도 작은 시스템 파티션의 사용률이 100%에 도달하면 특정 서비스에만 오류가 발생할 수 있습니다.
따라서 “내 RAID에는 여유 공간이 있다”는 사실만 확인하는 것으로는 충분하지 않습니다.
계속 증가하는 앱 데이터를 시스템 드라이브에서 분리하세요
현재 ZimaOS 문서에서는 Docker 데이터베이스, 썸네일, 캐시가 시스템 디스크를 가득 채우지 않도록 앱 데이터를 실제 스토리지 공간으로 이동할 것을 권장합니다.
다른 원인으로 시스템 드라이브의 공간이 부족해지는 문제를 방지하려면 현재 ZimaOS 앱 스토리지 안내를 따르세요.
커뮤니티의 files.db 이름 변경 방법은 여러 사용자에게 효과가 있었습니다
이후 한 커뮤니티 사용자가 다음 명령을 게시했습니다.
mv /var/lib/casaos_data/.casaos/files.db /var/lib/casaos_data/.casaos/files.db.bak
systemctl restart icewhale-files여러 참여자는 이 방법으로 Files가 복구되었다고 답했습니다.
그러나 이는 여전히 커뮤니티에서 제시한 보조 복구 방법으로 취급해야 합니다. IceWhale 직원은 Files 데이터베이스를 제거하는 것이 어떤 의미인지 즉시 질문했으며, 공식적인 “시스템 공간 확보 + 서비스 다시 시작” 안내를 이 명령으로 대체하지 않았습니다.
데이터베이스 이름 변경은 삭제보다 안전하지만 애플리케이션 상태를 변경합니다
커뮤니티 명령은 데이터베이스를 삭제하지 않고 .bak 사본을 남깁니다. 이는 롤백 측면에서 더 안전하지만, Files 데이터베이스를 다시 구축하면 색인된 메타데이터나 기타 서비스 상태가 변경될 수 있습니다.
시스템 디스크가 단순히 가득 찬 상황이라면 이 방법을 첫 번째 조치로 사용하지 마세요.
현재 ZimaOS에서도 1.5.4 버그가 계속된다고 단정하지 마세요
현재 ZimaOS는 1.7.x이며 Files, 스토리지, 메모리, 보안 및 앱 스토리지와 관련된 수정 사항이 계속 적용되고 있습니다. 이 과거 문제는 모든 최신 Files 오류의 원인이 같기 때문이 아니라, 서비스 오류와 데이터 손실을 구분하는 방법을 알려 준다는 점에서 유용합니다.
오늘 문제가 다시 발생한다면 먼저 현재 시스템 여유 공간, 현재 버전, 서비스 상태, SMB 또는 다른 파일 액세스가 여전히 작동하는지를 확인하고 기록하세요.
공간은 신중하게 확보하세요
알 수 없는 시스템 디렉터리를 대상으로 광범위한 정리 스크립트를 실행하지 마세요. 가능한 경우 용량이 큰 앱 캐시, Docker 데이터, 백업 또는 로그를 확인하고 현재 ZimaOS의 정리 및 마이그레이션 기능을 사용하세요.
Files Error Loading FAQ
원글 사례에서도 SMB는 작동했나요?
예. 이는 데이터와 마운트가 여전히 존재한다는 강력한 근거였습니다.
IceWhale 직원은 1.5.4의 문제를 무엇이라고 설명했나요?
시스템 디스크가 가득 차서 Files 서비스가 제대로 작동하지 않는 문제라고 설명했습니다.
공식 서비스 재시작 명령은 무엇인가요?
systemctl restart icewhale-files입니다.
files.db 이름 변경이 공식적인 첫 번째 해결 방법이었나요?
아니요. 여러 사용자가 효과를 확인한 커뮤니티 우회 방법이었으며, IceWhale의 첫 번째 안내는 공간을 확보한 뒤 Files 서비스를 다시 시작하는 것이었습니다.
