Immich peut utiliser de manière fiable un partage réseau pour les médias ou une bibliothèque externe lorsque le montage, les permissions, la latence et le comportement en cas de panne sont conçus et testés, mais son répertoire de données PostgreSQL doit rester sur un stockage basse latence pris en charge plutôt que sur un partage SMB ou NFS généraliste.
Le terme « données » recouvre différentes charges de travail : les originaux sont de gros fichiers durables, les miniatures génèrent de nombreuses opérations plus petites, les bibliothèques externes peuvent être en lecture seule, et PostgreSQL exige les sémantiques d’un système de fichiers adapté aux bases de données. Décidez chemin par chemin, montez le partage avant le démarrage des conteneurs, empêchez un répertoire local vide de se faire passer pour le NAS et vérifiez le comportement après un redémarrage de l’hôte ainsi que lors d’une interruption contrôlée du partage.
Classez chaque chemin Immich avant de le déplacer
Répertoriez séparément la bibliothèque des téléversements, les miniatures ou médias encodés, les bibliothèques externes, le répertoire de la base de données, le cache des modèles et les sauvegardes. Indiquez qui écrit dans chaque chemin et l’impact de sa perte. Un partage de médias peut convenir ; traiter tous les volumes comme interchangeables fait échouer la validation de conception.
Un guide pratique consacré à NFS montre comment mapper une bibliothèque externe Immich depuis un stockage partagé. Son modèle de montage d’une bibliothèque externe est utile pour planifier les chemins et les permissions, mais ne prouve pas que la base de données devrait utiliser NFS.
Conservez PostgreSQL sur un stockage recommandé pour les bases de données et protégez-le avec des sauvegardes natives et des copies de sauvegarde. Si la capacité du stockage local actif est limitée, déplacez uniquement le chemin des médias qui occupe le plus d’espace après mesure et documentez cette limite au lieu de relocaliser tout l’état de l’application.
Rendez l’ordre de montage distant déterministe
Montez le partage sur l’hôte avec des identifiants ou des règles d’export explicites, une adresse stable et le mode lecture-écriture prévu. Vérifiez l’identité du système de fichiers attendu ainsi que la présence d’un fichier marqueur connu avant de démarrer Immich. Montez dans les conteneurs le chemin de l’hôte déjà monté.
Configurez le gestionnaire de services afin qu’Immich attende le montage distant et ne démarre pas sur un répertoire de repli local vide. Un démarrage n’est réussi que lorsque le marqueur est visible dans le conteneur et qu’un fichier de test reçoit le propriétaire attendu ; un répertoire vide ou un fichier appartenant à root impose l’arrêt immédiat.
Redémarrez une fois avec le partage disponible, puis une fois avec celui-ci volontairement indisponible pendant une fenêtre de maintenance. Le premier test n’est réussi que lorsque le marqueur apparaît avant le démarrage d’Immich ; le second uniquement lorsqu’Immich s’arrête ou échoue de manière visible au lieu d’écrire dans le point de montage local nu.
Vérifiez l’identité des conteneurs et les permissions du partage
Faites correspondre les identifiants numériques d’utilisateur et de groupe sur le serveur, le client et le conteneur, puis testez la création, le renommage, la lecture et la suppression dans un dossier temporaire dédié. Ne résolvez pas une incompatibilité avec des permissions d’écriture globales qui exposeraient la bibliothèque familiale.
Répétez le test de fichier temporaire depuis l’intérieur du conteneur du serveur Immich, et pas seulement depuis l’hôte. Vérifiez que le NAS voit le propriétaire numérique attendu et qu’Immich peut rouvrir le fichier après la recréation d’un conteneur. Un test réussi uniquement sur l’hôte ne prouve pas que le chemin du conteneur fonctionne.
Si l’identité ou le comportement de création et de renommage diffère, arrêtez-vous et corrigez l’export, le montage ou la correspondance du conteneur de manière ciblée. Effectuez un nouveau test avant d’analyser une bibliothèque réelle ; des changements de permissions trop larges peuvent masquer l’incompatibilité tout en exposant chaque photo familiale à des services sans rapport.
Mesurez la latence et testez une interruption du partage
Effectuez un téléversement représentatif, la génération de miniatures, la navigation dans la chronologie, le téléchargement d’un original et l’analyse d’une bibliothèque externe tout en mesurant la latence du serveur et la progression des tâches. La validation exige une interaction acceptable et l’absence d’augmentation persistante de la file d’attente ; le débit brut de la liaison ne suffit pas à prouver les performances des métadonnées.
Un problème Immich fait état d’une incohérence entre la base de données et les fichiers dans un déploiement utilisant un NFS instable. Ce cas d’échec NFS circonscrit montre qu’il faut considérer les déconnexions pendant les écritures comme un risque de récupération, et non supposer que NFS corrompt toujours Immich.
Pendant une fenêtre de maintenance et après avoir terminé les sauvegardes, interrompez le partage de médias alors qu’un test non critique est actif. Immich doit échouer de manière visible plutôt que d’écrire dans le point de montage local nu. Rétablissez le partage et vérifiez que l’élément de test ainsi que l’enregistrement de la base de données se réconcilient sans boucle de redémarrage.
Prenez la décision d’adopter ou non la solution après les tests de redémarrage
Redémarrez séparément les conteneurs et l’hôte. Vérifiez que le partage correct est monté en premier, que les anciens et les nouveaux originaux s’ouvrent, que les analyses externes ne dupliquent pas les éléments et qu’un nouveau téléversement survive à un autre redémarrage. La comparaison entre DAS et NAS de ZimaSpace présente les compromis liés à la latence et au domaine de défaillance.
Utilisez le partage si ces tests sont concluants et si la surveillance peut signaler son absence, la latence, l’espace disponible et la pression sur les inodes. Choisissez un stockage local ou directement connecté lorsque le réseau ou le NAS ne peut pas satisfaire les exigences de disponibilité, ou lorsqu’il est impossible d’empêcher le comportement de montage avec ouverture en cas d’échec.
Revenez au chemin local précédent si Immich démarre avec une bibliothèque vide, crée des fichiers appartenant à root ou génère des erreurs de fichiers manquants après une interruption. Lors de l’escalade, fournissez le protocole, les options de montage, les identités, les correspondances de chemins, la latence et l’ordre de démarrage ; ne relancez jamais une analyse de manière destructive avant d’avoir confirmé quels sont les originaux faisant autorité et l’état de la base de données.
Assistance et conseils
Plus à lire

Comment optimiser les connexions à la base de données d’Immich pour des conteneurs simultanés
N’augmentez pas d’abord max_connections. Mesurez les sessions Immich, totalisez la demande de chaque conteneur, préservez une marge pour l’administration et n’optimisez que le goulot...

Comment empêcher les tâches ou importations en double dans Immich
Séparez les tâches répétées des ressources en double. Utilisez un chemin d’ingestion canonique, contrôlez les nouvelles tentatives et les changements de chemin, puis testez...

Comment réparer Immich après le remplissage de son volume de base de données
Ne supprimez jamais les journaux WAL de PostgreSQL pour libérer de l’espace. Arrêtez les écritures d’Immich, préservez l’état de la base de données, ajoutez...

