13_Immich

Immich-SERVER

High performance self-hosted photo and video management solution.

Image	`ghcr.io/immich-app/immich-server:release`
Version	v2.7.5
Etat	Up (healthy)
Compose project	immich
Reseau	immich_immich-network
URL	https://immich.juxjux.ovh
Source	https://github.com/immich-app/immich

Ports

Hote	Container	IP
8212	2283/tcp	0.0.0.0
8212	2283/tcp	::

Volumes

Source (hote)	Destination	Type	Mode
`/home/debian/docker/immich/upload`	`/data`	bind	rw
`/etc/localtime`	`/etc/localtime`	bind	ro
`/home/debian/docker/immich/upload/encoded-video`	`/mnt/media/encoded-video`	bind	rw
`/home/debian/photo`	`/mnt/media/photo`	bind	ro,shared

Immich-MICROSERVICES

High performance self-hosted photo and video management solution.

Image	`ghcr.io/immich-app/immich-server:release`
Version	v2.7.5
Etat	Up (healthy)
Compose project	immich
Reseau	immich_immich-network
URL	https://immich.juxjux.ovh
Source	https://github.com/immich-app/immich

Volumes

Source (hote)	Destination	Type	Mode
`/home/debian/docker/immich/upload`	`/data`	bind	rw
`/etc/localtime`	`/etc/localtime`	bind	ro
`/home/debian/docker/immich/upload/encoded-video`	`/mnt/media/encoded-video`	bind	rw
`/home/debian/photo`	`/mnt/media/photo`	bind	ro,shared

Immich-LEARNING

High performance self-hosted photo and video management solution.

Image	`ghcr.io/immich-app/immich-machine-learning:release`
Version	v2.7.5
Etat	Up (healthy)
Compose project	immich
Reseau	immich_immich-network
URL	https://immich.juxjux.ovh
Source	https://github.com/immich-app/immich

Volumes

Source (hote)	Destination	Type	Mode
`/home/debian/docker/immich/cache`	`/cache`	bind	rw

Immich-REDIS

Image	`redis:6.2-alpine`
Etat	Up (healthy)
Compose project	immich
Reseau	immich_immich-network
URL	https://immich.juxjux.ovh

Volumes

Source (hote)	Destination	Type	Mode
	`/data`	volume	rw

Immich-DB

Base images for Immich containers

Image	`ghcr.io/immich-app/postgres:16-vectorchord0.3.0-pgvectors0.2.0`
Version	16-vectorchord0.3.0-pgvector0.8.1-pgvectors0.2.0
Etat	Up (healthy)
Compose project	immich
Reseau	immich_immich-network
URL	https://immich.juxjux.ovh
Source	https://github.com/immich-app/base-images

Volumes

Source (hote)	Destination	Type	Mode
`/home/debian/docker/immich/db`	`/var/lib/postgresql/data`	bind	rw

Integration Claude Code — MCP

Statut MCP	MCP actif
Outils (prefix)	`mcp__immich__`
Configuration	Script Python : C:\Users\eliob\.claude\mcp_immich.py \| Auth : JWT via POST /api/auth/login

Outils disponibles

get_assets
get_asset
search_assets
update_asset
get_albums
get_album
create_album
get_people
get_person_assets
get_memories
get_statistics
get_my_user
get_server_info

Ce que nous pouvons faire ensemble

Rechercher des photos par date, lieu, contenu ou personne reconnue
Parcourir les albums et les souvenirs générés automatiquement
Consulter les statistiques de la photothèque (nb photos, vidéos, taille)
Créer un album et y regrouper des assets
Mettre à jour les métadonnées d'un asset (description, date, lieu)

Sauvegarde de la base de données

Sauvegarde automatique quotidienne de la base PostgreSQL Immich-DB vers kDrive Infomaniak. Mise en place le 2026-06-01.

Paramètres

Script	`/opt/backups/vps_backup.sh`
Cron	Tous les jours à 2h du matin (`0 2 * * *`)
Container DB	`Immich-DB` (PostgreSQL 16)
Commande	`pg_dump -U postgres`
Taille base (disque)	~7.5 Mo (métadonnées uniquement — photos sur volume séparé)
Format archive	.7z (compression niveau 5)
Destination	kDrive Infomaniak — `TOOJUX/jux_vps/immich` (dossier ID 1427919)
Rétention	7 jours glissants
Nommage fichier	`immich_db_YYYY-MM-DD.7z`

Note importante

Cette sauvegarde couvre uniquement les métadonnées (albums, faces, tags, utilisateurs). Les fichiers photos/vidéos sont stockés dans /home/debian/docker/immich/upload et /home/debian/photo — ils ne sont pas inclus dans ce backup.

REX — 2026-06-21 — FUSE cassé après restart rclone-photo

Symptôme

Immich connecté mais aucune photo visible. Logs Immich-SERVER :

WARN [Microservices:LibraryService] Skipping invalid import path: /mnt/media/photo. Reason: Error: ENOTCONN: socket is not connected, stat '/mnt/media/photo'

Cause

Le service rclone-photo.service a redémarré le 2026-06-18 (suite à l'incident sécurité du 2026-06-09 — fix --rc-addr 127.0.0.1). Les containers Immich-SERVER et Immich-MICROSERVICES, démarrés avant ce restart, conservent un file descriptor FUSE invalide. La propagation :shared aide pour les nouveaux montages mais ne restaure pas un fd FUSE mort.

Fix immédiat

docker restart Immich-SERVER Immich-MICROSERVICES
# puis déclencher un scan de bibliothèque :
curl -s -X POST "https://immich.juxjux.ovh/api/libraries/89bfcdc1-1604-47a1-90a3-975d2f6c4639/scan" \
  -H "Authorization: Bearer TOKEN"
# TOKEN obtenu via POST /api/auth/login (bertrand.dadone@gmail.com / 27101809)

Fix structurel — ExecStartPost dans rclone-photo.service (2026-06-21)

Ajout d'un ExecStartPost dans /etc/systemd/system/rclone-photo.service : à chaque redémarrage de rclone-photo, les containers Immich sont automatiquement relancés si et seulement s'ils tournent déjà (pas de blocage au boot).

ExecStartPost=/bin/bash -c 'sleep 3; docker ps --filter name=Immich-SERVER --filter status=running -q | grep -q . && docker restart Immich-SERVER Immich-MICROSERVICES || true'

Rechargement : sudo systemctl daemon-reload (pas de restart du service nécessaire — prendra effet au prochain redémarrage de rclone-photo).

Library ID Immich

89bfcdc1-1604-47a1-90a3-975d2f6c4639

Inventaire par Claude le 251001

2026-08-28 — Photos en double et chronologie cassee : diagnostic et reparation

Symptome : apres la resynchronisation d'un dossier renomme cote NAS, les photos de l'ete 2026 apparaissaient en double dans Immich et ne se rangeaient plus a leur date de prise de vue.

Deux causes distinctes se superposaient, et les confondre fait perdre du temps.

1. Les doublons — deja resolus par Immich lui-meme

Le dossier 2026_Eté UK ayant ete renomme en 2026_Eté UK et Italia, 308 assets pointaient sur un chemin disparu. Immich les avait deja marques hors ligne et mis a la corbeille tout seul : ils ne polluaient donc plus la chronologie. Ils ont ete purges definitivement par API.

POST /api/search/metadata   {"isOffline": true}     -> recensement
DELETE /api/assets          {"ids": [...], "force": true}

Aucun fichier reel n'est touche (ils n'existent plus sur le disque) et ces assets n'appartenaient a aucun album — verifie avant la purge.

2. Les dates — 275 photos n'avaient plus AUCUN bloc EXIF

Non pas « un EXIF sans date » : plus une seule metadonnee. Mesure sur les 351 fichiers du dossier :

NombreTaille moyennePeriode Sans aucun EXIF275493 Ko02/07 au 21/07 EXIF complet + GPS761103 Ko17/07 au 17/08

Cause : la passe de compression Caesium du 2026-07-14, lancee sans l'option -e — le piege decouvert et documente seulement le 27/08 (page 284). Les fichiers traites ont perdu date et GPS. Le GPS est definitivement perdu ; seule la date etait reconstituable, parce que les appareils Android nomment leurs prises IMG_AAAAMMJJ_HHMMSS au declenchement.

Pourquoi le probleme n'est apparu que maintenant

Prive de DateTimeOriginal, Immich retombe sur la date de modification du fichier. Or le WebDAV kDrive ne preserve pas les mtime : chaque reupload redate les fichiers au jour de la synchronisation, et les photos partent se ranger a cette date. Tant qu'aucune resynchronisation n'avait lieu, le defaut dormait — la compression de juillet ne s'est vue qu'en aout.

⚠ Corriger la date dans Immich ne tient pas

Teste puis abandonne : PUT /api/assets/{id} avec dateTimeOriginal a tenu quelques secondes, puis la valeur a ete ecrasee par la re-extraction des metadonnees du fichier. Sur une bibliotheque externe, le fichier fait autorite.

Il n'existe aucun reglage Immich pour « n'utiliser que la date de prise de vue » : sans EXIF, le logiciel n'a pas d'autre source. Exiger ce comportement revient a exiger que les fichiers portent leur date. La reparation doit donc se faire dans le fichier.

Reparation appliquee

Jux-scripts/Photos-Caesium/dater_photos_nas.py (stdlib seule, deploye sur le NAS) reconstruit la date depuis le nom et l'inscrit dans un segment APP1 de 138 octets insere apres le marqueur SOI.

python3 dater_photos_nas.py "/volume1/photo/2026/2026_Eté UK et Italia"        # simulation
python3 dater_photos_nas.py "/volume1/photo/2026/2026_Eté UK et Italia" --go   # ecriture

Garde-fous : ne touche que les JPEG totalement depourvus d'EXIF ; n'invente jamais de date (sans motif reconnu, le fichier est laisse tel quel) ; refuse les dates impossibles ; ecriture atomique avec relecture de controle avant remplacement ; mtime, proprietaire et permissions releves puis reimposes et verifies.

Resultat : 275 fichiers dates en 224 s, 0 echec. Donnees image identiques a l'octet pres (+138 octets de metadonnees), mtime preserve. Apres resynchronisation et POST /api/libraries/{id}/scan, Immich a relu l'EXIF en moins de 40 s : les 351 photos se repartissent du 02/07 au 17/08, et plus une seule n'est datee du jour de la synchro.

Audit du reste du stock — pas de reparation de masse

auditer_exif_nas.py sur les 16 262 JPEG du NAS : 1 001 sans date de prise de vue, mais aucun autre degat Caesium.

859 sont des numerisations anciennes (1930-2016 - Photos BERTRAND MER, L'album de Papa et Maman, cartes de voeux) : elles n'ont jamais eu d'EXIF, c'est leur nature. 85 dans 2024 - Nouvel an Arriège sont des photos WhatsApp (IMG-AAAAMMJJ-WA0004.jpg, 151 Ko de moyenne) : WhatsApp strippe systematiquement l'EXIF. Normal. ⚠ Ne jamais dater en masse depuis le nom de fichier. Dans l'album 1999, un nom en 20xx est la date de numerisation : l'inscrire comme date de prise de vue daterait une photo de 1999 en 2015. Le traitement se decide album par album.

Reperes API (aucun MCP Immich dans la session)

POST /api/auth/login                 -> accessToken (Bearer)
POST /api/search/metadata            isOffline, originalFileName, takenAfter/takenBefore,
                                     withExif ; pagination par le champ nextPage
GET  /api/assets/statistics
GET  /api/libraries + /api/libraries/{id}/statistics
POST /api/libraries/{id}/scan

Bibliotheque externe : 89bfcdc1-1604-47a1-90a3-975d2f6c4639, chemin d'import /mnt/media/photo.