Rozwiązanie społecznościowe

PhotoPrism nie uruchamia się w ZimaOS: napraw oryginały i mapowanie pamięci masowej

A January 2026 PhotoPrism install failed repeatedly. Logs pointed to a .ppstorage file under the Originals path; simply deleting it did not last, but changing the ZimaOS Originals volume mapping allowed PhotoPrism to start.

Ostatecznym rozwiązaniem w tym wątku nie było „usuwanie .ppstorage za każdym razem”. Plik powracał, ponieważ podstawowy układ woluminów nadal był nieprawidłowy. Przydatna diagnoza wynikała z logów, a trwałym rozwiązaniem było poprawienie katalogu hosta przypisanego do ścieżki Originals w PhotoPrism.

Ekran aplikacji PhotoPrism i logi z instalacji ZimaOS, która nie uruchomiła się
Autor pierwotnego wpisu udostępnił stan PhotoPrism po wystąpieniu błędu, przed poprawieniem mapowań pamięci.
Ustawienia aplikacji PhotoPrism w ZimaOS pokazujące pierwotną konfigurację woluminów
Ustawienia aplikacji porównano z działającym szablonem społeczności, aby zidentyfikować problem ze ścieżką Originals.
Powiadomienie PhotoPrism informujące, że aplikacja nie mogła uruchomić się przy pierwotnym układzie pamięci
Powiadomieniu towarzyszyły logi wskazujące na konflikt związany z pamięcią lub ścieżką Originals.
Poprawione mapowanie Originals w PhotoPrism, które umożliwiło uruchomienie aplikacji w ZimaOS
Końcowy zrzut ekranu udostępniony przez społeczność pokazywał zmienione mapowanie Originals, które umożliwiło uruchomienie PhotoPrism.

Komunikat z logu był wskazówką, a nie całym rozwiązaniem

W jednej z odpowiedzi zauważono znacznik .ppstorage w katalogu /DATA/Gallery i zasugerowano jego usunięcie. Użytkownik to zrobił, ale PhotoPrism ponownie utworzył pliki i nadal się nie uruchamiał. Pokazało to, że poprawy wymagała relacja między ścieżkami, a nie tylko sam plik.

PhotoPrism oddziela Originals od Storage

Oficjalna dokumentacja dotycząca katalogów Storage PhotoPrism wyjaśnia, że katalog storage zawiera konfigurację, pamięć podręczną, kopie zapasowe, miniatury i dane sidecar. Zwykle nie powinien być konfigurowany wewnątrz Originals, chyba że używa układu z ukrytą nazwą obsługiwanego przez PhotoPrism. Ta zasada wyjaśnia, dlaczego mapowanie pamięci aplikacji do drzewa zdjęć Originals może powodować problemy.

Artykuł o pierwszej aplikacji Docker wyjaśnia model host-path/container-path w ZimaOS, natomiast wymagania ZimaOS App Store przedstawiają bieżący kontekst na poziomie pakietów, gdy dostępnych jest więcej szablonów lub stosów zależności.

Sprawdź logi przed zmianą baz danych lub uprawnień

Oficjalna dokumentacja rozwiązywania problemów z PhotoPrism Docker zaleca sprawdzenie logów Dockera i zwraca szczególną uwagę na błędy dysku, uprawnień, tras i pamięci. W tym przypadku log zawierał wystarczająco dużo informacji, aby uniknąć losowego przebudowywania MariaDB, zmiany portów lub ponownej instalacji całego systemu operacyjnego.

Co potwierdziła działająca zmiana wprowadzona przez społeczność

Użytkownik porównał szablon BigBear z mapowaniem w ZimaOS App Store, zmienił przypisanie Originals, a PhotoPrism się uruchomił. Potwierdza to, że mapowanie pamięci miało decydujące znaczenie w tej instalacji; nie dowodzi jednak, że każdy obecny pakiet PhotoPrism korzysta dokładnie z tej samej ścieżki hosta.

Podsumowanie

Jeśli PhotoPrism instaluje się, ale natychmiast się wyłącza, najpierw przeczytaj logi, zamiast zmieniać wszystko naraz. W tym przypadku ze społeczności powtarzający się objaw związany z .ppstorage wskazywał na nieprawidłową relację między katalogami Storage i Originals w PhotoPrism. Poprawienie mapowania woluminów — a nie wielokrotne usuwanie znacznika — umożliwiło uruchomienie aplikacji.