Napraw Immich, używając pamięci systemowej ZimaOS zamiast dysku HDD

Jeśli Immich nadal pokazuje wolne miejsce na systemowym dysku SSD ZimaOS nawet po dodaniu większego dysku HDD, najważniejsze pytanie brzmi: który katalog hosta jest faktycznie powiązany z montowaniem przesyłania/pamięci Immich. W wątku społeczności z kwietnia 2026 roku oryginalny użytkownik korzystał z Immich 2.7.4 na systemowym dysku SSD o pojemności 250 GB i chciał przechowywać zdjęcia na dysku HDD o pojemności 1 TB. Wielokrotne zmienianie ścieżki po instalacji powodowało niezdrowy stan kontenerów lub problemy z uruchamianiem.

Wątek źródłowy przyniósł kilka różnych rezultatów. Jednemu użytkownikowi udało się po czystej reinstalacji i zastosowaniu niestandardowego pliku YAML. Autor oryginalnego wpisu ostatecznie zgłosił sukces dopiero po wybraniu ścieżki przechowywania na dysku HDD przed zainstalowaniem Immich. W późniejszej odpowiedzi powiązano niektóre problemy z uruchamianiem z kontrolami integralności pamięci masowej Immich. Bieżąca dokumentacja Immich dostępna u źródła również zmieniła się od wersji 2.7.4, dlatego dokładnej ścieżki kontenera z tego historycznego pakietu ZimaOS nie należy kopiować do każdej obecnej instalacji Immich.

Czego używała pierwotna konfiguracja Immich 2.7.4

Instrukcje społeczności przedstawiały to historyczne mapowanie:

Host:      /DATA/Gallery/immich
Kontener: /usr/src/app/upload

Pierwsze zalecenie polegało na zmianie wyłącznie strony hosta i zachowaniu ścieżki kontenera. Na przykład dodatkowy dysk mógł być udostępniony przez ścieżkę hosta ZimaOS, podczas gdy Immich nadal widział oczekiwany wewnętrzny katalog przesyłania.

Dlaczego sama zmiana ścieżki hosta nie zadziałała u wszystkich

Kilku użytkowników próbowało zastąpić domyślną ścieżkę hosta po wcześniejszym zainicjowaniu Immich. U niektórych pojawił się stan niezdrowego kontenera, inni zobaczyli błąd systemu plików tylko do odczytu, a jeszcze inni stwierdzili, że aplikacja nadal wskazywała dysk systemowy.

Oznacza to, że ten wątek nie potwierdza uniwersalnego twierdzenia, że „edytowanie jednego woluminu i ponowne uruchomienie” zawsze działa. Immich zapisuje stan bazy danych i znaczniki integralności pamięci masowej, a zmiana montowania bind po inicjalizacji może sprawić, że nowy katalog będzie niespójny ze stanem oczekiwanym przez Immich.

Potwierdzone działające podejście autora oryginalnego wpisu

Po kilku nieudanych próbach Solid powrócił 19 kwietnia i stwierdził, że działającym rozwiązaniem było wykonanie czystej instalacji oraz zmiana ścieżki instalacji/przechowywania na dysk HDD o pojemności 1 TB przed zainicjowaniem instalacji Immich.

Drugi użytkownik potwierdził świstą ponowną instalację i ścieżkę niestandardowego pliku YAML

Inny uczestnik, scott492010, usunął nieudaną instalację, zachował istniejące zdjęcia, usunął nieaktualny stan AppData/bazy danych Immich, ponownie zainstalował aplikację, a następnie użył niestandardowego pliku YAML udostępnionego w wątku. Wyraźnie potwierdził, że nowa konfiguracja działała.

Nie usuwaj pochopnie AppData ani bazy danych Immich. Ta społecznościowa procedura została użyta w przypadku uszkodzonej/testowej instalacji. Jeśli biblioteka zawiera ważne metadane, albumy użytkowników lub przesłane zasoby, przed odbudową wykonaj kopię zapasową zarówno bazy danych, jak i magazynu zdjęć.

Historyczna ścieżka ZimaOS: /DATA/.media/...

W wątku testowano ścieżki zewnętrznych dysków, takie jak:

/DATA/.media/Elements/Photos
/DATA/.media/Elements/Photos/upload

Te przykłady dotyczyły konkretnych dysków i układu ścieżek ZimaOS w tamtej dyskusji. Nie kopiuj nazwy Elements ani nie zakładaj, że każdy dysk jest dostępny pod tą samą ścieżką hosta. Użyj rzeczywistej ścieżki wyświetlanej w ustawieniach Plików/aplikacji ZimaOS.

Aktualny Immich korzysta z innego układu pamięci masowej upstream

Aktualna dokumentacja upstream Immich Docker Compose używa UPLOAD_LOCATION na hoście i montuje je jako /data w bieżącym szablonie Compose. Różni się to od historycznego mapowania ZimaOS Immich 2.7.4 na /usr/src/app/upload.

Zobacz aktualną dokumentację Immich Docker Compose.

To granica między wersjami, a nie sprzeczność. Jeśli używasz pakietu z App Store ZimaOS, zachowaj miejsce docelowe kontenera zdefiniowane przez bieżący pakiet. Jeśli samodzielnie zarządzasz upstreamowym Compose, postępuj zgodnie z aktualnym szablonem upstream.

Aktualne wskazówki Immich dotyczące niestandardowych lokalizacji plików

Immich ma teraz dedykowany przewodnik po niestandardowych lokalizacjach plików. Zaleca celową zmianę lokalizacji po stronie hosta oraz przeniesienie odpowiednich istniejących plików, aby Immich nadal mógł je odnaleźć.

Immich ostrzega również przed rozdzielaniem upload/ oraz library/ na osobne punkty montowania bind na tym samym urządzeniu. W przypadku nowego układu zastosuj aktualny model pamięci masowej, zamiast odtwarzać wiersz po wierszu społecznościowy plik YAML z 2026 roku.

Dlaczego brakujące pliki .immich mogą zatrzymać uruchamianie

Odpowiedź z lipca 2026 r. w tym wątku wskazywała błędy takie jak:

ENOENT: nie ma takiego pliku ani katalogu
.../encoded-video/.immich

Aktualna dokumentacja integralności systemu Immich potwierdza, że ukryte pliki .immich to znaczniki punktów montowania używane do wykrywania nieprawidłowych uprawnień lub brakujących/zastąpionych punktów montowania pamięci masowej.

Odpowiedź na forum sugerowała ręczne utworzenie oczekiwanych folderów i plików znacznikowych. Aktualna dokumentacja upstreamu jest ostrożniejsza: plików znacznikowych zasadniczo nie należy tworzyć ani usuwać ręcznie, z wyjątkiem określonych sytuacji odzyskiwania. Jeśli punkt montowania zmienił się nieoczekiwanie, najpierw napraw montowanie. Ręczne odtworzenie znacznika jest właściwe tylko po zweryfikowaniu, dlaczego go brakuje.

Nie używaj chmod 777 jako domyślnego rozwiązania problemów z uprawnieniami

Końcowa odpowiedź społeczności również zawierała:

sudo chmod -R 777 /DATA/Main-Storage/immich

Zapewnia to każdemu lokalnemu użytkownikowi/procesowi szeroki dostęp do zapisu. Może usunąć barierę uprawnień, ale nie jest preferowanym trwałym modelem uprawnień. Zamiast tego ustal identyfikatory UID/GID oraz uprawnienia do pamięci masowej oczekiwane przez zainstalowany pakiet Immich.

Przechowuj bazę danych PostgreSQL w odpowiednim systemie plików

Przeniesienie zasobów zdjęć na duży dysk HDD nie oznacza, że każdy komponent Immich powinien się tam znajdować. Zgodnie z aktualnymi wymaganiami Immich baza danych PostgreSQL powinna znajdować się najlepiej na lokalnym dysku SSD i wymaga systemu plików z typową semantyką własności i uprawnień Unix; NTFS i exFAT nie są obsługiwane w katalogu danych bazy.

Zobacz wymagania instalacji Immich.

Oznacza to, że rozsądna architektura może przechowywać bazę danych i stan aplikacji Immich na niezawodnym dysku SSD, a znacznie większą lokalizację przesyłania zdjęć i filmów umieścić na odpowiednim dysku pomocniczym.

Wykonaj kopię zapasową przed przebudową lub przeniesieniem istniejących danych Immich

Obecna dokumentacja Immich zaleca zabezpieczenie zarówno bazy danych, jak i zasobów systemu plików. Sama kopia zapasowa bazy danych nie zawiera oryginalnych zdjęć ani filmów.

Przewodnik tworzenia i przywracania kopii zapasowej Immich

Bezpieczniejsza kolejność rozwiązywania problemów

1. Ustal dokładny pakiet i wersję Immich zainstalowane w ZimaOS.
2. Zapisz bieżące mapowanie katalogu upload między hostem a kontenerem.
3. Przed zmianą istniejącej instalacji wykonaj kopię zapasową ważnych zdjęć oraz bazy danych Immich.
4. W przypadku nowej instalacji wybierz docelową ścieżkę hosta na dużej pamięci przed pierwszą inicjalizacją, jeśli pakiet ZimaOS na to pozwala.
5. Zachowaj ścieżkę po stronie kontenera zdefiniowaną przez ten pakiet.
6. Jeśli aplikacja stanie się niezdrowa, odczytaj logi Immich i poszukaj błędów uprawnień lub integralności pamięci masowej.
7. Sprawdź, czy nowy folder hosta jest zapisywalny dla tożsamości kontenera Immich.
8. Jeśli w logach pojawia się informacja o braku .immich znaczników — przed ręcznym utworzeniem plików sprawdź podmontowanie oraz strukturę katalogów.
9. Unikaj chmod 777 jako trwałe rozwiązanie.

Najczęstsze pytania dotyczące pamięci systemowej Immich

Dlaczego Immich nadal pokazuje pojemność mojego systemowego dysku SSD?

Aktywne dowiązanie bind dla katalogu upload może nadal wskazywać pamięć systemową albo zmienione dowiązanie mogło nie zostać poprawnie zainicjalizowane. Sprawdź rzeczywiste mapowanie host–kontener używane przez działający serwer.

Czy autor oryginalnego rozwiązania rozwiązał ten problem?

Tak. Solid zgłosił, że czysta instalacja, w której przed instalacją wybrano ścieżkę dysku HDD, działała po tym, jak zmiany wprowadzone po instalacji zakończyły się niepowodzeniem.

Czy powinienem skopiować /usr/src/app/upload do nowej instalacji Immich?

Nie bez zastanowienia. Była to ścieżka kontenera w historycznym pakiecie ZimaOS Immich 2.7.4. Obecny upstreamowy plik Compose Immich używa /data. Należy stosować się do wersji pakietu, z której faktycznie korzystasz.

Czy powinienem ręcznie utworzyć pliki .immich?

Dopiero po ustaleniu, dlaczego ich brakuje. Obecna dokumentacja Immich mówi, że tych znaczników zasadniczo nie należy tworzyć ani usuwać ręcznie, z wyjątkiem określonych przypadków odzyskiwania.

Czy mogę umieścić bazę danych na dysku USB exFAT?

Obecne wymagania Immich nie obsługują systemów exFAT/NTFS dla katalogu danych PostgreSQL. Bazę danych należy przechowywać na odpowiednim lokalnym systemie plików, a w razie potrzeby osobno przenieść zasoby zdjęć.