immichってなんなのかを簡単に説明すると、自宅内で写真と動画を管理することが出来るサービスです。
自宅内なので、自分で管理出来るよ!!というユーザーは少なくないかと思います。
このサービスは各個人が管理するというより、家族や身内間で管理するという感じになります。
家族や身内には一定の操作スキルが求められますが、ファイルバックアップなどの知識は不要です。
管理者となる方が代表でバックアップ知識を保有していればよいのです。
クラウドサービスを使う方が一般的ですが、自宅内管理であるため容量制限やネットワーク制限が特にありません。
これが一番のポイントでしょうか。
写真は設定したアルバム毎に管理され、第三者に日数制限付きで公開することも可能です。
Synology の NAS でも immich の導入が可能なようです。
今回は下記の自作NASに、写真と動画ファイルを管理するサービスを入れようと思いました。
試しに使ってみたら、自身の理想の8割くらい網羅出来ている感じでした。
観点としては主に下記のような感じ。
- 既に画像や動画ファイルを管理しているストレージがあり、変更せずにそのまま取り込める。
- 取り込んだストレージから自身の領域にコピーすることがない。
- サムネイル作成の領域は別のディレクトリ領域で作成する。
- 登録ユーザーで画像や動画ファイルを共有出来る。
- スマートフォンアプリに対応し、Googleストレージのようにバックアップ用途としても使用可能。
写真枚数が3桁以下くらいならアリ、写真枚数が4桁以上あるとアルバム作成と割り当てが大変
完全に主観なのですが、少し使ってみての感想を挙げてみます。
不便だと思ったこと。
- 取り込んだ画像の付帯情報が表示出来ない。例えばディレクトリ名などが見えない。NAS上にディレクトリ毎に写真管理してた場合、取り込んだ後にアルバム作成する必要があるが、ディレクトリ名から写真選択が一切出来ないので、1枚ずつ目視で選択していく必要がある。つまり、別システムから取り込んだ際のデータ紐付けの難易度が高い。大量に写真がある場合にかなりシンドい。
- アルバム作成時に、既にアルバム選択した写真を除外することが出来ない。大量に写真データがあると目視となるため選定でかなり疲れる。
- 上記に絡むが、アルバム作成時の写真選択時に付帯情報でのフィルター検索などが出来ないので、絞り込みが非常に大変。
- 現段階だと追加したアルバムに対してタグ設定が出来ない。追加したアルバムが大量にあると割と埋もれるので、探すのが大変になる。
- オンラインストレージと比べると、データバックアップは自分で行う必要がある。
- immichのアップデートに失敗するとサービス起動出来なくなる。公式の見解から321バックアップが必須。
- スマートフォンアプリがあるが、自宅ネットワーク専用。外出先から操作するものではない。外出先からの場合は自宅VPN設定が必須か。
優秀だと思ったこと。
- 家族・親族・友人などでアルバムをシェアすると非常に便利と感じた。例えばイベントだったり旅行だったりなどのアルバムを最初に作成しておき、関係者にシェア用URLを送りWEBブラウザからアクセスしてもらう。イベントや旅行先で撮った写真や動画をアップロードしてもらえば関係者間でファイルの共有が出来る。クラウドストレージのシェア機能と同じような感じかなと。ただしコレは外部公開設定(WEBサービスの導入とSSL証明書の導入)が必要。導入難易度も高いです。
- 自宅に接続設定が出来る環境であれば、WEB画面ではなくスマートフォンアプリからアクセス可能。スマートフォンの写真を手軽にアップロードが可能。
- スマートフォンアプリでGoogleストレージのようにバックアップ用途で使用可能。
- 取り込んだ写真は顔認証の解析が入るため、顔写真で関連写真を検索表示出来ること。
immichの読み方???
Google翻訳だとイミッチ。
Youtubeによる各国の発音を聞いてみると、イメッチ、イミッチ、イムッチなど。
結構ブレがあるけれど、Google翻訳の通りイミッチでいいのかな?
immichの公式サイトにデモがあります。
公式サイトは下記にあります。
Open Demoをクリックすると実際に触りの部分を体験することが出来ます。
このページでのみ確認したい場合は、下部の「登録ユーザーが操作するWEB画面について」項目でザックリご紹介しています。
基本無料です。
無料で使用できるものですが、サーバーライセンス、ユーザーライセンスとして課金は可能です。
ドネーションウェア(寄付による課金)と同じような扱いだと思われます。
登録ユーザーが操作するWEB画面について
■ 自身のアップロード写真・動画ファイル領域
WEBブラウザやスマートフォンアプリで写真や動画ファイルをアップロードすると、日付毎に溜まって行きます。
ファイルをアップロードすると下記のような感じになります。
大量のファイルが溜まりますので、必要に応じてアルバムとして新規作成してファイルを紐付けていく必要があります。
■ アルバム
自分で作成したアルバムや共有設定になっているアルバムが表示されます。
アルバムをクリックすると、割り当てられている写真が表示されます。
自身のユーザー領域に写真や動画をアップロード済みの場合、その対象をアルバムに追加することも可能です。
アルバム作成したユーザーであれば、アルバム管理者となれます。
管理者の操作として共有リンクを作成することが出来ます。
immich内の登録ユーザーに対する共有なのか、外部の一般ユーザー向けの共有なのかを選べます。
一般ユーザー向けの共有は外部公開設定(WEBサービス+SSL証明書)が完了している場合に使える機能です。
共有リンクとしてはそれなりに自由に設定が可能です。
文字パスワードの設定を行い、パスワードを通知した人のみアクセスが出来たりします。
有効期限は「無し、30分、1時間、6時間、1日、7日、30日、3ヶ月、1年」の中から選べます。
アルバムに対して、ダウンロードやアップロード権限についても設定が可能です。
リンクを作成すると下記のようにQRコードとURLリンクが発行されます。
セットアップについて
公式のDockerコンテナで導入するか、Proxmox VE内で「Proxmox VE Helper-Scripts」という1行コマンドを実行すると導入出来ます。
個人的にDockerは運用方法がよく分からなくて挫折した人間なのでDockerでの導入は行わず。
「Proxmox VE Helper-Scripts」で簡単セットアップです。
下記に公式のスクリプト配布があります。
https://community-scripts.github.io/ProxmoxVE/scripts?id=immich&category=Media+%26+Streaming
自分の環境では /opt/immich/.env の「IMMICH_MEDIA_LOCATION=/opt/immich/upload」で指定されているパスを NAS の NFS領域 としてマウントして上書きすることで、登録ユーザーがアップロードしたファイルを外出しにして分離しています。
外部ライブラリは別で NAS 上の samba 領域の一部を指定しています。
ただし、現段階では「MACHINE_LEARNING_CACHE_FOLDER=/opt/immich/cache」について何もしていません。
キャッシュ領域のため、必要であれば再作成すればよいと考えています。
もし、容量が肥大化するようであれば、仮想ディスクを割り当てて対処しようと思います。
公開共有向けにWEBサービスを構築してSSL証明書を導入
WEBサーバーの運用歴のある方なら、問題なく作業が出来るかと思います。
初心者だとハードルは高いかもしれません。
作業前にOSバックアップやスナップショットの取得を行ったほうがよいです。
・WEBサービスの選定
Nginxを使用する方法など、公式サイトでアナウンスがあります。
https://docs.immich.app/administration/reverse-proxy/
・WEBサービスの導入
Nginxの導入については下記を参考にした。
https://www.server-world.info/query?os=Debian_13&p=nginx&f=1
・SSL証明書の導入+設定
下記を参考にしつつ、SSL証明書は無償利用出来る Let's Encrypt を利用した。
別途、ルーターのポート開放などの対応が必要。
https://www.server-world.info/query?os=Debian_13&p=ssl&f=2
・ドメインの登録+設定
同じく無償利用としてMyDNS JPでドメインの登録を行い、更新スクリプトも導入した。
色々と対応したような気がしますが、だいたいこのくらいの設定になるかと思います。
nginx向けのセキュリティ対策
※セキュリティ向上のため内部的に日々変更しているので、下記に記載した内容は古いです。あまり鵜吞みにしないようにお願いします。
■ 正規手段のクロール拒否設定
正規のやり方を行っているクロール処理について対応可能。(大手検索エンジンなどは対策は可能だが、マナーを守らない野良クロールは対処不可)
参考URLをもとに下記を設定しました。
- robots.txt の設置
- index.htmlの<META> タグの記述
参考:https://www.just-size.net/support/tips_searchdeny.php
■ 国内アクセスのみ許可する設定
参考URLをもとに、nginxにGeoIP2モジュールを導入し、日本アクセス以外を除外するようにしてセキュリティ向上を試みました。
国内のIPアドレスの一覧を用意して一致しない国外IPアドレスだったら拒否というやり方もありますが、国内IPアドレスを常に更新してメンテナンスする必要があります。
・MAXMINDアカウントを作成する
https://www.maxmind.com/en/geolite2/signup
・アカウントプロファイルにアクセスし、新しいキーを作成する。
[Manage license keys]をクリック
[Generate new license key]をクリック
下記を入力する。
License key description:Nginx
Account ID、License keyが発行されるので、内容を控えておく。
[Download Config]をクリックし、GeoIP.confをダウンロードしておく。
・Teratermなどからコンソールに下記コマンドを実行する
# apt install geoipupdate
・下記ファイルにダウンロードしたGeoIP.confの中身を置き換える。
# vi /etc/GeoIP.conf
# `AccountID` is from your MaxMind account.
AccountID xxxxxxx
# `LicenseKey` is from your MaxMind account.
LicenseKey xxxxxxxxxxxxxxxxxxxxxxxxx
# `EditionIDs` is from your MaxMind account.
EditionIDs GeoLite2-ASN GeoLite2-City GeoLite2-Country
・GEOIP2 のデータベースを更新
# geoipupdate -v
# ls -la /var/lib/GeoIP/
合計 81356
drwxr-xr-x 2 root root 4096 10月 12 17:53 .
drwxr-xr-x 27 root root 4096 10月 12 17:49 ..
-rw------- 1 root root 0 10月 12 17:53 .geoipupdate.lock
-rw-r--r-- 1 root root 10906593 10月 12 17:53 GeoLite2-ASN.mmdb
-rw-r--r-- 1 root root 62492941 10月 12 17:53 GeoLite2-City.mmdb
-rw-r--r-- 1 root root 9891879 10月 12 17:53 GeoLite2-Country.mmdb
・nginx向けGEOIP2 モジュールのインストール
# apt install libnginx-mod-http-geoip2
・nginx 構成ファイル(nginx.conf)を編集
# vi /etc/nginx/nginx.conf
http {
・・・
##
# Gzip Settings
##
gzip on;
gzip_types text/plain text/css application/json application/javascript text/xml application/xml application/xml+rss text/javascript;
##
# GEOIP2 Settings
##
geoip2 /var/lib/GeoIP/GeoLite2-Country.mmdb {
auto_reload 60m;
$geoip2_metadata_country_build metadata build_epoch;
$geoip2_data_country_code country iso_code;
$geoip2_data_country_name country names en;
}
# JP判定
map $geoip2_data_country_code $allowed_country {
default no;
JP yes;
}
# ローカルネットワーク判定
geo $remote_addr $allowed_local {
default no;
192.168.0.0/16 yes; # 各自のローカルネットワークに合わせる
}
# GeoIP情報を含むカスタムログフォーマット
log_format geoip_combined '$remote_addr - $remote_user [$time_local] '
'"$request" $status $body_bytes_sent '
'"$http_referer" "$http_user_agent" '
'Country:$geoip2_data_country_code';
・・・
}
・Nginx 構成ファイル(/etc/nginx/sites-enabled/default-ssl.conf)を編集
# HTTP(80番→443番)のリダイレクト
server {
listen 80;
server_name xxxxxxx; # 各自の環境に合わせる
return 301 https://$host$request_uri;
}
# HTTPS(443番→2283番にproxy)
server {
listen 443 ssl;
server_name xxxxxxx; # 各自の環境に合わせる
root /var/www/html;
index index.html;
# SSL設定 パスは各自の環境に合わせる
ssl_certificate /etc/letsencrypt/live/xxxxxxx/cert.pem;
ssl_certificate_key /etc/letsencrypt/live/xxxxxxx/privkey.pem;
# 実際のクライアントIP取得設定
set_real_ip_from 192.168.0.0/16; # 自宅ネットワークの範囲
real_ip_header X-Real-IP;
real_ip_recursive on;
# 国情報付きのログ
set $deny_log 0;
access_log /var/log/nginx/access.log geoip_combined;
# allow large file uploads
client_max_body_size 50000M;
# 日本からのアクセスを許可
set $allowed 0;
if ($allowed_country = yes) {
set $allowed 1;
}
# ローカルネットワークからのアクセスを許可
if ($allowed_local = yes) {
set $allowed 1;
}
# Let's Encrypt challenge pathは例外
if ($uri ~* "^/\.well-known/acme-challenge/") {
set $allowed 1;
}
# 許可されていない場合は接続を切断
if ($allowed = 0) {
set $deny_log 1;
return 444; # 接続を即座に切断
}
# Set headers
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
# enable websockets: http://nginx.org/en/docs/http/websocket.html
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";
proxy_redirect off;
# GeoIP情報をバックエンドに転送
proxy_set_header X-GeoIP-Country-Code $geoip2_data_country_code;
proxy_set_header X-GeoIP-Country-Name $geoip2_data_country_name;
proxy_set_header X-Real-IP $remote_addr;
# set timeout
proxy_read_timeout 600s;
proxy_send_timeout 600s;
send_timeout 600s;
location / {
proxy_pass http://192.168.100.xxx:2283; # immichのアドレス
}
location = /.well-known/immich {
proxy_pass http://192.168.100.xxx:2283; # immichのアドレス
}
}
JPアクセスもしくはローカルネットワーク以外は444ステータスで除外される。
しかし、除外時のログを記録したいのだが、現在設定方法がよくわからない。
なお、geoipの自動更新が必要かと思ったが、既に導入されていた。
毎週月曜日の6時47分実行のようだ。
一斉にその時刻にアクセスするとサーバーアタック状態になるので10分くらいずらすとよいかもしれない。
# cat /etc/cron.d/geoipupdate
# Regular cron job for the geoipupdate package, used to update GeoIP databases
#
# MaxMind typically updates their databases on Tuesdays.
#
# m h dom mon dow user command
47 6 * * 3 root test -x /usr/bin/geoipupdate && grep -q '^AccountID .*[^0]\+' /etc/GeoIP.conf && test ! -d /run/systemd/system && /usr/bin/geoipupdate
参考:
https://techexpert.tips/ja/nginx-ja/nginx-%E5%9B%BD%E3%81%8B%E3%82%89%E3%81%AE%E3%82%A2%E3%82%AF%E3%82%BB%E3%82%B9%E3%82%92%E3%83%96%E3%83%AD%E3%83%83%E3%82%AF%E3%81%99%E3%82%8B/
https://my-note.net/docker-nginx-proxy-geoip-access-control/
https://cn.teldevice.co.jp/blog/p38813/
https://docs.immich.app/administration/reverse-proxy/
■ Expressヘッダーを非表示する設定
immichはNode.jsのExpressを使用しているようです。
下記の対応で上書き出来ました。
■モジュールのインストール
# apt install libnginx-mod-http-headers-more-filter
■モジュール読み込みの追加
# echo "load_module modules/ngx_http_headers_more_filter_module.so" >> /etc/nginx/modules-available/load_module.conf
■nginx.conf設定でNode.jsのExpressヘッダーの非表示を設定
server {
...
more_clear_headers 'X-Powered-By';
...
}
バージョンアップ(アップデート)が大変?
アップデート内容によって、互換性の無い変更が発生するときがあるようです。
Dockerコンテナで構築するのが一般的なようですが、私の環境はProxmoxのLXCコンテナで作成している環境です。
Proxmoxで下記の「Proxmox VE Helper-Scripts」のImmichを使用している場合、Dockerの知識(設定・運用含む)がなくても簡単にアップデートが出来ました。
事前にコンテナと保存ストレージのスナップショットを作成してからアップデートを行った方がよさそうです。
初期セットアップではProxmoxのホストOS上でスクリプトコマンドを実行するだけでした。
アップデートの時は、ImmichがインストールされたLXCコンテナ上で下記のようなスクリプトコマンドを実行するだけです。
bash -c "$(curl -fsSL https://raw.githubusercontent.com/community-scripts/ProxmoxVE/main/ct/immich.sh)"
下記に正式なコマンドがあります。(上記は年数経過により古くなっている可能性があります)
https://community-scripts.github.io/ProxmoxVE/scripts?id=immich&category=Media+%26+Streaming
コマンドを実行すると、アップデートを行うかどうかの選択肢が表示されます。
通常は1を選択すればよいでしょう。
問題なくアップデートが完了していれば、下記のような感じになる?
再起動などは行わず、そのままImmichのWEB画面を開いてバージョン確認。
問題なくアップデート出来た。簡単!
スクリプトの公式の方にアップデート方法を載せて無いからわからん!って思ってたけど、載ってた。
更新可能(Updateable)にマウスカーソルを当てると、アップデートに関する吹き出しが出てくる。
初見ではわからんって。
現在は Debian13 としてコンテナが作成されているが、Debian14 にアップグレードしたタイミングはLXCコンテナから作り直しが発生するかもしれない。
そのときのアップデート時は要注意かもしれない。まぁ数年後だと思うけど。
[上級者向け] immich の 内部データを弄る
immich の管理データは Postgresql というデータベースソフトに記録されています。
デフォルト設定では immich が稼働しているPC内でしか Postgresql へのアクセスが出来ないようになっています。
設定変更して自宅ネットワーク上の自宅パソコンでもアクセス可能とすれば、管理データを改竄もとい、アルバムデータに都合の良いファイルを当て込むことが出来るのではと考えました。
結論からして、可能でした。
下記のスキルが必要です。
- Postgresql を少しでも触ったことがある
- SQL について多少の知識がある。(CRUD 操作知識くらいは必須)
アルバム(albumテーブル)そのものの新規レコード追加は無理です。(自動採番のIDを採用しており採番体系が不明なため)
アルバムの外側データはWEB画面やスマホアプリでの登録が必要です。
登録時は必ず写真を1枚選択する必要があるので、後始末も含めて少々面倒です。
登録したアルバムIDに、ユーザーが追加した写真(assetテーブルのownerIdがuserテーブルのidと一致)のIDや外部ライブラリとして取り込んだファイル(assetテーブルのdeviceIdがLibrary Import)のIDを紐づけるようにalbum_assetテーブルへ登録すれば、とりあえず行けるようです。
その際にupdateIdを登録する必要がありますが、assetテーブルのupdateIdを一緒に登録すれば問題ないようです。
外部ライブラリとして取り込んだファイルですが、ファイルのフルパス情報もassetテーブルに記録されています。
フォルダー(ディレクトリ)情報もそこから引っ張ってこれるので、うまく割り当てるように登録すればいけます。
ということで、下記のテーブルが関連します。
- albumテーブル(参照)
- assetテーブル(参照)
- album_assetテーブル(レコード追加)
下記を編集することで、Postgresql を自宅内ネットワークのPCで編集することが可能になります。
# vi /etc/postgresql/16/main/pg_hba.conf ※環境にあわせて設定が必要
# IPv4 local connections:
host all all 127.0.0.1/32 scram-sha-256
host all all 192.168.xxx.0/24 scram-sha-256
# vi /etc/postgresql/16/main/postgresql.conf
# - Connection Settings -
listen_addresses = '*' # what IP address(es) to listen on;
[上級者向け] ログファイル関連
LXCで構築した際には、下記にログファイルが格納されます。
/var/log/immich/web.log
ログローテーションの設定がされているか現段階では不明です。
ログの内容を確認すると、毎日0時にシステムチェックなどを行っているようです。
その際に、外部ライブラリとして取り込んだファイルのパスが変更されていたりすると、変更後のパスを追従出来ておらず、エラーが毎日吐かれるようになります。
エラー情報にファイルのフルパスが記載されていますので、上記の「[上級者向け] immich の 内部データを弄る」項目に沿って、同様の作業を行う必要があるようです。
assetテーブルのoriginalPath項目からフルパス内容を当て込んで検索します。
該当レコードであれば、レコード削除していきます。
→ assetテーブルから削除されると、対象が自動的にゴミ箱へ移動されます。WEB画面のゴミ箱にて対象を再度削除することで管理化から外れます。指定日数を超えることで自動的に削除されるため操作しなくても自動で消えます。
Niktoによる脆弱性スキャンと対応
結論からすると、nginxとimmichが脆弱性の塊になりえるので、Niktoを実行すると警告とエラーがそれなりに出力されます。
対策しすぎるとimmichの外部アクセス時に正しく動作しなくなりますので、トライアルアンドエラーで対応していく必要があります。
7~8割くらいはnginx向けの設定でした。
現状、下記の3点が対応出来ていないです。Content-Encodingを設定したいけど、immich内部の解析と修正になりそうです。
+ /: The Content-Encoding header is set to "deflate" which may mean that the server is vulnerable to the BREACH attack. See: http://breachattack.com/
+ /docs/<script>alert('Vulnerable');</script>: Nokia Electronic Documentation is vulnerable to Cross Site Scripting (XSS). See: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2003-0801
+ /api/soap/?wsdl=1: Uncommon header 'x-immich-cid' found, with contents: oer1idxt.
immich内部ファイルの修正
immichのバージョンアップすると、修正ファイルは恐らく元に戻されると思われる。
・/opt/immich/app/www/robots.txt
家族/身内向けとして稼働するのであれば、2~4はコメント化するか削除が必須な気がしています。
これがデフォルトのままだと、検索サイトからアクセスが可能となってしまいます。
とはいえ、/shareや/apiをnginxにてアクセス拒否設定するとimmichが動作しなくなります。
immichは脆弱性の塊
そもそも、公式のやりかたは下記のように提示しており、全てのアクセスをimmichに転送するような方法です。
例えば https://samplehoge.com というWEBサーバーを管理してたとして、そこからのアクセス全てを immich へ転送してしまいます。
server {
location / {
proxy_pass http://<backend_url>:2283;
}
}
下記のように https://samplehoge.com/imm と設定出来ればセキュリティ上望ましいのですが、設定しても immich の方でURL解析出来なくてエラーになります。
server {
location /imm {
proxy_pass http://<backend_url>:2283;
}
}
/immのように設定すること出来るのであれば、そのアドレスのみ許可すればよくて、他のアドレスは拒否が可能になるのです。
悲しいお話で、immich上で管理者ユーザーでログインした際、URLに admin という文字を使用しているところです。ユーザーIDなどではないのです。
例えば https://samplehoge.com/admin/ というようなURLは許可しないと immich へ転送したときにエラー表示が出てしまいます。
admin、administrator、rootなどの用語をURLで使用するのは完全に脆弱性の塊になります。
ソフトウェアの設計上、これはNGと言えます。
運用しているアクセスログを見ると下記のような不正アクセスを試みている内容が出ています。
/api
/app
/backend
/docs
/download
/frontend
/portal
/apiや/docsは immich で使用しているみたいなので、拒否設定が出来ません。
利用する場合は、この脆弱性の対策を考えて運用していかなければなりません。
外部公開は便利なのですが、導入する場合は検討した方がよいと思います。
本当に・・・/immのように設定するが出来ればよいのに。。。
とても残念です。
管理画面で下記の設定が出来ますが、https://xxx.com/imm のように設定出来ないのです。
フォーカスアウトすると/immの部分が消えます。
-
購入金額
0円
-
購入日
2025年09月23日
-
購入場所
immich公式
















ZIGSOWにログインするとコメントやこのアイテムを持っているユーザー全員に質問できます。