Die endgültige Lösung in diesem Thread war nicht, jedes Mal „.ppstorage löschen“ auszuführen. Die Datei kam zurück, weil das zugrunde liegende Volume-Layout weiterhin falsch war. Die entscheidende Diagnose lieferten die Logs, und die dauerhafte Änderung bestand darin, das richtige Host-Verzeichnis dem Originals-Pfad von PhotoPrism zuzuordnen.
Die Logmeldung war ein Hinweis, nicht die vollständige Lösung
In einer Antwort wurde ein .ppstorage-Marker in /DATA/Gallery entdeckt und vorgeschlagen, ihn zu löschen. Der Nutzer tat dies, aber PhotoPrism erstellte die Dateien erneut und schlug weiterhin fehl. Das zeigte, dass nicht nur die Datei, sondern die Pfadbeziehung korrigiert werden musste.
PhotoPrism trennt Originals und Storage
Die offiziellen PhotoPrism-Speicherordner erklären, dass der Storage-Ordner Konfiguration, Cache, Backups, Vorschaubilder und Sidecar-Daten enthält. Normalerweise sollte er nicht innerhalb von Originals konfiguriert werden, es sei denn, eine von PhotoPrism unterstützte Anordnung mit einem versteckten Namen wird verwendet. Diese Vorgabe des Upstream-Projekts erklärt, warum das Einbinden des Anwendungsspeichers in den Foto-Originals-Baum Probleme verursachen kann.
Die Anleitung zur ersten Docker-Anwendung erklärt das Modell aus Host-Pfad und Container-Pfad in ZimaOS. Die Anforderungen des ZimaOS App Store liefern den aktuellen Kontext auf Paketebene, wenn mehrere Vorlagen oder Abhängigkeitsstacks vorhanden sind.
Logs prüfen, bevor Datenbanken oder Berechtigungen geändert werden
Die offizielle Fehlerbehebung für PhotoPrism Docker empfiehlt, die Docker-Logs zu prüfen, und weist ausdrücklich auf Fehler bei Speicherplatz, Berechtigungen, Routen und Speicher hin. In diesem Fall lieferten die Logs genügend Informationen, um MariaDB nicht aufs Geratewohl neu aufzusetzen, Ports zu ändern oder das gesamte Betriebssystem neu zu installieren.
Was die funktionierende Änderung der Community bewiesen hat
Der Nutzer verglich die BigBear-Vorlage mit der Zuordnung im ZimaOS App Store, änderte die Originals-Verknüpfung, und PhotoPrism startete. Das bestätigt, dass die Speicherzuordnung für diese Installation entscheidend war. Es beweist jedoch nicht, dass jedes aktuelle PhotoPrism-Paket exakt denselben Host-Pfad verwendet.
Fazit
Wenn PhotoPrism installiert wird, aber sofort beendet wird, sollten zuerst die Logs gelesen werden, bevor alles gleichzeitig geändert wird. In diesem Community-Fall deutete das wiederkehrende .ppstorage-Symptom auf eine falsche Beziehung zwischen dem PhotoPrism-Speicher und Originals hin. Die Korrektur der Volume-Zuordnung – nicht das wiederholte Löschen des Markers – ermöglichte den Start der Anwendung.
