2026 年 3 月時点の元のユーザーは、128 GB NVMe システムディスクと USB 接続のハードドライブ 3 台を搭載した HP T640 シンクライアントで、初めての NAS を構築していました。写真を 1 台の外付けディスクに保存し、2 台目のディスクにバックアップし、Plex メディアを別の 4 TB ドライブに置く計画は妥当でした。主な障害は USB ストレージが使用できなかったことではありません。アプリのボリュームマッピングが誤って編集されたため、Immich が停止したのです。
このスレッドのストレージ機能に関する部分には、現在のバージョンとの境界も明記する必要があります。2026 年 3 月時点では、ユーザーと回答者は USB ドライブを内蔵ストレージよりも制限の多いものとして扱っていました。現在の ZimaOS のドキュメントでは、USB ドライブは内蔵 HDD/SSD と同じストレージロジックに従い、ストレージとして使用したり、アレイに追加したり、既存の容量を拡張したりできると明示されています。
元の NAS は USB ストレージに完全に依存していた
構成は次のとおりでした：
- AMD R1505G、8 GB RAM、128 GB NVMe を搭載した HP T640 シンクライアント。
- 別々の USB ケースに収めた 2.5 インチ Seagate HDD 2 台。
- Plex メディア用の 4 TB WD 外付け HDD 1 台。
シンクライアントには使いやすい内蔵ドライブベイがなかったため、ユーザーは USB ストレージを一時的なリムーバブルメディアではなく、主要な NAS ストレージとして機能させる必要がありました。
ドライブは USB ストレージとして認識されていた
ユーザーは、外付けドライブを内蔵ストレージのように扱ったり、RAID に使用したりできないと考えていました。これは現在の ZimaOS のストレージモデルではなく、2026 年 3 月時点の環境での動作と認識を反映したものでした。
現在の ZimaOS では USB ドライブを通常のストレージとして扱う
現在の IceWhale のドキュメントでは、USB ドライブは内蔵 HDD や SSD と同じロジックに従い、単体ストレージとして使用したり、アレイに追加したり、既存の容量を拡張したりできると説明されています。
USB ドライブについては、古い「USB RAID は一律にサポートされない」という前提で新しいシステムを構築するのではなく、現在の ZimaOS のストレージワークフローを使用してください。
Immich の障害は、ファイルとディレクトリのマッピングエラーでした
元のユーザーが Immich のボリューム設定を変更したところ、Docker は次のマウントに失敗したというエラーを返しました：
/media/Photos/Immich
→ /etc/localtime/etc/localtime コンテナ内ではファイルであり、写真ライブラリのディレクトリではありません。そのため Docker は、そのファイルの上にフォルダーをマウントしようとした操作を拒否しました。
/etc/localtime ファイルマッピング。写真ストレージと /etc/localtime は別々のマウントとして保持する
コミュニティの回答者は、2つの役割を正しく分けていました。
- 写真のホストフォルダー → Immichのアップロード／データディレクトリ；
- ホスト
/etc/localtimeファイル → コンテナ/etc/localtimeファイル。
現在のDockerのバインドマウントルールでも、ソースと宛先の種類を一致させる必要があります。ディレクトリをファイルの上に、あたかも相互に交換可能であるかのようにマウントすることはできません。
/DATAのバインドマウントによる回避策は、過去のコミュニティによる提案でした
回答者はさらに、 /DATA そして、外付けディスクは再起動後にアプリケーションが起動した時点でまだ準備できていない可能性があるため、そこにUSBパスをバインドマウントする
これは元のバージョン向けのコミュニティガイダンスでした。現在のZimaOSでは管理対象USBストレージのサポートが強化されているため、新規インストールではカスタムの起動時バインドマウントを作成するのではなく、まずストレージUIとアプリの管理対象ボリュームピッカーを使用してください。
Immichはデバイスの生パスではなく、管理対象ストレージを参照させる
現在のZimaOSでは、システムドライブを圧迫するのではなく、アプリケーションデータや大容量メディアライブラリを、それらを保存するために指定したストレージ領域に置くことを推奨しています。ZimaOSで選択したホストパスを使用し、Immichが想定するコンテナ側のパスは維持してください。
現在のアプリケーションマッピングについては、ZimaOSのアプリストレージパスモデルで、ホストパスとコンテナパスの対応関係を説明しています。
RAIDとバックアップは今でも別の問題を解決します
現在のZimaOSではUSBドライブをアレイで使用できますが、RAID 1は2つ目の独立したバックアップの代わりにはなりません。1つのアレイ内の2台のUSBディスクはメンバーディスクの故障からは保護しますが、誤削除、マルウェア、エンクロージャーやコントローラーの問題、NAS全体の損失からは保護しません。
ストレージ機能が変更された現在でも、追加のコピーを保持するという元のユーザーの考えは有用です。
PlexのメディアはImmichのアプリケーション状態より単純
ユーザーは、動画コンテンツを置き換えられるため、4 TBのPlexドライブを使い捨てと考えていました。これは合理的なリスクの区別です。メディアファイル、Immichの写真、Immichのデータベース状態、アプリケーション設定は、必ずしも同じ冗長化やバックアップポリシーにする必要はありません。
外付けUSBストレージに関するよくある質問
現在のZimaOSでは、USBドライブを管理対象ストレージとして使用できますか？
はい。現在のストレージドキュメントでは、USBドライブをストレージおよびアレイのメンバーとして明示的にサポートしています。
ディレクトリを変更した後、Immichが失敗したのはなぜですか？
写真フォルダーが誤ってコンテナの /etc/localtime ファイルパス。
現在のユーザーは、すべてのUSBドライブに手動で /DATA のバインドマウントを作成すべきですか？
いいえ。それは過去のコミュニティによる回避策です。まずは現在の管理対象ストレージとアプリボリュームの設定を使用してください。
