Si Immich continue d’indiquer l’espace libre du SSD système de ZimaOS même après l’ajout d’un disque dur plus volumineux, la question importante est de savoir quel répertoire hôte est réellement lié au montage de téléchargement/stockage d’Immich. Dans la discussion communautaire d’avril 2026, l’utilisateur d’origine exécutait Immich 2.7.4 sur un SSD système de 250 Go et souhaitait stocker ses photos sur un disque dur de 1 To. Les changements répétés du chemin après l’installation ont provoqué des conteneurs non sains ou des échecs au démarrage.
La discussion source a produit plusieurs résultats différents. Un utilisateur a réussi après une réinstallation propre accompagnée d’un fichier YAML personnalisé. L’auteur original a finalement signalé que la méthode n’avait fonctionné qu’après avoir choisi le chemin de stockage sur le disque dur avant d’installer Immich. Une réponse ultérieure a établi un lien entre certains échecs au démarrage et les vérifications d’intégrité du stockage d’Immich. La documentation actuelle d’Immich en amont a également changé depuis la version 2.7.4 ; le chemin exact du conteneur utilisé dans cet ancien paquet ZimaOS ne doit donc pas être repris dans tous les déploiements actuels d’Immich.
Configuration Immich 2.7.4 originale utilisée
Les instructions de la communauté indiquaient ce mappage historique :
Hôte : /DATA/Gallery/immich
Conteneur : /usr/src/app/uploadLa première recommandation consistait à modifier uniquement le côté hôte et à conserver le chemin du conteneur. Par exemple, un disque secondaire pouvait être exposé via un chemin hôte ZimaOS, tandis qu’Immich continuait de voir le répertoire interne de téléchargement attendu.
Pourquoi la simple modification du chemin hôte n’a pas fonctionné pour tout le monde
Plusieurs utilisateurs ont essayé de remplacer le chemin hôte par défaut après l’initialisation d’Immich. Certains ont obtenu un état de conteneur non sain, d’autres une erreur de système de fichiers en lecture seule, tandis que d’autres ont constaté que l’application signalait toujours le disque système.
Cela signifie que cette discussion ne permet pas d’affirmer de manière universelle que « modifier un volume et redémarrer » fonctionne toujours. Immich conserve l’état de la base de données et des marqueurs d’intégrité du stockage, et la modification d’un montage bind après l’initialisation peut rendre le nouveau répertoire incohérent avec l’état attendu par Immich.
Méthode fonctionnelle confirmée par l’auteur original
Après plusieurs tentatives infructueuses, Solid est revenu le 19 avril et a indiqué que la méthode fonctionnelle consistait à effectuer une installation propre et à modifier le chemin d’installation/de stockage vers le disque dur de 1 To avant l’initialisation de l’installation d’Immich.
Un deuxième utilisateur a confirmé une réinstallation propre et un chemin YAML personnalisé
Un autre participant, scott492010, a supprimé l’installation défaillante, conservé les photos existantes, supprimé l’ancien état AppData/la base de données Immich, réinstallé l’application, puis utilisé le YAML personnalisé partagé dans la discussion. Il a explicitement confirmé que la nouvelle configuration fonctionnait.
Ne supprimez pas AppData ni la base de données Immich à la légère. Cette procédure de la communauté a été utilisée sur une installation défaillante/de test. Si la bibliothèque contient des métadonnées, des utilisateurs, des albums ou des fichiers importés importants, sauvegardez la base de données et le stockage des photos avant de reconstruire l’installation.
Ancien chemin ZimaOS : /DATA/.media/...
La discussion a testé des chemins vers des disques externes tels que :
/DATA/.media/Elements/Photos
/DATA/.media/Elements/Photos/uploadCes exemples correspondaient spécifiquement aux disques et à la disposition des chemins de ZimaOS évoqués dans cette discussion. Ne copiez pas le nom Éléments ou supposez que chaque disque apparaît au même chemin sur l’hôte. Utilisez le chemin réel affiché dans les paramètres actuels de ZimaOS Files/de l’application.
Immich utilise actuellement une disposition de stockage en amont différente
La documentation actuelle de Docker Compose d’Immich en amont utilise UPLOAD_LOCATION sur l’hôte et le monte sur /data dans le modèle Compose actuel. Cela diffère de l’ancien mappage Immich 2.7.4 de ZimaOS vers /usr/src/app/upload.
Consultez la documentation actuelle de Docker Compose d’Immich.
Il s’agit d’une différence de version, pas d’une contradiction. Si vous utilisez un paquet de l’App Store ZimaOS, conservez la destination du conteneur définie par le paquet actuel. Si vous gérez vous-même Compose en amont, suivez le modèle actuel fourni en amont.
Guide actuelle d’Immich pour les emplacements de fichiers personnalisés
Immich dispose désormais d’un guide dédié sur les emplacements personnalisés des fichiers. Il recommande de modifier délibérément les emplacements côté hôte et de déplacer les fichiers existants correspondants afin qu’Immich continue à les trouver.
Immich déconseille également de séparer upload/ et library/ en montages bind distincts sur le même périphérique. Pour une nouvelle organisation, suivez le modèle de stockage actuel plutôt que de reconstituer ligne par ligne le YAML de la communauté datant de 2026.
Pourquoi l’absence des fichiers .immich peut empêcher le démarrage
Une réponse publiée en juillet 2026 dans le fil identifiait des erreurs telles que :
ENOENT : aucun fichier ou dossier de ce type
.../encoded-video/.immichLa documentation d’Immich sur l’intégrité du système confirme que les fichiers .immich cachés sont des marqueurs de montage utilisés pour détecter des autorisations incorrectes ou des montages de stockage manquants ou remplacés.
La réponse du forum suggérait de créer manuellement les dossiers et fichiers marqueurs attendus. La documentation actuelle en amont est plus prudente : les fichiers marqueurs ne doivent généralement pas être créés ou supprimés manuellement, sauf dans des situations de récupération précises. Si le point de montage a changé de manière inattendue, corrigez d’abord le montage. La recréation manuelle d’un marqueur n’est appropriée qu’après avoir vérifié la raison de sa disparition.
N’utilisez pas chmod 777 comme solution d’autorisation par défaut
La réponse finale de la communauté indiquait également :
sudo chmod -R 777 /DATA/Main-Storage/immichCela accorde à chaque utilisateur ou processus local un large accès en écriture. Cela peut supprimer une barrière d’autorisation, mais ce n’est pas le modèle d’autorisations permanent recommandé. Identifiez plutôt l’UID/GID et les autorisations de stockage attendus par le paquet Immich installé.
Conserver la base de données PostgreSQL sur un système de fichiers adapté
Déplacer les fichiers photo vers un grand disque dur ne signifie pas que chaque composant d’Immich doit y être installé. Les exigences actuelles d’Immich indiquent que la base de données PostgreSQL devrait idéalement se trouver sur un stockage SSD local et qu’elle nécessite un système de fichiers prenant en charge les sémantiques Unix normales de propriété et d’autorisations ; NTFS et exFAT ne sont pas pris en charge pour le répertoire de données de la base.
Consultez les exigences d’installation d’Immich.
Cela signifie qu’une architecture raisonnable peut conserver la base de données et l’état de l’application Immich sur un stockage SSD fiable, tout en plaçant le répertoire d’envoi, beaucoup plus volumineux, des photos et vidéos sur un disque secondaire adapté.
Sauvegardez vos données avant de reconstruire ou de déplacer des données Immich existantes
La documentation actuelle d’Immich recommande de protéger à la fois la base de données et les ressources du système de fichiers. Une sauvegarde de la base de données seule ne contient pas les photos et vidéos d’origine.
Guide de sauvegarde et de restauration d’Immich
Ordre de dépannage recommandé
- Identifiez le package/la version exacte d’Immich installé dans ZimaOS.
- Notez le mappage actuel du répertoire d’envoi entre l’hôte et le conteneur.
- Sauvegardez les photos importantes et la base de données Immich avant de modifier une installation existante.
- Pour une nouvelle installation, choisissez le chemin hôte du stockage volumineux souhaité avant la première initialisation, lorsque le package ZimaOS le permet.
- Conservez le chemin côté conteneur défini par ce package.
- Si l’application passe à l’état défectueux, consultez les journaux d’Immich et recherchez les erreurs liées aux autorisations ou à l’intégrité du stockage.
- Vérifiez que le nouveau dossier hôte est accessible en écriture pour l’identité du conteneur Immich.
- Si les journaux mentionnent l’absence de
.immichmarqueurs, vérifiez le montage et la structure des répertoires avant de créer manuellement des fichiers. - À éviter
chmod 777comme correctif permanent.
FAQ sur le stockage système d’Immich
Pourquoi Immich affiche-t-il toujours la capacité de mon SSD système ?
Le montage bind actif du répertoire d’envoi pointe peut-être toujours vers le stockage système, ou le montage modifié ne s’est peut-être pas initialisé correctement. Vérifiez le mappage hôte-conteneur réellement utilisé par le serveur en cours d’exécution.
L’auteur d’origine a-t-il résolu le problème ?
Oui. Solid a indiqué qu’une installation propre, avec le chemin du disque dur sélectionné avant l’installation, avait fonctionné après l’échec des modifications post-installation.
Dois-je copier /usr/src/app/upload dans une nouvelle installation d’Immich ?
Pas aveuglément. Il s’agissait du chemin du conteneur dans l’ancien package Immich 2.7.4 de ZimaOS. Le fichier Compose Immich en amont actuel utilise /data. Suivez le package/la version que vous utilisez réellement.
Dois-je créer manuellement des fichiers .immich ?
Uniquement après avoir confirmé pourquoi ils manquent. La documentation actuelle d’Immich indique que ces marqueurs ne doivent normalement pas être créés ou supprimés manuellement, sauf dans certains cas de récupération.
Puis-je mettre la base de données sur une clé USB exFAT ?
Les exigences actuelles d’Immich ne prennent pas en charge exFAT/NTFS pour le répertoire de données PostgreSQL. Conservez la base de données sur un système de fichiers local adapté et déplacez séparément les ressources photo si nécessaire.
