ZimaOS Immich 外付けドライブ：マウントとライブラリの設定

ZimaOSが次のように返した場合 mkdir: cannot create directory '/mnt/...': Read-only file system、外部ディスク自体が壊れていると決めつけないでください。2025年10月のIceWhaleコミュニティスレッドでは、ユーザーは従来のLinux /mnt ZimaOSのワークフローでは、システムファイルシステムとストレージ構成が異なる方法で管理されています。

このスレッドから得られる最も重要な教訓は、2つの作業を分けることです。まず、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

Zima-Giorgioは、専門家の指導の下、またはテスト環境以外では、ZimaOSのシステムファイルを直接変更しないよう注意しました。同じ返信では、ZimaOSが管理するドライブや共有は通常、次のようなパス配下に表示されるとも指摘されています /media ターミナルから一覧表示できます。

ZimaOSがすでにドライブをどのようにマウントしているかを確認する

アンマウントまたは編集を行う前に /etc/fstab現在のストレージ状態を確認します：

lsblk -f
ls /media
df -h

元のスレッドでは、ZimaOSがすでに4台のディスクを、次のようなパスで公開していました：

/media/sdb-ata-ST2000VN003-3CW1
/media/sdc-ata-ST2000VN003-3CW1

ZimaOSを通じてドライブがすでに安定してマウントされている場合は、手動で再マウントする必要はまったくないかもしれません。最も簡単なImmichの設定は、多くの場合、既存のZimaOSホストパスをDockerボリュームマッピングの左側に指定する方法です。

著者が共有した、過去の手動マウント方式

元の著者は最終的に、UUIDベースの手動方式を文書化しました /etc/fstab 以下のエントリとマウントポイント /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；これはそのユーザーのハードウェアに固有のもので、変更される可能性があります。

元の問題の一部は単純な入力ミスでした

The author later discovered that Apple Notes had automatically capitalized the first character of some copied command lines. Linux commands and paths are case-sensitive, so a command copied as Mkdir instead of mkdir, or a path with changed capitalization, will fail.

When preparing terminal commands, use a plain-text editor and verify capitalization before pasting.

Immich External Libraries Require Two Separate Steps

The later replies clarified the architecture:

ZimaOS/Docker: map the external HDD's host path into the immich-server container.
Immich: create an External Library using the container-side path from step 1.

If only step 2 is performed, Immich validation fails because the path does not exist inside its container.

The 2025 ZimaOS Example Used /external_library

Community member sny used a mapping conceptually like:

ZimaOS host path: /media/USB_1/sny
Immich path:      /external_library

ZimaOS Immich settings showing an external USB path mapped into the container — The community example mapped an existing ZimaOS host path into the Immich container before adding it as an external library.

Then in Immich the user added:

/external_library

as the External Library import path.

Immich external library configuration validating the container-side import path — Immich validates the path visible inside the container, not the original ZimaOS host path.

Current Immich Does Not Require the Name /external_library

Current Immich documentation is more flexible. Its official External Library guide shows arbitrary host and container paths, for example:

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外付けドライブチェックリスト

次を確認します lsblk -f, ls /mediaまずはZimaOS Storageを確認します。
従来の方法が必要だと決めつけず、 /mnt マウントポイント。
すでに存在する場合は、ZimaOSが管理するホストパスを優先します。
ホストパスを次の場所にマッピングします immich-server コンテナ。
次のような分かりやすいコンテナパスを使用します /external_library/photos.
を使用します :ro Immichがアーカイブを読み取るだけでよい場合
Immichの「管理」→「外部ライブラリ」で、正確なコンテナパスを追加します。
新しいライブラリをスキャンし、ジョブが実行されていることを確認します。
外部ライブラリのオリジナルファイルは、Immichとは別にバックアップしてください。

ZimaOSでのImmich外付けドライブに関するFAQ

ZimaOSで /mnt/terrabay1 を作成できないのはなぜですか？

元のケースでは、ZimaOSのシステムファイルシステムがそこへの書き込みを拒否しました。ZimaOSはすでに、以下を含む独自のストレージパスを通じて外部ストレージを管理していました。 /media.

/etc/fstabを編集する必要がありますか？

必ずしもそうではありません。原作者はカスタムUUIDベースのマウント構成にfstabを使用していましたが、ZimaOSがすでにドライブを安定してマウントしているなら、既存のホストパスを使うほうが簡単で変更も少なくて済みます。

Immichのパスは必ず /external_library でなければなりませんか？

いいえ。それはZimaOSコミュニティでの慣例でした。現在のImmichでは、External Library設定に同じコンテナパスを入力する限り、任意のマウントパスを使用できます。

Immichの外部ライブラリはオリジナルをコピーしますか？

いいえ。ファイルは元の外部ロケーションに残り、Immichはそれらをインデックス化して、関連するメタデータと派生アセットを作成します。