Źródło prawidłowo wskazuje warstwę odpowiedzialną za własność: gdy kontener tworzy katalog wewnątrz zamontowanego folderu ZimaOS, nowy katalog zwykle dziedziczy tożsamość i sposób działania umask procesu uruchomionego wewnątrz kontenera, a nie uprawnienia, które mieliśmy nadzieję automatycznie wymusić na folderze nadrzędnym.
Dlatego nawet folder nadrzędny z prawem zapisu dla wszystkich użytkowników może nadal zawierać nowo utworzone podfoldery root:root z uprawnieniami 0755. Jeśli aplikacja działa jako root i używa domyślnej wartości umask, podfoldery należące do roota są spodziewanym rezultatem, chyba że obraz obsługuje PUID/PGID, określonego użytkownika kontenera, dziedziczenie grupy przez setgid, domyślne listy ACL lub inny model uprawnień.
Przykład ze źródła dotyczył zamontowanego folderu kopii zapasowej
Użytkownik opisał ścieżkę taką jak:
/media/Daten/Backupw której nowo tworzone podfoldery otrzymywały:
root:root
drwxr-xr-xUżytkownik inny niż root, na przykład o UID 999, mógł wtedy odczytywać dane, ale nie mógł tworzyć plików w tych nowych podfolderach.
Folder nadrzędny 0777 nie wymusza własności podfolderów
Uprawnienie do zapisu w folderze nadrzędnym pozwala procesowi kontenera utworzyć element podrzędny. Nie sprawia jednak automatycznie, że element ten odziedziczy właściciela lub grupę folderu nadrzędnego, chyba że reguły systemu plików i grup zostały skonfigurowane tak, aby zapewnić takie zachowanie.
UID/GID twórcy oraz umask procesu określają zwykły rezultat.
Używaj PUID/PGID tylko wtedy, gdy obraz kontenera je obsługuje
Wiele obrazów w stylu LinuxServer udostępnia zmienne środowiskowe PUID i PGID. Inne obrazy całkowicie ignorują te zmienne i wymagają użycia pola user: w Dockerze albo ustawień właściwych dla danej aplikacji.
Aktualne wskazówki IceWhale dotyczące Syncthing wyraźnie zalecają sprawdzenie rzeczywistych identyfikatorów użytkownika ZimaOS za pomocą:
id -u username
id -g usernamea następnie wpisanie tych wartości w polach PUID/PGID aplikacji.
Zobacz aktualny przykład PUID/PGID dla ZimaOS.
umask określa, które bity uprawnień zostaną usunięte podczas tworzenia
Aplikacja, która tworzy katalogi z bazowym trybem 0777 przy typowej wartości umask 022, utworzy katalogi z uprawnieniami 0755. W ramach współpracy grupowej można użyć innej wartości umask, jeśli aplikacja ją obsługuje.
Nie ustawiaj globalnie skrajnie liberalnej wartości umask tylko po to, aby naprawić działanie jednej aplikacji.
setgid może pomóc zachować wspólną grupę w nowych podfolderach
W natywnych linuksowych systemach plików ustawienie bitu setgid na współdzielonym katalogu może sprawić, że nowo tworzone elementy podrzędne odziedziczą grupę tego katalogu. Jest to przydatne, gdy wiele usług lub użytkowników celowo współpracuje w ramach jednej grupy.
Nie zmienia to identyfikatora użytkownika procesu tworzącego element i może działać inaczej na zamontowanych systemach plików NTFS/exFAT, które emulują własność uniksową za pomocą opcji montowania.
Domyślne listy ACL zapewniają bardziej precyzyjne dziedziczenie
W systemach plików obsługujących listy ACL POSIX domyślne wpisy ACL mogą określać uprawnienia otrzymywane przez nowo utworzone elementy podrzędne. Często jest to bardziej przejrzyste niż wielokrotne uruchamianie rekursywnego chmod po każdym zadaniu tworzenia kopii zapasowej.
Przed poleganiem wyłącznie na konfiguracji w powłoce należy sprawdzić, czy bieżący interfejs ZimaOS udostępnia pełny mechanizm ACL dla danej ścieżki pamięci.
Źródło opisuje prośbę o funkcję, a nie istniejące ustawienie ZimaOS
Autor poprosił o globalną kontrolę PUID/PGID, przełącznik dziedziczenia, obsługę umask, wsparcie dla setgid oraz interfejs graficzny do rekursywnego naprawiania uprawnień. W wątku nie ma odpowiedzi IceWhale potwierdzającej wdrożenie tych funkcji.
Nie przedstawiaj listy próśb jako aktualnie dostępnych opcji w ustawieniach.
Najpierw napraw tożsamość aplikacji, zanim zmienisz rekursywnie cały dysk
Jeśli aplikacja do tworzenia kopii zapasowych wielokrotnie odtwarza foldery należące do roota, uruchamianie chown -R po każdym zadaniu usuwa jedynie objaw. Najpierw prawidłowo skonfiguruj tożsamość kontenera, grupę i umask, a następnie napraw tylko dotknięte drzewo katalogów.
Bieżące ustawienia aplikacji ZimaOS pozwalają przeglądać mapowania woluminów i konfigurację aplikacji, natomiast dokładne zmienne uprawnień zależą od obrazu.
Najczęstsze pytania dotyczące własności zamontowanych folderów
Dlaczego podfolder może stać się root:root w folderze nadrzędnym z prawem zapisu?
Ponieważ proces wewnątrz kontenera utworzył go jako root, a folder nadrzędny nie nadpisuje automatycznie tożsamości twórcy.
Czy PUID i PGID działają z każdym obrazem Dockera?
Nie. Są to zależne od obrazu konwencje zmiennych środowiskowych, a nie uniwersalne zmienne Dockera.
Czy IceWhale potwierdziło istnienie globalnego przełącznika dziedziczenia uprawnień w źródłowym wątku?
Nie. Wątek zawiera prośbę o funkcję, ale nie ma potwierdzenia jej wdrożenia.
