La solution finale dans cette discussion n’était pas de « supprimer .ppstorage à chaque fois ». Le fichier réapparaissait parce que la disposition des volumes sous-jacente était toujours incorrecte. Le diagnostic utile venait des journaux, et la modification durable consistait à corriger le répertoire hôte associé au chemin Originals de PhotoPrism.
Le message du journal était un indice, pas la solution complète
Une réponse a signalé la présence d’un marqueur .ppstorage dans /DATA/Gallery et a suggéré de le supprimer. L’utilisateur l’a fait, mais PhotoPrism a recréé les fichiers et a continué à échouer. Cela a montré que c’était la relation entre les chemins — et pas seulement le fichier — qu’il fallait corriger.
PhotoPrism sépare Originals et Storage
La page officielle sur les dossiers de stockage de PhotoPrism indique que le dossier Storage contient la configuration, le cache, les sauvegardes, les miniatures et les données annexes. Il ne doit normalement pas être configuré à l’intérieur de Originals, sauf au moyen d’une organisation avec un nom masqué prise en charge par PhotoPrism. Cette règle en amont explique pourquoi l’association du stockage de l’application à l’arborescence de photos Originals peut provoquer des problèmes.
La page sur la première application Docker explique le modèle chemin hôte/chemin conteneur dans ZimaOS, tandis que les exigences de la boutique d’applications ZimaOS fournissent le contexte actuel au niveau des paquets lorsqu’il existe plusieurs modèles ou piles de dépendances.
Consultez les journaux avant de modifier les bases de données ou les permissions
Le guide officiel de dépannage de PhotoPrism avec Docker recommande de vérifier les journaux Docker et mentionne notamment les erreurs liées au disque, aux permissions, au routage et au stockage. Dans ce cas, le journal fournissait suffisamment d’informations pour éviter de reconstruire au hasard MariaDB, de modifier les ports ou de réinstaller tout le système d’exploitation.
Ce que la modification communautaire fonctionnelle a démontré
L’utilisateur a comparé le modèle BigBear à l’association proposée par la boutique d’applications ZimaOS, a modifié le lien Originals, puis PhotoPrism a démarré. Cela confirme que l’association du stockage était déterminante pour cette installation ; cela ne prouve pas que tous les paquets PhotoPrism actuels utilisent exactement le même chemin hôte.
En résumé
Si PhotoPrism s’installe mais se ferme immédiatement, consultez les journaux avant de tout modifier en même temps. Dans ce cas communautaire, le symptôme récurrent lié à .ppstorage indiquait une relation incorrecte entre le stockage de PhotoPrism et Originals. La correction de l’association des volumes — et non la suppression répétée du marqueur — a permis à l’application de démarrer.
