Jak zapobiegać rozbieżnościom uprawnień w folderach danych Immich

Zapobieganie rozjeżdżaniu się uprawnień w Immich oznacza przewidywalne ustalenie właścicieli plików i reguł dostępu, zanim różne kontenery, protokoły NAS, aktualizacje lub zadania konserwacyjne zaczną tworzyć nowe pliki z innymi identyfikatorami.

Trwałym rozwiązaniem nie jest okresowe, rekurencyjne resetowanie uprawnień. Zapisz numeryczne UID/GID oraz dostęp, którego faktycznie potrzebuje każdy przepływ pracy, świadomie skonfiguruj własność punktów montowania i dziedziczenie ACL, rozdziel ścieżki tylko do odczytu od zapisywalnych oraz przetestuj ścieżkę tworzenia po każdej zmianie. Rozjeżdżanie się uprawnień jest powstrzymane wtedy, gdy jutrzejszy nowy plik zostanie utworzony poprawnie bez awaryjnego `chown`, a nie wtedy, gdy dzisiejsza biblioteka przypadkiem jest możliwa do odczytu.

Zapisz tożsamości, które odczytują i zapisują każdą ścieżkę Immich

Wymień ścieżki hosta montowane w Immich i określ, które procesy mają odczytywać, tworzyć, zmieniać nazwy lub usuwać pliki w każdej z nich. Dla każdego procesu zapisującego zanotuj jego numeryczne UID i GID na hoście oraz wewnątrz kontenera. Numeryczne identyfikatory są ważniejsze niż zgodność nazw użytkowników, ponieważ pliki przechowują własność jako liczby.

Uwzględnij w wykazie procesy zapisujące spoza Immich. Przesyłanie przez SMB, klienci NFS, narzędzia do tworzenia kopii zapasowych, skrypty importujące, kontenery do zarządzania multimediami oraz powłoka administratora mogą tworzyć pliki w tym samym drzewie. Jeśli robią to jako różne tożsamości, w bibliotece mogą stopniowo gromadzić się właściciele i tryby dostępu, które działają dla jednej ścieżki, ale zawodzą dla innej.

Przechowuj tę mapę tożsamości razem z konfiguracją Compose. Dzięki temu przyszłą aktualizację obrazu, migrację serwera lub przywrócone konto NAS będzie można porównać ze znaną, poprawną konfiguracją bazową, zamiast wykrywać niezgodność dopiero po tym, jak nowe przesyłane pliki zaczną powodować błędy.

Ustal świadomy model właściciela, wspólnej grupy i minimalnego dostępu

Określ, która tożsamość powinna być właścicielem danych zarządzanych przez aplikację oraz która wspólna grupa, jeśli w ogóle jest potrzebna, powinna mieć do nich dostęp. Przyznawaj każdemu przepływowi pracy tylko uprawnienia odczytu lub zapisu, których wymaga. Nie udostępniaj całego drzewa Immich do zapisu dla wszystkich tylko dlatego, że jeden kontener nie może utworzyć miniatury lub przenieść zaimportowanego pliku.

Niezgodności UID/GID i zbyt szerokie tryby dostępu są częstymi przyczynami problemów ze współdzielonymi woluminami. Bezpieczniejszym rozwiązaniem jest dopasowanie uprawnień kontenera i woluminu, zamiast przyznawania nieograniczonego dostępu. Ma to znaczenie na serwerze domowym, na którym kilka usług może korzystać z tej samej puli pamięci masowej.

Jeśli kilka usług potrzebuje dostępu do zapisu, użyj wspólnej grupy oraz spójnych uprawnień grupy lub list ACL zamiast naprzemiennie zmieniać własność rekurencyjną między aplikacjami. Najpierw zweryfikuj jeden reprezentatywny katalog. Szeroko zakrojone rekurencyjne zmiany w całej bibliotece zdjęć powinny być ostatecznością wykonywaną z aktualną kopią zapasową, a nie rutynową konserwacją.

Zapewnij przewidywalne uprawnienia nowych plików

Istniejące pliki mogą wyglądać idealnie, podczas gdy nowe od razu tracą spójność, ponieważ reguły ich tworzenia są nieprawidłowe. Sprawdź ACL katalogu nadrzędnego, domyślne wpisy ACL, umask, tożsamość usługi oraz ustawienia tworzenia plików SMB lub NFS dotyczące danej ścieżki. Celem zapobiegania jest dziedziczenie, a nie sprzątanie.

Przed rekurencyjną zmianą trybów dostępu porównaj numeryczną własność na hoście z UID/GID, z którym faktycznie działa kontener. Ten test UID/GID dla montowania bind szybko odróżnia niezgodność tożsamości od rzeczywiście brakującego uprawnienia. Napraw relację właściciela i grupy zamiast maskować problem nadmiernie liberalnymi trybami dostępu.

Utwórz mały plik testowy przez każdą standardową ścieżkę zapisu: przesyłanie do Immich, przepływ importu, transfer SMB/NFS, jeśli jest używany, oraz przywracanie z kopii zapasowej. Po każdym teście sprawdź właściciela, grupę, tryb dostępu i ACL. Jeśli dwie ścieżki tworzenia dają niezgodne wyniki, rozwiąż ten konflikt zasad przed zaimportowaniem kolejnych danych.

-15% OFF

ZimaBoard 2 – Mini serwer domowy dla Twojego wielkiego pomysłu

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Nie pozwól, aby zmiany montowania i aktualizacje przepisywały własność

Traktuj zmianę w Compose, aktualizację obrazu, ponowne zamontowanie NAS lub migrację jako zmianę wrażliwą na uprawnienia. Przed jej zastosowaniem zapisz bieżące źródło i miejsce docelowe montowania, informację, czy ścieżka jest tylko do odczytu czy do odczytu i zapisu, efektywnego użytkownika kontenera oraz próbkę numerycznej własności każdego ważnego katalogu.

Transfery i pamięć sieciowa mogą wprowadzić inne tożsamości SMB/NFS, identyfikatory numeryczne, dziedziczenie ACL oraz sposób działania umask. Użyj punktów ryzyka zmian uprawnień NAS jako listy kontrolnej przed zmianą za każdym razem, gdy dane Immich są przenoszone między systemami plików lub metodami dostępu.

Po zmianie porównaj te same próbki przed uruchomieniem zadań zbiorczych. Jeśli własność nagle zmieni się podczas uruchamiania, zatrzymaj stos i ustal, który punkt wejścia, zadanie konserwacyjne lub przemapowana tożsamość spowodowały tę zmianę. Nie pozwalaj, aby niewyjaśnione rekurencyjne przepisywanie własności było kontynuowane w dużej bibliotece.

Wykrywaj rozjeżdżanie się uprawnień za pomocą małych, powtarzalnych testów

Wykonuj lekką kontrolę uprawnień według harmonogramu lub po aktualizacjach: sprawdzaj kilka niezmiennych oryginałów, ostatnio przesłany plik, nowo wygenerowaną pochodną oraz każde zamontowane źródło biblioteki zewnętrznej. Szukaj nieoczekiwanych właścicieli, braku dostępu grupy, montowań tylko do odczytu, które stały się zapisywalne, lub ACL, które nie są już dziedziczone zgodnie z oczekiwaniami.

Następnie wykonaj kompleksowy test zapisu. Prześlij plik tymczasowy za pomocą standardowego klienta, pozwól Immich go przetworzyć, otwórz go i usuń za pośrednictwem aplikacji. Jeśli konfiguracja obejmuje biblioteki zewnętrzne lub ścieżki importu, dodaj po jednym reprezentatywnym pliku tymi ścieżkami i potwierdź, że Immich może go odczytać bez nieoczekiwanej zmiany własności.

Pętla zapobiegania jest kompletna dopiero wtedy, gdy nowe pliki nadal otrzymują zamierzoną tożsamość i dostęp po ponownym uruchomieniu Immich oraz po ponownym uruchomieniu hosta. Jeśli po którymkolwiek z tych zdarzeń uprawnienia wymagają ręcznej naprawy, system nadal się rozjeżdża; napraw regułę tworzenia lub mapowanie tożsamości przed rozszerzeniem dostępu.