Dlaczego właściciele plików w kontenerze zmieniają się po skopiowaniu danych aplikacji?

Właściciele plików kontenera zmieniają się po skopiowaniu, gdy numeryczne wartości UID/GID nie zostaną zachowane lub środowisko docelowe ponownie mapuje albo nadpisuje te wartości.

Na domowym serwerze NAS ten sam plik może wyświetlać jedną nazwę użytkownika na hoście, a inną wewnątrz kontenera, ponieważ własność jest przechowywana jako liczby, a każde środowisko rozpoznaje te liczby za pomocą innej bazy kont. Kopie wykonywane przez interfejs graficzny, udział SMB, archiwum, powłokę roota, narzędzie migracji lub punkt wejścia kontenera również mogą zastąpić informacje o właścicielu. Najpierw zdiagnozuj tożsamość numeryczną, a następnie oddziel zachowanie podczas kopiowania, ustawienia użytkownika środowiska uruchomieniowego, skrypty startowe, przestrzenie nazw użytkowników i mapowanie systemów plików sieciowych, zanim zmienisz uprawnienia w całym drzewie danych aplikacji.

Porównaj numeryczne wartości UID i GID przed porównaniem nazw użytkowników

Sprawdź źródło i miejsce docelowe, wyświetlając numeryczne informacje o właścicielu, a nie tylko nazwy. Zapisz UID, GID, tryb, listy ACL, atrybuty rozszerzone i system plików dla jednego reprezentatywnego pliku oraz jego katalogu nadrzędnego — zarówno na hoście, jak i wewnątrz kontenera.

Dowiązania montowane przez Dockera udostępniają pliki hosta procesom, które mogą korzystać z innej bazy użytkowników. Dyskusja społeczności Dockera na temat uprawnień wyjaśnia, dlaczego niezawodny dostęp zależy od zgodności numerycznych wartości UID/GID, a nie wyłącznie od zgodności nazw użytkowników.

Jeśli liczby są identyczne, ale wyświetlane nazwy się różnią, własność mogła wcale się nie zmienić. Popraw dokumentację lub mapowanie kont zamiast rekurencyjnie przepisywać dane. Jeśli liczby się różnią, zachowaj zebrane informacje i przejdź do etapów kopiowania oraz uruchamiania.

Ustal, czy kopiowanie zachowało, czy odtworzyło informacje o właścicielu

Zapisz dokładną ścieżkę kopiowania: menedżer plików hosta, cp, rsync, archiwum tar, klient SMB/NFS, przywracanie kopii zapasowej, polecenie kopiowania Dockera lub tymczasowy kontener migracyjny. Każda metoda ma inne wartości domyślne dotyczące właściciela, grupy, list ACL i atrybutów rozszerzonych.

Kopiowanie uruchomione jako root może zachować numeryczną własność po użyciu jawnych opcji archiwizacji, podczas gdy inne narzędzie może utworzyć wszystkie pliki docelowe jako konto wykonujące kopiowanie. Niedawny problem z migracją kontenera pokazuje, jak skopiowane dane aplikacji mogą stać się nieczytelne, gdy docelowy UID różni się od tożsamości używanej przez aplikację.

Powtórz operację na jednym małym katalogu testowym i natychmiast sprawdź własność, zanim aplikacja zostanie uruchomiona. Jeśli liczby są już nieprawidłowe, popraw metodę kopiowania lub opcje przywracania. Jeśli zmieniają się dopiero po uruchomieniu, pozostaw kopiowanie bez zmian i zbadaj punkt wejścia kontenera.

Dopasuj użytkownika środowiska uruchomieniowego kontenera do właściciela danych na hoście

Sprawdź efektywnego użytkownika wewnątrz uruchomionego kontenera oraz numerycznego właściciela katalogu danych aplikacji zamontowanego przez dowiązanie. Sprawdź również user: w Compose, dodatkowe grupy, zmienne PUID/PGID specyficzne dla platformy oraz ustawienia konta właściwe dla danego obrazu.

Uruchomienie kontenera jako użytkownik inny niż root nie zapewnia automatycznie dostępu do katalogu hosta należącego do innej tożsamości numerycznej. Przypadek opisany na forum Dockera rozwiązuje problem przez dopasowanie użytkownika kontenera i uprawnień hosta, zamiast nadawania katalogowi uniwersalnych praw zapisu.

Wybierz jeden stabilny model własności dla aplikacji i opisz go w Compose. Dodaj tylko grupy wymagane do współdzielenia dostępu. Unikaj chmod 777, ponieważ ukrywa niezgodność tożsamości, osłabia separację i nie zachowuje zamierzonego właściciela dla przyszłych plików.

Featured

ZimaCube 2 Osobisty domowy NAS w chmurze

ZimaCube2

$799.00 - $2,499.00

Buy Now

Sprawdź, czy punkt wejścia zmienia własność podczas uruchamiania

Wiele obrazów uruchamia się na krótko jako root, tworzy brakujące katalogi, ustawia skonfigurowany UID/GID i rekurencyjnie zmienia własność, zanim obniży uprawnienia. Takie działanie może sprawić, że prawidłowe kopiowanie będzie wyglądać tak, jakby własność zmieniła się samoistnie po pierwszym uruchomieniu kontenera.

Środowiska uruchomieniowe kontenerów i obrazy mogą również oferować opcje montowania zmieniające własność. Zgłoszenie dotyczące Podmana wskazuje, że opcja :U może nadpisywać własność źródła, a skrypty punktu wejścia mogą wykonywać podobną rekurencyjną zmianę podczas uruchamiania aplikacji.

Uruchom kontener raz z widocznymi logami i monitoruj małe poddrzewo testowe. Wyszukaj w punkcie wejścia oraz informacjach o wydaniu obrazu frazy chown, migrację użytkownika, PUID/PGID i kroki naprawy uprawnień. Wyłącz lub ogranicz to działanie tylko wtedy, gdy obraz obsługuje stabilną alternatywę.

Uwzględnij rootless Docker, przestrzenie nazw użytkowników i systemy plików sieciowych

Rootless Docker i mapowanie przestrzeni nazw użytkowników tłumaczą identyfikatory kontenera na inny zakres hosta. NFS, CIFS i niektóre opcje montowania NAS mogą niezależnie mapować roota na użytkownika anonimowego lub wymuszać określony UID i GID dla wszystkich plików.

Zgłoszenie dotyczące uprawnień w rootless Docker pokazuje, że pliki mogą wyświetlać nieoczekiwaną własność, ponieważ tożsamość kontenera jest mapowana przez podrzędny zakres hosta. Wskazówką diagnostyczną jest mapowanie własności w przestrzeni nazw użytkowników, a nie typowy błąd kopiowania.

Sprawdź, czy ścieżka danych znajduje się na lokalnym systemie plików, NFS, CIFS, FUSE lub innym zamontowanym systemie, a następnie zapisz jego zachowanie dotyczące UID/GID, mapowania roota na użytkownika anonimowego i list ACL. Osobno przetestuj tworzenie plików z hosta i z kontenera. Nie wykonuj rekurencyjnego chown na udziale sieciowym, dopóki nie poznasz zasad identyfikacji obowiązujących po stronie serwera.

Napraw własność na podstawie znanej tożsamości aplikacji

Zatrzymaj aplikację, wykonaj kopię zapasową bieżących metadanych i określ dokładne wartości UID, GID, tryby katalogów, tryby plików, listy ACL oraz etykiety zabezpieczeń wymagane przez obraz. Poprawiaj tylko ścieżki należące do aplikacji, wyłączając współdzielone multimedia i niezwiązane zbiory danych.

Poradnik ZimaSpace dotyczący odróżniania problemów z uprawnieniami od montowania tylko do odczytu jest kolejnym krokiem, gdy prawidłowa własność nadal nie pozwala na zapis.

Uruchom ponownie kontener i utwórz, zmodyfikuj oraz usuń jeden plik testowy jako rzeczywisty użytkownik usługi. Następnie odtwórz kontener i powtórz test. Naprawa jest zakończona dopiero wtedy, gdy własność pozostaje stabilna po kopiowaniu, uruchomieniu, ponownym uruchomieniu hosta i odtworzeniu kontenera, a aplikacja może odczytywać i zapisywać dane bez szerokich wyjątków w uprawnieniach.