이 스레드에서 최종적으로 해결된 방법은 매번 .ppstorage를 삭제하는 것이 아니었습니다. 기본 볼륨 구성이 여전히 잘못되어 있었기 때문에 파일이 다시 생성되었습니다. 유용한 진단은 로그에서 확인할 수 있었고, 지속적인 해결책은 PhotoPrism의 Originals 경로에 매핑된 호스트 디렉터리를 올바르게 수정하는 것이었습니다.
로그 메시지는 단서였을 뿐, 전체 해결책은 아니었습니다
한 답변에서 /DATA/Gallery 안에 있는 .ppstorage 마커를 확인하고 이를 삭제하라고 제안했습니다. 사용자가 삭제했지만 PhotoPrism은 해당 파일을 다시 생성했고 계속 실패했습니다. 이는 파일 자체뿐 아니라 경로 간의 관계도 수정해야 한다는 것을 보여 주었습니다.
PhotoPrism은 Originals와 Storage를 분리합니다
공식 PhotoPrism 스토리지 폴더 문서에 따르면 Storage 폴더에는 구성, 캐시, 백업, 썸네일, 사이드카 데이터가 저장됩니다. 또한 PhotoPrism에서 지원하는 숨김 이름 구조를 사용하는 경우가 아니라면 일반적으로 Originals 내부에 구성해서는 안 됩니다. 이 상위 수준의 규칙은 애플리케이션 스토리지를 사진 Originals 트리 안에 매핑할 경우 문제가 발생할 수 있는 이유를 설명합니다.
첫 번째 Docker 앱 문서에서는 ZimaOS의 호스트 경로와 컨테이너 경로 모델을 설명하며, ZimaOS App Store 요구 사항은 둘 이상의 템플릿 또는 종속성 스택이 존재할 때 필요한 현재 패키지 수준의 맥락을 제공합니다.
데이터베이스나 권한을 변경하기 전에 로그를 확인하세요
공식 PhotoPrism Docker 문제 해결 문서에서는 Docker 로그를 확인할 것을 권장하며, 디스크, 권한, 라우팅 및 스토리지 오류를 특히 중요하게 다룹니다. 이 사례에서는 로그에 충분한 정보가 있었기 때문에 MariaDB를 무작정 다시 구축하거나 포트를 변경하거나 운영 체제 전체를 재설치할 필요가 없었습니다.
정상적으로 작동한 커뮤니티 변경이 입증한 것
사용자는 BigBear 템플릿과 ZimaOS App Store 매핑을 비교한 뒤 Originals 링크를 변경했고, PhotoPrism이 시작되었습니다. 이는 해당 설치 환경에서 스토리지 매핑이 결정적인 요인이었다는 것을 확인해 줍니다. 다만 현재 모든 PhotoPrism 패키지가 정확히 동일한 호스트 경로를 사용한다는 뜻은 아닙니다.
핵심 요약
PhotoPrism이 설치되지만 즉시 종료된다면 한꺼번에 모든 설정을 변경하기 전에 로그를 확인하세요. 이 커뮤니티 사례에서 반복적으로 나타난 .ppstorage 증상은 PhotoPrism Storage와 Originals 사이의 관계가 잘못되었음을 가리켰습니다. 마커를 계속 삭제하는 대신 볼륨 매핑을 올바르게 수정하자 앱을 시작할 수 있었습니다.
