Dlaczego Immich odtwarza brakujące pliki z niewłaściwym właścicielem?

Immich nie powinien po cichu odtwarzać brakującego oryginału źródłowego jako ogólnej funkcji odzyskiwania. Jeśli usunięty obiekt pojawi się ponownie, najpierw ustal, czy jest to wygenerowana miniatura, zakodowany plik wideo, artefakt profilu, plik towarzyszący XMP czy inny zapisywalny plik — takie obiekty mogą być odtwarzane lub przepisywane przez różne procesy i dziedziczyć innego właściciela.

Użyj jednego tymczasowego, ponownie wygenerowanego obiektu oraz jego katalogu nadrzędnego. Porównaj numeryczne UID/GID i listy ACL na hoście z efektywnym procesem zapisującym wewnątrz kontenera, a następnie ustal, czy obiekt został faktycznie utworzony przez Immich, funkcję zapisu plików towarzyszących, protokół NAS czy inny proces hosta. Unikaj rekurencyjnego chown lub chmod 777, dopóki nie ustalisz, który proces zapisuje plik.

Porównaj odtworzony plik z jego katalogiem nadrzędnym i znanym poprawnie działającym plikiem

Zapisz właściciela, grupę, tryb, listę ACL, a w razie potrzeby także atrybuty rozszerzone i numeryczne UID/GID dla odtworzonego pliku, jego katalogu nadrzędnego oraz starszego pliku, który działa poprawnie. Nazwy mogą być mylące w systemie NAS i kontenerze; numeryczne identyfikatory pokazują, czy „immich” w jednym systemie odpowiada tej samej tożsamości w drugim.

Procedura ZimaSpace dotycząca uprawnień dla plików przeniesionych do NAS ma tu bezpośrednie zastosowanie: nowe obiekty podlegają listom ACL miejsca docelowego, tożsamości kontenera, mapowaniu protokołu i regułom tworzenia. Zastępczy plik może więc być możliwy do odczytu, a mimo to otrzymać właściciela, który zakłóci działanie innego narzędzia. Jeśli odtworzony plik odpowiada dziedziczeniu z katalogu nadrzędnego, a tylko wyświetlana nazwa wygląda nieznajomo, przed wprowadzeniem zmian sprawdź mapowanie identyfikatora numerycznego. Jeśli różni się zarówno od katalogu nadrzędnego, jak i od poprawnie działających plików, przejdź do ustalenia tożsamości procesu zapisującego — problem może tkwić w konfiguracji kontenera, a nie w liście ACL systemu plików.

Ustal proces oraz efektywne UID/GID zapisujące plik zastępczy

Wywołaj jedno bezpieczne odtworzenie, obserwując odpowiednie dzienniki i system plików. Sprawdź efektywnego użytkownika oraz grupy wewnątrz kontenera, który wykonuje zapis. Jeśli plik tworzy plik towarzyszący, narzędzie metadanych, proces kopii zapasowej lub skrypt hosta, sprawdź tę usługę zamiast zmieniać tożsamość procesu Immich.

Własność w kontenerach jest określana numerycznie, a nie na podstawie nazwy. Wyjaśnienie własności plików w Dockerze pokazuje, dlaczego ten sam plik zamontowany jako bind mount może wyświetlać inną nazwę użytkownika na hoście i w kontenerze, gdy mapowania UID/GID nie są zgodne. Używaj identyfikatorów numerycznych jako wspólnego punktu odniesienia.

W dyskusji na temat własności zewnętrznych bibliotek w Immich udokumentowano przypadek zapisywania plików towarzyszących XMP jako root w jednym wdrożeniu. To dowód na potrzebę sprawdzenia efektywnego procesu zapisującego i obsługiwanej tożsamości procesu, a nie twierdzenie, że każda obecna instalacja Immich zapisuje każdy ponownie wygenerowany plik jako root.

Jeśli kontener celowo działa jako użytkownik inny niż root, potwierdź, że dane UID/GID faktycznie istnieją na hoście lub serwerze NAS i mają wymagany dostęp do zamontowanej ścieżki. Symboliczna nazwa użytkownika wewnątrz kontenera nie jest automatycznie zgodna z kontem hosta o tej samej nazwie.

Napraw regułę tworzenia zamiast wielokrotnie poprawiać istniejące pliki

Popraw najmniejszy potwierdzony element graniczny: dopasuj UID/GID usługi, jeśli jest to obsługiwane, napraw dziedziczenie grupy lub list ACL katalogu nadrzędnego, ustaw odpowiednią wartość umask albo zmień mapowanie udziału NAS, które dostarcza nieprawidłową tożsamość. Zachowaj możliwość dostępu Immich i innych uprawnionych czytników do oryginałów oraz wygenerowanych plików.

Nie używaj domyślnie uprawnień umożliwiających zapis wszystkim. Ukrywają one niezgodność tożsamości i niepotrzebnie rozszerzają dostęp do zapisu. Nie zmieniaj też rekurencyjnie własności PostgreSQL, pamięci podręcznej modeli, przesłanych plików i bibliotek zewnętrznych jednym poleceniem; te ścieżki mogą celowo korzystać z różnych tożsamości usług.

Jeśli biblioteka zewnętrzna ma być niezmienna, rozważ zamontowanie jej tylko do odczytu i przechowywanie zapisywanego przez aplikację stanu w innym miejscu, ale tylko jeśli używane funkcje nie wymagają zapisywania tam plików towarzyszących. Chodzi o ustalenie pożądanej własności i sposobu zapisu, a nie o wymuszenie jednego konta dla każdego pliku w archiwum zdjęć.

Featured

ZimaCube 2 Osobisty domowy NAS w chmurze

ZimaCube2

$799.00 - $2,499.00

Buy Now

Odtwórz ponownie jeden plik i sprawdź działanie po ponownym uruchomieniu

Usuń tylko tymczasowy wygenerowany obiekt lub testowy plik towarzyszący, który można bezpiecznie odtworzyć, a następnie ponownie wywołaj dokładnie tę operację Immich. Sprawdź nowego właściciela, grupę, listę ACL oraz możliwość odczytu zarówno z poziomu Immich, jak i programu, który wcześniej nie działał. Podczas tego testu nie modyfikuj oryginalnych multimediów.

Uruchom ponownie kontener, a następnie raz zrestartuj hosta, aby upewnić się, że poprawiona tożsamość i punkty montowania przetrwają zmiany cyklu życia. Udana naprawa powoduje automatyczne utworzenie kolejnego pliku testowego z oczekiwaną własnością; nie zależy od wykonywanego po uruchomieniu skryptu chown, który może wyścigowo konkurować z zapisami Immich.

Zatrzymaj usługę i przywróć zachowaną konfigurację, jeśli zmiany własności nieoczekiwanie obejmą bazę danych lub oryginały albo jeśli po ponownym uruchomieniu usługa utraci dostęp do odczytu lub zapisu. Przy eskalacji przekaż numeryczne identyfikatory, wynik poleceń dotyczących ACL, opcje montowania, efektywnego użytkownika kontenera, fragment konfiguracji Compose oraz dokładny typ pliku odtworzonego przez Immich.