Mapowanie identyfikatora użytkownika za pomocą NFS na serwerze Synology NAS

Mam urządzenie Synology NAS (z systemem DSM 5.1) i wyeksportowałem katalog przez NFS. Próbuję zamontować go na moim systemie Ubuntu.

W większości działa dobrze, ale mam problemy z mapowaniem użytkowników i grup. W polu Ubuntu jestem uid 1000 (roger), gid 1000 (roger). Na Synology mam UID 1026 (Roger), grupa 100 (użytkownicy).

Jeśli używam NFSv3, używa liczbowych wartości uid / gid, co oznacza, że ​​własność jest pomieszana w Synology.

Gdybym miał kiedykolwiek uzyskiwać dostęp tylko do montażu NFS z tego samego urządzenia Ubuntu, używając tego samego użytkownika, byłoby dobrze, ale uzyskiwałbym również dostęp do katalogu z urządzenia Windows za pomocą CIFS (SMB), co oznacza, że ​​uprawnienia są źle.

Jeśli używam NFSv4 ( mount -o nfsvers=4), z domyślnymi ustawieniami Synology, wtedy pliki należące roger.usersdo Synology wyglądają na posiadane przez, roger.usersgdy przeglądamy je z okna Ubuntu. To jest dobre.

Jednak gdy mam touchplik:

roger@ubuntu$ touch /mounts/diskstation/music/foo

Kończy się własnością 1000.1000Synology i jest pokazywany jako własność, nobody.4294967294gdy oglądany jest z okna Ubuntu.

Wszystko, co mogę znaleźć na ten temat na forach Synology, jest datowane na rok 2011, kiedy NFSv4 nie był obsługiwany, lub składa się z osób zadających to samo pytanie, a następnie poddających się.

Dla kompletności /etc/exportsma:

/volume1/music  10.0.0.0/24(rw,async,no_wdelay,root_squash,insecure_locks,sec=sys,anonuid=1025,anongid=100)

... i montuję go na pudełku Ubuntu za pomocą:

mount -t nfs diskstation:/volume1/music /mounts/diskstation/music/ -o rw,nfsvers=4

Znalazłem kilka wskazówek, że sec=sysmoże to być problem: Dlaczego mapowanie UID / gid NFSv4 nie działa z AUTH_UNIX (AUTH_SYS) , ale to nie ma rozwiązania.

Czy istnieje prosty sposób na obejście tego problemu? Czy jest bardziej skomplikowana ( kaszel Kerberos kaszel ) sposób rozwiązać ten problem?

Poważnie, jeśli Kerberos jest odpowiedzią, wezmę to uderzenie, ale chciałbym wiedzieć, zanim stracę na to sporo czasu.

Aktualizacja : podczas gdy dokumentacja Synology mówi o różnych opcjach Kerberos, nie mogę ich znaleźć w interfejsie użytkownika. Informacje o wersji mówią „Jeśli zaimplementowany zostanie smak bezpieczeństwa Kerberos ...”. Znalazłem (ale nie mogę ponownie znaleźć) stronę, która sugeruje, że może nie być w niektórych modelach. Mam DS211, zgodnie ze stroną Informacje o systemie. Może nie mam szczęścia?

Aby mapowanie identyfikatorów NFSv4 działało poprawnie, zarówno klient, jak i serwer muszą działać z idmapddemonem Mapowania identyfikatorów i mieć tę samą Domainkonfigurację /etc/idmapd.conf.

W ten sposób klient NFS wysyła dane uwierzytelniające, takie jak [email protected]w poleceniach NFS w sieci, a program idmapper serwera NFS odwzorowuje je na użytkownika wywołanego rogerna serwerze NFS. UID i GID nie mają znaczenia, są one mapowane w każdym systemie przez idmapper.

Jednak nie przejmuję się tym na mojej Synology. Mój folder współdzielony ma następujące uprawnienia:

• Uprawnienia
  • Użytkownicy lokalni
    • Administrator = odczyt / zapis
• Uprawnienia NFS
  • Miąższ
    • Przypisz wszystkich użytkowników do administratora

Powoduje to dodanie anonuid=1024,anongid=100( adminużytkownika i usersgrupy) do eksportu /etc/exportsna serwerze NAS.

Mój klient NFS (który nie ma uruchomionego programu mapującego ID) wysyła moje polecenia NFS jako mój użytkownik ( 1000:1000), a ponieważ UID i GID nie istnieją na serwerze NAS, tłumaczy mój identyfikator UID i GID, 1024:100więc jestem traktowany jako Administrator, który ma pełne uprawnienia.

Jest to strasznie nieprofesjonalne i niepewne korzystanie z NFS w środowisku biznesowym, ale tylko dla mnie, aby uzyskać dostęp do moich plików w domu, jest to nadużycie zachowania NFS, które jest dla mnie dopuszczalne.

Inną opcją jest ustawienie rogeridentyfikatora UID i GID na kliencie NFS i serwerze NAS tak, aby można było używać NFSv4 bez mapowania ID lub NFSv3, który opiera się tylko na UID i GID.

Naprawdę zmagam się z dokładnie tym samym problemem. Przeszedłem przez ogromny ból związany z konfiguracją serwera Kerberos z Dockerem na Synology, skonfigurowałem mapowanie identyfikatorów i nadal nie podobało mi się to zachowanie. Kerberos jest zbyt przeprojektowany i trudny do kontynuowania po ponownym uruchomieniu i automatycznym montażu. Ponadto domyślną umaską nowo utworzonych plików był 0000, a każdy nowy plik był tworzony w trybie 777, niezależnie od tego, jaki był mój lokalny umask.

Moje rozwiązanie było podobne do rozwiązania suprjami, ale poszedłem trochę dalej:

• Utwórz nowego użytkownika za pomocą internetowego interfejsu użytkownika Synology, nazwij go jakoś roger.remote. Zrób to samo dla grupy użytkowników i nazwij ją tak samo jak nazwa użytkownika.
• Na Synology jako root, edytuj / etc / passwd i zmień roger.remoteUID na 1000, a GID na 1000
• edytuj / etc / group i zmień także grupę roger.remotena 1000
• W internetowym interfejsie Synology ustaw squash na „wszyscy użytkownicy do administrowania” i zapisz
• Jako root ponownie edytuj / etc / export i zmień UID / GID na anonuid=1000,anongid=1000
• Uruchom ponownie NFS za pomocą /usr/syno/etc.defaults/rc.sysv/S83nfsd.sh restart
• Jest to również nieco zuchwałe - ale chmod 777 /volume1. Miałem wiele dziwnych problemów z zamontowanym katalogiem domowym. KDE nie uruchomi się, ponieważ access()funkcja glibc zwróci odmowę dostępu w zamontowanym katalogu NFS. (Ale wszystkie podkatalogi działałyby) Firefox miał również podobny problem, ponieważ odmówił zapisania plików w zamontowanym katalogu z powodu kontroli dostępu. Mimo że uprawnienia były prawidłowe, mogłem dotknąć / utworzyć / zapisać pliki w zamontowanym katalogu. Zmiana katalogu nadrzędnego / woluminu1 na świat do zapisu naprawiła ten głupi problem i oszukała aplikacje klienckie, aby do niego pisać.
• Usuń wszystkie listy ACL systemu plików z udziału. Podczas wielu losowych eksperymentów odkryłem, że te listy ACL powodują problemy z maską trybu tworzonych plików. Nie jestem mistrzem ACL, więc może jest bardziej eleganckie rozwiązanie. Zrób jako root na Synology synoacltool -del /volume1/myshare. Powinieneś zobaczyć +symbol usunięty z wyjścia ls -l.
• Zmień własność udziału na nowego użytkownika: chown roger.remote:roger.remote /volume1/myshare
• Zmień tryb na 755: chmod 755 /volume1/myshare
• Zamontuj wolumin na kliencie, przetestuj uprawnienia, powinno działać! Upewnij się, że dotknąłeś również pliku i sprawdź, czy umash bash jest poprawnie zastosowany.

$ umask 
0002
$ cd / mnt / myshare
$ test dotykowy
$ ls -l test
-rw-rw-r-- 1 roger roger 0 października 21 18:15 test

Na Synology powinieneś zobaczyć:

# ls -l / volume1 / myshare / test
-rw-rw-r-- 1 roger.remote roger.remote 0 21 października 18:15 test

Cieszyć się!