더 큰 HDD를 추가한 후에도 Immich가 ZimaOS 시스템 SSD의 여유 공간을 계속 표시한다면, 중요한 질문은 어떤 호스트 디렉터리가 실제로 Immich의 업로드/저장소 마운트에 연결되어 있는가입니다. 2026년 4월 커뮤니티 스레드에서 원 작성자는 250GB 시스템 SSD에서 Immich 2.7.4를 실행하고 있었으며, 사진을 1TB HDD에 저장하려고 했습니다. 설치 후 경로를 반복해서 변경하자 비정상 컨테이너나 시작 실패가 발생했습니다.
원본 스레드에서는 여러 가지 결과가 나왔습니다. 한 사용자는 새로 설치한 후 사용자 지정 YAML을 적용해 성공했습니다. 원 작성자는 결국 Immich를 설치하기 전에 HDD 저장 경로를 선택한 후에만 성공했다고 보고했습니다. 이후 한 답변에서는 일부 시작 실패가 Immich의 저장소 무결성 검사와 관련 있을 수 있다고 설명했습니다. 현재의 Immich 공식 문서도 2.7.4 버전 이후 변경되었으므로, 이 과거 ZimaOS 패키지의 정확한 컨테이너 경로를 현재의 모든 Immich 배포에 그대로 적용해서는 안 됩니다.
원래 Immich 2.7.4 설정에서 사용한 방식
커뮤니티 안내에는 다음과 같은 당시의 매핑이 나와 있었습니다.
호스트: /DATA/Gallery/immich
컨테이너: /usr/src/app/upload첫 번째 권장 방법은 컨테이너 측 경로는 유지한 채 호스트 측 경로만 변경하는 것이었습니다. 예를 들어 보조 드라이브를 ZimaOS 호스트 경로를 통해 노출하면서도 Immich에서는 예상되는 내부 업로드 디렉터리로 보이게 할 수 있습니다.
호스트 경로만 변경하는 방법이 모두에게 작동하지 않은 이유
여러 사용자가 Immich가 이미 초기화된 후 기본 호스트 경로를 바꾸려고 했습니다. 일부는 비정상 컨테이너 상태가 되었고, 일부는 읽기 전용 파일 시스템 오류가 발생했으며, 다른 사용자들은 앱이 여전히 시스템 드라이브를 표시하는 것을 확인했습니다.
즉, 이 스레드는 “볼륨 하나를 수정하고 재시작하면” 항상 작동한다는 일반적인 주장을 뒷받침하지 않습니다. Immich는 데이터베이스 상태와 저장소 무결성 마커를 유지하므로, 초기화 후 바인드 마운트를 변경하면 새 디렉터리가 Immich가 예상하는 상태와 일치하지 않을 수 있습니다.
원 작성자가 확인한 작동 방법
여러 차례 실패한 시도 끝에 Solid는 4월 19일에 돌아와, Immich 설치가 초기화되기 전에 새로 설치하고 설치/저장 경로를 1TB HDD로 변경하는 것이 작동하는 방법이라고 밝혔습니다.
두 번째 사용자가 클린 재설치 및 사용자 지정 YAML 경로를 확인함
또 다른 참여자인 scott492010은 실패한 설치를 제거하고 기존 사진을 보존한 뒤 오래된 Immich AppData/데이터베이스 상태를 삭제하고 재설치한 다음, 스레드에서 공유된 사용자 지정 YAML을 사용했습니다. 새 설정이 정상적으로 작동했다고 명시적으로 확인했습니다.
AppData 또는 Immich 데이터베이스를 함부로 삭제하지 마세요. 해당 커뮤니티 절차는 손상되었거나 테스트 중인 설치에서 사용되었습니다. 라이브러리에 중요한 메타데이터, 사용자, 앨범 또는 업로드된 자산이 포함되어 있다면 재구축하기 전에 데이터베이스와 사진 저장소를 모두 백업하세요.
과거 ZimaOS 경로: /DATA/.media/...
해당 스레드에서는 다음과 같은 외부 드라이브 경로를 시험했습니다.
/DATA/.media/Elements/Photos
/DATA/.media/Elements/Photos/upload이 예시들은 해당 논의에서 사용된 드라이브와 ZimaOS 경로 레이아웃에 특정된 것입니다. 다음 이름을 그대로 복사하지 마세요. Elements 모든 드라이브가 호스트에서 동일한 경로로 표시된다고 가정하지 마세요. 현재 ZimaOS 파일/앱 설정에 표시된 실제 경로를 사용하세요.
현재 Immich는 다른 업스트림 스토리지 레이아웃을 사용합니다.
현재 업스트림 Immich Docker Compose 문서에서는 다음을 사용합니다. UPLOAD_LOCATION 호스트에서 해당 경로를 사용하고 다음 위치에 마운트합니다. /data 현재 Compose 템플릿에 있습니다. 이는 과거 ZimaOS Immich 2.7.4 매핑과 다릅니다. /usr/src/app/upload.
최신 Immich Docker Compose 문서를 참조하세요.
이는 모순이 아니라 버전 차이입니다. ZimaOS 앱 스토어 패키지를 사용하는 경우 현재 패키지에서 정의한 컨테이너 대상 경로를 유지하세요. 업스트림 Compose를 직접 관리하는 경우 현재 업스트림 템플릿을 따르세요.
사용자 지정 파일 위치를 위한 현재 Immich 지침
Immich에는 이제 전용 파일 사용자 지정 위치 가이드가 있습니다. 이 가이드에서는 호스트 측 위치를 신중하게 변경하고 해당 기존 파일도 함께 이동하여 Immich가 계속 파일을 찾을 수 있도록 권장합니다.
Immich는 또한 다음을 분리하지 말라고 경고합니다. upload/ 및 library/ 같은 장치의 별도 바인드 마운트로 분리하는 방식입니다. 새 레이아웃을 구성할 때는 2026년 커뮤니티 YAML을 한 줄씩 재구성하기보다 현재 스토리지 모델을 따르세요.
누락된 .immich 파일이 시작을 중단시킬 수 있는 이유
2026년 7월 스레드의 답변에서는 다음과 같은 오류를 확인했습니다.
ENOENT: 해당 파일 또는 디렉터리가 없습니다
.../encoded-video/.immich현재 Immich 시스템 무결성 문서에서도 숨겨진 .immich 파일이 잘못된 권한이나 누락되었거나 교체된 스토리지 마운트를 감지하는 데 사용되는 마운트 마커임을 확인할 수 있습니다.
포럼 답변에서는 필요한 폴더와 마커 파일을 수동으로 만들 것을 제안했습니다. 현재 업스트림 문서는 더 신중한 입장입니다. 특정 복구 상황을 제외하면 마커 파일을 일반적으로 수동으로 만들거나 삭제해서는 안 됩니다. 마운트가 예기치 않게 변경되었다면 먼저 마운트를 올바르게 수정하세요. 마커가 누락된 이유를 확인한 경우에만 마커를 수동으로 다시 만드는 것이 적절합니다.
기본 권한 해결 방법으로 chmod 777을 사용하지 마세요
최종 커뮤니티 답변에도 다음 내용이 포함되었습니다.
sudo chmod -R 777 /DATA/Main-Storage/immich이렇게 하면 모든 로컬 사용자/프로세스에 광범위한 쓰기 권한이 부여됩니다. 권한 장벽은 제거할 수 있지만, 영구적으로 권장되는 권한 모델은 아닙니다. 대신 설치된 Immich 패키지에 필요한 UID/GID와 스토리지 권한을 확인하세요.
PostgreSQL 데이터베이스를 적합한 파일 시스템에 유지하세요
사진 에셋을 대용량 HDD로 옮긴다고 해서 모든 Immich 구성 요소를 그곳에 두어야 하는 것은 아닙니다. 현재 Immich 요구 사항에 따르면 PostgreSQL 데이터베이스는 로컬 SSD 스토리지에 두는 것이 이상적이며, 일반적인 Unix 소유권/권한 의미 체계를 지원하는 파일 시스템이 필요합니다. NTFS와 exFAT는 데이터베이스 데이터 디렉터리에 지원되지 않습니다.
Immich 설치 요구 사항을 참조하세요.
즉, 안정적인 SSD 저장소에 Immich 데이터베이스와 앱 상태를 유지하면서 훨씬 더 큰 사진/동영상 업로드 위치는 적합한 보조 디스크에 배치하는 합리적인 아키텍처를 구성할 수 있습니다.
기존 Immich 데이터를 다시 구축하거나 이동하기 전에 백업하세요
현재 Immich 문서에서는 데이터베이스와 파일 시스템 에셋을 모두 보호할 것을 권장합니다. 데이터베이스 백업만으로는 원본 사진과 동영상이 포함되지 않습니다.
더 안전한 문제 해결 순서
- ZimaOS에 설치된 정확한 Immich 패키지/버전을 확인하세요.
- 현재 호스트-컨테이너 업로드 매핑을 기록하세요.
- 기존 Immich 설치를 변경하기 전에 중요한 사진과 Immich 데이터베이스를 백업하세요.
- 새로 설치할 경우 ZimaOS 패키지에서 허용한다면 최초 초기화 전에 원하는 대용량 저장소 호스트 경로를 선택하세요.
- 해당 패키지에서 정의한 컨테이너 측 경로를 유지하세요.
- 앱 상태가 비정상으로 바뀌면 Immich 로그를 읽고 권한 또는 저장소 무결성 오류를 확인하세요.
- 새 호스트 폴더에 Immich 컨테이너의 사용자 ID로 쓰기 권한이 있는지 확인하세요.
- 누락된 항목이 로그에 언급되면
.immich마커가 언급되면 수동으로 파일을 만들기 전에 마운트와 디렉터리 구조를 확인하세요. - 피하세요
chmod 777영구적인 해결 방법으로 사용하세요.
Immich 시스템 저장소 FAQ
Immich에 시스템 SSD 용량이 계속 표시되는 이유는 무엇인가요?
활성 업로드 바인드 마운트가 여전히 시스템 저장소를 가리키고 있거나, 변경된 마운트가 정상적으로 초기화되지 않았을 수 있습니다. 실행 중인 서버에서 실제로 사용되는 호스트-컨테이너 매핑을 확인하세요.
원래 작성자가 문제를 해결했나요?
예. Solid는 설치 전에 HDD 경로를 선택한 새로 설치한 환경이 설치 후 변경이 적용되지 않았던 경우에도 정상 작동했다고 보고했습니다.
/usr/src/app/upload를 새 Immich 설치로 복사해야 하나요?
무작정 그렇게 하지 마세요. 이는 과거 ZimaOS Immich 2.7.4 패키지에서 사용된 컨테이너 경로였습니다. 현재 업스트림 Immich Compose는 /data. 실제로 실행 중인 패키지/버전을 따르세요.
.immich 파일을 수동으로 만들어야 하나요?
먼저 누락된 이유를 확인한 후에만 가능합니다. 현재 Immich 문서에 따르면 이러한 마커는 특정 복구 상황을 제외하고 일반적으로 수동으로 만들거나 삭제해서는 안 됩니다.
데이터베이스를 exFAT USB 드라이브에 저장해도 되나요?
현재 Immich 요구 사항에서는 PostgreSQL 데이터 디렉터리에 exFAT/NTFS를 지원하지 않습니다. 데이터베이스는 적합한 로컬 파일 시스템에 유지하고, 필요한 경우 사진 에셋은 별도로 이동하세요.
