Dlaczego uprawnienia do plików ulegają zmianie po przeniesieniu ich na NAS?

Pliki mogą działać normalnie na komputerze, zewnętrznym dysku lub w folderze pobierania, a następnie stać się tylko do odczytu, niewidoczne dla aplikacji lub niedostępne po przeniesieniu na NAS. Zazwyczaj nie oznacza to uszkodzenia danych pliku. Oznacza to, że pliki weszły do nowego systemu plików z innym modelem własności i uprawnień.

Przeniesienie między urządzeniami jest zwykle wykonywane jako kopiowanie, a następnie usunięcie źródła. NAS tworzy nowe pliki, używając połączonej tożsamości SMB lub NFS, ACL folderu docelowego, wartości UID i GID, umask, użytkownika kontenera oraz zasad tworzenia po stronie serwera. Najszybszym sposobem rozwiązania problemu jest ustalenie, kto utworzył pliki, kto jest ich obecnym właścicielem oraz który użytkownik lub proces jest odmawiany dostępu.

Przenoszenie plików na NAS zwykle tworzy nowe pliki

Przeciągnięcie folderu na NAS może wyglądać jak zwykłe przeniesienie w Eksploratorze Windows lub Finderze. Jednak pod spodem dysk źródłowy i NAS to oddzielne systemy plików. Klient odczytuje oryginalne dane, tworzy nowe obiekty w miejscu docelowym i usuwa oryginały po pomyślnym transferze.

Różni się to od przenoszenia pliku między dwoma folderami w tym samym systemie plików, gdzie system może jedynie zaktualizować lokalizację pliku w katalogu. Opis zachowania kopiowania i przenoszenia Microsoft wyjaśnia, że obiekty kopiowane na inny wolumin dziedziczą uprawnienia nowego folderu, podczas gdy przeniesienie w obrębie tego samego woluminu zwykle zachowuje istniejące uprawnienia.

To rozróżnienie wyjaśnia, dlaczego „Wytnij i wklej” nie gwarantuje, że własność, wpisy ACL lub atrybuty rozszerzone pozostaną identyczne po przeniesieniu na NAS. System docelowy nie po prostu przenosi oryginalny obiekt systemu plików.

ACL miejsca docelowego decydują, jakie uprawnienia dziedziczą nowe pliki

Jeśli każdy nowo skopiowany plik otrzymuje te same nieoczekiwane uprawnienia, zazwyczaj ważniejszy jest katalog nadrzędny niż plik źródłowy. Miejsce docelowe może mieć odziedziczone wpisy ACL, domyślne ACL POSIX, flagi ACL NFSv4 lub specyficzne dla NAS ustawienia uprawnień.

Na przykład folder współdzielony może być skonfigurowany tak, aby nowe pliki dziedziczyły dostęp dla grupy rodzinnej, grupy multimedialnej lub konkretnego konta SMB. Brak flagi dziedziczenia może spowodować odwrotny efekt: użytkownicy mogą mieć dostęp do katalogu głównego zestawu danych, ale nie do nowych plików w jego wnętrzu.

Systemy uprawnień w stylu TrueNAS rozróżniają modele POSIX i NFSv4/SMB ACL. Ważne jest, że dziedziczenie NFSv4 i SMB ACL może kontrolować nowe pliki i foldery, podczas gdy domyślne ustawienia POSIX i granice zestawów danych zachowują się inaczej. Przed zmianą pojedynczych plików sprawdź ACL i flagi dziedziczenia w folderze docelowym.

NAS używa połączonego konta SMB

Gdy komputer z Windows lub macOS kopiuje plik przez SMB, NAS zwykle nie zachowuje lokalnej tożsamości użytkownika klienta. Tworzy plik docelowy jako konto uwierzytelnione do udziału SMB lub jako konto, do którego przypisana jest ta sesja.

Dlatego plik należący do użytkownika Windows na komputerze źródłowym może należeć do kenneth, użytkownik_nas, gośćlub inną tożsamością po stronie NAS po transferze. Zapisane poświadczenie SMB może też spowodować, że jeden komputer tworzy pliki pod innym właścicielem niż inny komputer.

Sprawdź aktywną nazwę użytkownika SMB, zamiast zakładać, że używane jest logowanie na pulpicie. Odłącz udział, w razie potrzeby wyczyść przestarzałe poświadczenia i połącz się ponownie z kontem NAS, które powinno posiadać lub zarządzać plikami.

Dostęp do udziału i dostęp do pliku to oddzielne warstwy uprawnień

Użytkownik może otworzyć udział SMB i przeglądać foldery, ale nadal nie móc edytować, zmieniać nazwy ani usuwać pliku. Oznacza to, że udział sieciowy jest dostępny; nie dowodzi jednak, że system plików przyznał żądaną operację.

Zasady na poziomie udziału decydują, czy klient SMB lub NFS może wejść do udziału oraz czy połączenie jest tylko do odczytu, czy do odczytu i zapisu. Podstawowy system plików ocenia wtedy właściciela, grupę, bity trybu, wpisy ACL i zasady dziedziczenia dla każdego pliku i katalogu.

Rozwiąż problemy na obu warstwach. Udział oznaczony jako do odczytu/zapisu nie może nadpisać ACL systemu plików, który odmawia zapisu, a pobłażliwe tryby systemu plików nie pomagają, gdy konto SMB jest ograniczone przez konfigurację udziału.

ACL w stylu Windows i tryby POSIX nie mapują się idealnie

uprawnienia Windows mogą zawierać wielu użytkowników i grupy, jawne wpisy zezwalające i odmawiające, flagi dziedziczenia oraz oddzielne prawa do odczytu, zapisu, usuwania i modyfikacji. Tradycyjne bity trybu POSIX ograniczają dostęp do właściciela, grupy i innych.

Samba i systemy operacyjne NAS muszą tłumaczyć między tymi modelami. Panel zabezpieczeń Windows może pokazywać szczegółowy ACL, mimo że ls -l wyświetla tylko uproszczoną reprezentację. Natomiast uruchomienie chmod może zmieniać bity trybu bez prawidłowego odbudowania ACL w stylu Windows, którego oczekują klienci SMB.

Jeśli zestaw danych NAS używa NFSv4 lub ACL SMB, sprawdź pełny ACL przez interfejs NAS lub polecenie obsługujące ACL. Nie zakładaj, że plik pokazujący rwxrwx--- opowiadają całą historię uprawnień.

Niezgodności UID i GID wpływają na Linux, NFS i aplikacje

Systemy Linux zwykle określają własność przez numeryczne identyfikatory użytkowników i grup. Nazwa użytkownika jest tylko etykietą powiązaną z tymi liczbami.

Dwa systemy mogą wyświetlać użytkownika o nazwie media podczas gdy jeden używa UID 1000, a drugi UID 1001. Dla Linuksa i NFS to różne tożsamości. Plik należący do UID 1000 może być niedostępny dla aplikacji działającej jako UID 1001, nawet jeśli ich widoczne nazwy użytkowników wyglądają identycznie.

Sprawdź wartości numeryczne na NAS, hoście, kliencie i w aplikacji:

id media
ls -ln /path/to/files
stat /path/to/files/example.mkv

Porównuj liczby, a nie tylko wyświetlane nazwy. Jeśli wiele systemów musi zapisywać te same dane, wyrównaj wymagane wartości UID/GID lub utwórz wspólną grupę z odpowiednimi uprawnieniami.

SMB i NFS mogą zapisywać ten sam zestaw danych jako różni użytkownicy

Problemy z uprawnieniami często pojawiają się stopniowo, gdy klienci SMB i NFS mają jednocześnie dostęp do zapisu do tego samego katalogu. Pliki przesłane przez SMB mogą należeć do jednego użytkownika NAS, podczas gdy pliki tworzone przez NFS mogą mieć numeryczne UID z innego systemu.

Oba protokoły mogą również stosować różne zasady ACL i mapowania tożsamości. W efekcie folder może zawierać pliki, które dla użytkownika wyglądają identycznie, ale mają różnych właścicieli, grupy, maski lub wpisy dziedziczone.

W miarę możliwości wybierz jeden główny protokół zapisu. Gdy SMB i NFS muszą współdzielić zestaw danych, wyrównaj numeryczne ID, wspólne grupy, domyślne ACL, wartości umask i zachowanie przy tworzeniu przed umieszczeniem w nim danych produkcyjnych.

Kontenery Docker dodają kolejną tożsamość użytkownika

Plik może być czytelny przez SMB, ale niedostępny dla Plex, Jellyfin, Nextcloud, pobieracza lub kontenera kopii zapasowej. Docker może zamontować poprawną ścieżkę, podczas gdy proces wewnątrz kontenera nadal nie ma uprawnień do odczytu lub zapisu.

Proces kontenera działa pod własnym UID i GID. Jeśli ta tożsamość nie odpowiada właścicielowi lub dozwolonej grupie na zamontowanej ścieżce NAS, aplikacja otrzymuje Odmowa dostępu. Montowanie wolumenu sprawia, że katalog jest widoczny; nie omija autoryzacji systemu plików.

Powszechnym rozwiązaniem jest dopasowanie UID i GID kontenera do tożsamości uprawnionej do korzystania z zamontowanego wolumenu. Sprawdź faktyczną tożsamość procesu, zamiast polegać wyłącznie na polu PUID lub PGID pokazanym w pliku Compose:

docker exec container-name id
docker exec container-name ls -ln /data
docker exec container-name test -w /data && echo "Zapis możliwy"

Jeden kontener może tworzyć pliki, których inny nie może odczytać

To często zdarza się w stosach automatyzacji mediów. Kontener pobierania pomyślnie zapisuje ukończony plik, ale serwer multimediów nie może go zeskanować lub organizator nie może go zmienić nazwy.

Aplikacje mogą używać różnych wartości UID/GID lub różnych umasków. Jeśli pobierający tworzy pliki jako 600, tylko jego właściciel może je czytać i zapisywać. Tryb taki jak 640 pozwala grupie na odczyt, ale tylko wtedy, gdy obie aplikacje dzielą właściwą grupę.

Dla współdzielonych katalogów aplikacji użyj zaplanowanej grupy właściciela, dodaj niezbędne tożsamości aplikacji do tej grupy i wybierz umask, który zapewnia grupie wymagany dostęp. Naprawa tylko starych plików nie pomoże, jeśli pobierający będzie nadal tworzył nowe pliki z restrykcyjnymi trybami.

Umask i zasady tworzenia na serwerze kontrolują nowe uprawnienia

Jeśli stare pliki działają, ale każdy nowy plik jest niedostępny, prawdopodobną przyczyną jest proces tworzenia. Każdy program zaczyna od żądanego trybu pliku, a jego umask usuwa wybrane uprawnienia przed utworzeniem pliku.

Samba może także używać ustawień takich jak maska tworzenia, maska katalogu, wymuś użytkownika, lub wymuś grupę. Interfejsy NAS mogą ukrywać te ustawienia za szablonami uprawnień, presetami folderów współdzielonych lub opcjami dziedziczenia.

Utwórz jeden plik testowy przez każdą ścieżkę: Windows SMB, macOS SMB, menedżer plików NAS, NFS oraz każdy odpowiedni kontener. Porównaj wynikowego właściciela, grupę, tryb i ACL. To szybko ujawnia, która ścieżka tworzenia powoduje błędne uprawnienia.

Różne narzędzia transferu zachowują różne metadane

Finder, Windows Explorer, interfejs webowy NAS, cp, oraz rsync nie gwarantują identycznych wyników. Niektóre zachowują znaczniki czasu, inne mogą utrzymać tryby POSIX, a jeszcze inne po prostu tworzą nowe pliki według reguł docelowych.

Przed wyborem metody migracji zdecyduj, które właściwości muszą zostać zachowane:

• Zawartość plików i struktura katalogów
• Czasy modyfikacji
• Uprawnienia POSIX
• Właściciel i grupa
• Wpisy ACL
• Rozszerzone atrybuty
• Linki symboliczne

Dla zwykłych dokumentów rodzinnych lub plików multimedialnych dziedziczenie na docelowym urządzeniu może być lepsze niż zachowywanie kont komputerów źródłowych, które nie istnieją na NAS. Dla danych aplikacji, katalogów domowych Linuxa lub migracji serwerów zachowanie własności i metadanych ACL może być niezbędne.

Rsync nie zachowuje wszystkich atrybutów za pomocą jednego podstawowego polecenia

Rsync jest przydatny do kontrolowanych migracji NAS, ale wynik zależy od jego opcji, uprawnień użytkownika wykonującego oraz możliwości systemów plików źródłowego i docelowego.

Tryb archiwizacji zachowuje wspólne metadane, w tym tryby, znaczniki czasu, grupy i własność tam, gdzie jest to dozwolone. Dodatkowe opcje są wymagane, gdy migracja musi zachować uprawnienia, ACL i rozszerzone atrybuty za pomocą rsync. Typowy test Linux do Linuxa może używać:

rsync -aAX --numeric-ids --dry-run /source/ user@nas:/destination/

Polecenie -A opcja zachowuje ACL i -X zachowuje rozszerzone atrybuty, gdy obie strony je obsługują. --numeric-ids powinno być używane świadomie, ponieważ zachowanie numerycznego właściciela, który nie ma ważnego konta na NAS, może odtworzyć właśnie tę niezgodność, której chcesz uniknąć.

Miejsce docelowe rsync zamontowane przez SMB może nie zachowywać się jak system plików NAS

Uruchamianie rsync z komputera do lokalnie zamontowanego udziału SMB nie zawsze jest równoważne z uruchamianiem rsync przez SSH bezpośrednio na systemie plików NAS. Warstwa SMB może mapować właścicieli, przekształcać ACL lub odrzucać próby ustawienia atrybutów.

Użytkownik wykonujący kopiowanie SMB może nie mieć uprawnień do przypisania dowolnego właściciela, nawet jeśli rsync tego wymaga. System plików docelowy może również obsługiwać inny model ACL niż źródłowy.

Najpierw przetestuj mały reprezentatywny katalog. Sprawdź pliki bezpośrednio na NAS po transferze, nie tylko przez zamontowany udział klienta. Potwierdź właściciela, tryby, ACL, rozszerzone atrybuty i dostęp aplikacji przed migracją całego zestawu danych.

Wstępne ustawienia uprawnień NAS mogą nadpisywać proste bity trybu

Niektóre systemy NAS zarządzają dostępem przez szablony ACL zestawu danych i rozszerzone metadane, a nie tylko tradycyjne tryby właściciel/grupa/inni. Może to sprawić, że ręczne chmod mogą wydawać się udane, podczas gdy SMB lub aplikacja nadal odmawia dostępu.

Zestaw danych może być również skonfigurowany do ponownego stosowania dziedziczonych reguł podczas tworzenia nowych plików lub edycji uprawnień przez interfejs zarządzania. Mieszanie ACL zarządzanych przez GUI z powtarzającymi się zmianami w wierszu poleceń może prowadzić do niespójnego stanu.

Wybierz jeden model uprawnień i zarządzaj nim konsekwentnie. Jeśli zestaw danych jest skonfigurowany dla ACL SMB/NFSv4, używaj edytora ACL NAS lub narzędzi obsługujących ACL zamiast wielokrotnego zastępowania struktury poleceniami trybu POSIX.

Ponowna instalacja NAS niekoniecznie resetuje uprawnienia do danych

Uprawnienia zwykle należą do plików i zestawu danych systemu plików, a nie tylko do konfiguracji systemu operacyjnego NAS. Ponowna instalacja systemu rozruchowego może więc pozostawić te same niedostępne wpisy właściciela i ACL na zaimportowanej puli pamięci masowej.

Przykład z społeczności TrueNAS ilustruje, jak uprawnienia systemu plików pozostają przypisane do puli pamięci masowej i muszą być dopasowane do odpowiednich użytkowników oraz konfiguracji dostępu. Pokazuje to również ryzyko dokonywania dużych, rekurencyjnych zmian bez wcześniejszego zrozumienia zamierzonego modelu tożsamości.

Przed ponowną instalacją lub odbudową usług sprawdź właściciela zestawu danych, grupę, ACL i użytkowników aplikacji. Dane mogą być nienaruszone i wymagać tylko prawidłowego przywrócenia zasad dostępu.

Dlaczego rekursywny chmod 777 nie jest prawdziwą naprawą

Gdy tysiące plików staje się niedostępnych, chmod -R 777 wygląda na szybki sposób przywrócenia dostępu. Nadaje uprawnienia do odczytu, zapisu i wykonywania właścicielowi, grupie i każdej innej lokalnej tożsamości.

To może ujawnić prywatne dane, pozwolić niepowiązanym usługom modyfikować pliki, ustawić uprawnienia do wykonywania na zwykłych dokumentach i uszkodzić starannie dziedziczony ACL. Nie naprawia też błędnego właściciela, niezgodnego UID kontenera, brakującego członkostwa w grupie ani złego mapowania tożsamości SMB.

Użyj zamiast tego zamierzonego modelu dostępu: ustal właściwego właściciela i wspólną grupę, odbuduj odpowiedni ACL, ustaw tryby katalogów i plików osobno oraz popraw przyszłe dziedziczenie i ustawienia umask. Testuj na małym folderze przed zastosowaniem zmian rekursywnych.

Napraw uprawnienia od tożsamości na zewnątrz

Zacznij od odmówionego użytkownika lub procesu, a nie od polecenia, które ma to naprawić. Użytkownik SMB, serwer multimediów i kontener kopii zapasowej mogą wymagać różnych poziomów dostępu.

Dla każdego dotkniętego procesu pracy zanotuj:

• Użytkownik lub proces próbujący uzyskać dostęp
• Numeryczne UID i GID, jeśli dotyczy
• Używany protokół lub montowanie
• Aktualny właściciel i grupa pliku
• Pełny ACL i wpisy dziedziczone
• Rzeczywisty wymagany dostęp: odczyt, tworzenie, modyfikacja lub usuwanie

Następnie zmodyfikuj tylko warstwę, która jest błędna. Dodaj użytkownika do dozwolonej grupy, popraw właściciela, napraw ACL, dopasuj UID kontenera lub zaktualizuj regułę tworzenia. Unikaj nadawania szerszego dostępu niż wymaga proces pracy.

Postępuj według warstwowego porządku rozwiązywania problemów

Zmiana ACL udziału, tożsamości kontenera, eksportu NFS i trybów plików jednocześnie niszczy przydatne dowody. Testuj jedną warstwę uprawnień na raz.

Zacznij od jednego dotkniętego pliku i jednego użytkownika lub aplikacji. Gdy ten mały przypadek zadziała, utwórz nowy plik przez normalny proces i potwierdź, że naprawa zapobiega powrotowi problemu.

Zapobiegaj problemom z uprawnieniami przed dużą migracją NAS

Naprawa uprawnień w setkach tysięcy plików jest znacznie trudniejsza niż przetestowanie modelu dostępu przed migracją. Utwórz mały folder docelowy z tym samym ACL i konfiguracją aplikacji, planowaną dla końcowego zestawu danych.

Skopiuj kilka typów plików, zagnieżdżone katalogi, pliki tylko do odczytu, skrypty wykonywalne oraz pliki z rozszerzonymi atrybutami. Przetestuj je z każdej wymaganej ścieżki: SMB, NFS, interfejs NAS, oprogramowanie do kopii zapasowych i odpowiednie kontenery.

Pełną migrację rozpocznij dopiero, gdy nowe pliki konsekwentnie otrzymują poprawnego właściciela, grupę, ACL i dostęp aplikacji. Zachowaj migawkę lub kopię zapasową przed zastosowaniem jakichkolwiek rekurencyjnych zmian własności lub uprawnień do istniejących danych.

Ostateczne wnioski

Uprawnienia plików psują się po przeniesieniu danych na NAS, ponieważ transfer zwykle tworzy nowe obiekty systemu plików. Obiekty te są zarządzane przez konto NAS używane do transferu, ACL docelowego, wartości UID/GID, umask, mapowanie protokołu oraz tożsamość aplikacji lub kontenera.

Nie zaczynaj od chmod 777Najpierw odpowiedz na trzy pytania: kto utworzył plik, kto jest jego obecnym właścicielem i której tożsamości odmówiono dostępu. Następnie sprawdź dostęp do udziału, ACL systemu plików, dziedziczenie, identyfikatory kontenera i przyszłe reguły tworzenia.

Udana naprawa powinna zrobić dwie rzeczy: przywrócić odpowiedni dostęp do istniejących plików oraz zapewnić, że następny plik skopiowany, pobrany lub utworzony na NAS automatycznie otrzyma poprawne uprawnienia.

FAQ

Dlaczego skopiowane pliki dziedziczą uprawnienia folderu NAS?

Transfer do NAS zwykle tworzy nowe pliki na innym systemie plików. Nowe obiekty są zazwyczaj przypisywane uprawnienia z ACL folderu docelowego, flag dziedziczenia i reguł tworzenia po stronie serwera.

Dlaczego mogę otworzyć pliki NAS przez SMB, ale mój kontener Docker nie może?

Sesja SMB i kontener używają różnych tożsamości. Sprawdź rzeczywisty UID i GID kontenera, numeryczną własność zamontowanej ścieżki, członkostwo w grupie oraz czy montowanie jest tylko do odczytu.

Czy powinienem użyć chmod 777 do naprawy udziału NAS?

Nie. Przyznaje każdej lokalnej tożsamości szeroki dostęp, może uszkodzić dziedziczenie ACL i nie rozwiązuje problemu nieprawidłowej własności lub mapowania UID/GID. Zdefiniuj zamierzonych użytkowników i grupy, a następnie napraw własność i ACL odpowiednio.

Czy rsync może zachować uprawnienia plików NAS?

Może zachować uprawnienia POSIX i inne metadane, gdy wybrane opcje, uprawnienia wykonawcze i oba systemy plików je obsługują. ACL i rozszerzone atrybuty wymagają dodatkowych opcji, takich jak -A i -X.

Dlaczego nowe pliki ciągle się psują po naprawieniu starych plików?

Ścieżka tworzenia jest nadal nieprawidłowa. Sprawdź dziedziczone ACL folderu docelowego, tożsamość SMB lub NFS, umask aplikacji, reguły tworzenia Samby oraz UID/GID kontenera.