커뮤니티 솔루션

ZimaOS에서 Immich용 외장 드라이브 마운트하기

A ZimaOS user could not create traditional /mnt mount points for four USB-connected HDDs. The thread clarified ZimaOS storage paths, Docker host/container mappings, and the two-step process for exposing an external drive to Immich.

If ZimaOS returns ZimaOS가 다음을 반환한다면mkdir: cannot create directory '/mnt/...': Read-only file system /mnt , 외부 디스크 자체에 문제가 있다고 단정하지 마세요. 2025년 10월 IceWhale 커뮤니티 스레드에서 사용자는 일반적인 Linux 방식을 적용하고 있었습니다.

ZimaOS의 워크플로에 적용하는 방식이며, 시스템 파일 시스템과 저장소 레이아웃이 다르게 관리됩니다.

이 스레드에서 얻을 수 있는 가장 유용한 교훈은 두 가지 작업을 분리하는 것입니다. 먼저 ZimaOS에 외장 HDD를 위한 안정적인 호스트 경로가 있는지 확인한 다음, 해당 호스트 경로를 Immich 컨테이너에 매핑해야 합니다. Immich는 컨테이너 내부에 존재하는 외부 라이브러리 경로만 검증할 수 있습니다. 현재 Immich 문서도 여전히 동일한 Docker 원칙을 따르지만, 더 이상 과거의 컨테이너 경로인 /external_library를 특정해서 요구하지는 않습니다.

커뮤니티 사례에서 /mnt가 읽기 전용이었던 이유

원 작성자는 다음 항목을 만들려고 했습니다.
/mnt/terrabay1
/mnt/terrabay2
/mnt/terrabay3

/mnt/terrabay4

하지만 ZimaOS는 다음 메시지를 반환했습니다.

mkdir: cannot create directory '/mnt/terrabay4': Read-only file system /media Zima-Giorgio는 전문가의 안내를 받거나 테스트 환경에서 작업하는 경우가 아니라면 ZimaOS 시스템 파일을 직접 수정하지 말라고 권고했습니다. 같은 답변에서는 ZimaOS가 관리하는 드라이브와 공유 폴더는 일반적으로 다음 경로 아래에 표시된다고 설명했습니다.

터미널에서 목록을 확인할 수 있습니다.

ZimaOS가 이미 드라이브를 마운트한 방식 확인 /etc/fstab마운트를 해제하거나 편집하기 전에

lsblk -f
ls /media
현재 저장소 상태를 확인합니다.

df -h

원본 스레드에서 ZimaOS는 이미 다음과 유사한 경로를 통해 네 개의 디스크를 노출하고 있었습니다.
/media/sdb-ata-ST2000VN003-3CW1

/media/sdc-ata-ST2000VN003-3CW1

드라이브가 이미 ZimaOS를 통해 안정적으로 마운트되어 있다면, 수동으로 다시 마운트할 필요가 전혀 없을 수 있습니다. 가장 간단한 Immich 설정은 기존 ZimaOS 호스트 경로를 Docker 볼륨 매핑의 왼쪽 항목으로 사용하는 것입니다.

작성자가 공유한 과거의 수동 마운트 방법 /etc/fstab 원 작성자는 결국 UUID 기반 수동 방법을 문서화했습니다. 아래의 항목과 마운트 지점/DATA

sudo mkdir -p /DATA/Enclosure/Bay1
sudo mount /dev/sdb /DATA/Enclosure/Bay1

그런 다음 다음 명령을 실행합니다. /etc/fstab 실제 디스크 UUID를 사용한 줄:

UUID=YOUR-REAL-UUID /DATA/Enclosure/Bay1 ext4 defaults,nofail,x-systemd.automount 0 0

다음 명령을 실행한 후:

sudo systemctl daemon-reload
sudo mount -a

이는 2025년 ZimaOS에서 사용된 커뮤니티 해결 방법일 뿐, 현재 모든 경우에 적용되는 일반적인 권장 사항은 아닙니다. 다음과 같은 스레드의 UUID나 장치 이름을 그대로 복사하지 마세요. /dev/sdb; 이는 해당 사용자의 하드웨어에 속하며 변경될 수 있습니다.

원래 문제에는 작은 입력 오류가 있었습니다

작성자는 나중에 Apple 메모가 복사한 일부 명령줄의 첫 글자를 자동으로 대문자로 변경했다는 사실을 알게 되었습니다. Linux 명령과 경로는 대소문자를 구분하므로, 다음과 같이 복사된 명령은 Mkdir 대신 mkdir또는 대소문자가 변경된 경로를 사용하면 실패합니다.

터미널 명령을 준비할 때는 일반 텍스트 편집기를 사용하고, 붙여넣기 전에 대소문자를 확인하세요.

Immich 외부 라이브러리에는 별도의 두 단계가 필요합니다

이후 답변에서는 다음과 같이 구조를 명확히 설명했습니다:

  1. ZimaOS/Docker: 외부 HDD의 호스트 경로를 immich-server 컨테이너에 매핑하세요.
  2. Immich: 1단계에서 사용한 컨테이너 측 경로로 외부 라이브러리를 만드세요.

2단계만 수행하면 경로가 컨테이너 내부에 존재하지 않기 때문에 Immich 검증이 실패합니다.

2025년 ZimaOS 예시에서는 /external_library를 사용했습니다

커뮤니티 회원 sny는 개념적으로 다음과 같은 매핑을 사용했습니다:

ZimaOS 호스트 경로: /media/USB_1/sny
Immich 경로:      /external_library
컨테이너에 매핑된 외부 USB 경로를 표시하는 ZimaOS Immich 설정
커뮤니티 예시에서는 기존 ZimaOS 호스트 경로를 Immich 컨테이너에 매핑한 후 외부 라이브러리로 추가했습니다.

그런 다음 Immich에서 사용자는 다음을 추가했습니다:

/external_library

을 외부 라이브러리 가져오기 경로로 사용합니다.

컨테이너 측 가져오기 경로를 검증하는 Immich 외부 라이브러리 구성
Immich는 원래 ZimaOS 호스트 경로가 아니라 컨테이너 내부에서 보이는 경로를 검증합니다.

현재 Immich에는 /external_library라는 이름이 필요하지 않습니다

현재 Immich 문서는 더 유연합니다. 공식 외부 라이브러리 가이드에는 다음과 같이 호스트 및 컨테이너 경로를 임의로 지정하는 예가 나와 있습니다:

immich-server:
  volumes:
    - /home/user/photos1:/home/user/photos1:ro
    - /mnt/photos2:/mnt/photos2:ro

중요한 규칙은 Immich에 입력하는 경로가 컨테이너 측 경로와 정확히 일치해야 한다는 것입니다. 이름 /external_library 이는 ZimaOS 커뮤니티 예시에서 편의상 사용한 규칙일 뿐, Immich에서 요구하는 사항은 아닙니다.

아카이브 라이브러리에는 읽기 전용 마운트를 우선 사용하세요

현재 Immich 문서에서는 다음을 추가할 것을 권장합니다 :ro 외부 라이브러리를 Immich에서 읽기만 해야 하는 경우:

/host/photos:/external_library:ro

Immich가 외부 자산을 삭제하거나 XMP 사이드카 메타데이터를 작성하도록 의도한 경우에만 읽기 전용 모드를 해제하세요. 읽기 전용 아카이브 마운트를 사용하면 애플리케이션이 원본 파일을 수정할 위험을 줄일 수 있습니다.

여러 외부 라이브러리

커뮤니티에서는 다음과 같이 컨테이너 경로를 분리하자고 제안했습니다:

/external_library/usb1
/external_library/usb2
/external_library/photos

현재 Immich는 여러 마운트 지점도 지원합니다. 각 라이브러리 경로는 다음 위치에 마운트되어야 합니다. immich-server 그런 다음 Immich의 외부 라이브러리 관리 페이지에서 추가합니다.

Immich는 외부 라이브러리 사진을 기본 라이브러리로 복사하나요?

아니요. 현재 Immich 문서에서는 외부 라이브러리를 원래 파일 시스템 위치에 그대로 남아 있는 에셋으로 설명합니다. Immich는 이를 스캔하고 메타데이터를 색인하며, 데이터베이스 레코드와 썸네일 같은 파생 에셋을 생성한 뒤 타임라인에 표시합니다.

외부 파일이 디스크에서 사라지면 재스캔 후 Immich가 해당 에셋을 누락된 것으로 표시하거나 휴지통으로 이동할 수 있습니다. 외부 드라이브는 별도로 백업해 두세요.

ZimaOS에서 /etc/fstab 편집 시 주의

원문 스레드의 수동 방식은 안정적인 드라이브 경로를 만드는 데까지는 작동했지만, 작성자는 이후 추가적인 USB 및 마이그레이션 문제를 보고했습니다. 잘못된 /etc/fstab 항목은 부팅을 방해하거나 저장소를 사용할 수 없게 만들 수도 있습니다.

ZimaOS가 이미 디스크를 관리하고 안정적인 경로를 제공한다면 /media/... 경로가 있다면, 호스트의 저장소 구성을 불필요하게 다시 만들지 말고 Immich 바인드 마운트에 기존 경로를 사용하는 편이 좋습니다.

ZimaOS Immich 외부 드라이브 체크리스트

  1. 다음을 확인하세요. lsblk -f, ls /media, 그리고 먼저 ZimaOS 저장소를 확인하세요.
  2. 기존 방식을 사용해야 한다고 단정하지 마세요. /mnt 마운트 지점.
  3. 이미 ZimaOS가 관리하는 호스트 경로가 있다면 해당 경로를 우선 사용하세요.
  4. 호스트 경로를 다음 위치에 매핑하세요. immich-server 컨테이너.
  5. 다음과 같이 명확한 컨테이너 경로를 사용하세요. /external_library/photos.
  6. 다음을 사용하세요. :ro Immich가 아카이브를 읽기만 하면 될 때
  7. Immich 관리 → 외부 라이브러리에서 정확한 컨테이너 경로를 추가하세요.
  8. 새 라이브러리를 스캔하고 작업이 실행 중인지 확인하세요.
  9. 외부 라이브러리의 원본 파일은 Immich와 별도로 백업하세요.

ZimaOS Immich 외부 드라이브 FAQ

ZimaOS에서 /mnt/terrabay1을 만들 수 없는 이유는 무엇인가요?

원문 사례에서는 ZimaOS 시스템 파일 시스템이 해당 위치에 대한 쓰기를 거부했습니다. ZimaOS는 이미 자체 저장소 경로를 통해 외부 저장소를 관리하고 있었으며, 여기에는 다음과 같은 경로도 포함됩니다. /media.

/etc/fstab을 편집해야 하나요?

항상 그런 것은 아닙니다. 원문 작성자는 사용자 지정 UUID 기반 마운트 구성을 위해 fstab을 사용했지만, ZimaOS가 이미 드라이브를 안정적으로 마운트하고 있다면 기존 호스트 경로를 사용하는 편이 더 간단하고 변경도 적습니다.

Immich 경로는 반드시 /external_library여야 하나요?

아니요. 그것은 ZimaOS 커뮤니티의 관행이었습니다. 현재 Immich에서는 외부 라이브러리 설정에 동일한 컨테이너 경로를 입력하기만 하면 임의의 마운트 경로를 사용할 수 있습니다.

Immich 외부 라이브러리는 원본 파일을 복사하나요?

아니요. 파일은 원래 외부 위치에 그대로 남아 있으며, Immich는 파일을 색인하고 관련 메타데이터와 파생 에셋을 생성합니다.