Ánh xạ ID người dùng với NFS trên Synology NAS

Tôi có hộp NAS Synology (chạy DSM 5.1) và tôi đã xuất một thư mục qua NFS. Tôi đang cố gắn nó vào hộp Ubuntu của mình.

Nó chủ yếu hoạt động tốt, nhưng tôi gặp vấn đề với ánh xạ của người dùng và nhóm. Trên hộp Ubuntu, tôi là 1000 (roger), gid 1000 (roger). Trên Synology, tôi có uid 1026 (roger), nhóm 100 (người dùng).

Nếu tôi sử dụng NFSv3, nó sử dụng các giá trị uid / gid số, điều đó có nghĩa là quyền sở hữu bị rối tung trên Synology.

Nếu tôi chỉ truy cập vào mount NFS từ cùng một hộp Ubuntu, sử dụng cùng một người dùng, điều này sẽ ổn, nhưng tôi cũng truy cập vào thư mục từ hộp Windows, sử dụng CIFS (SMB), có nghĩa là các quyền là Sai lầm.

Nếu tôi sử dụng NFSv4 ( mount -o nfsvers=4), với các cài đặt mặc định trên Synology, thì các tệp thuộc sở hữu của roger.usersSynology sẽ xuất hiện do sở hữu roger.userskhi được xem từ hộp Ubuntu. Điều này là tốt

Tuy nhiên, khi tôi touchmột tập tin:

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

Nó kết thúc thuộc sở hữu của 1000.1000trên Synology và được hiển thị là sở hữu nobody.4294967294khi được xem từ hộp Ubuntu.

Mọi thứ tôi có thể tìm thấy về chủ đề trên các diễn đàn Synology đều có từ năm 2011, khi NFSv4 không được hỗ trợ hoặc bao gồm những người hỏi cùng một câu hỏi và sau đó từ bỏ.

Để hoàn thiện, /etc/exportscó:

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

... và tôi đang gắn nó trên hộp Ubuntu với:

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

Tôi đã tìm thấy một số gợi ý rằng đó sec=syscó thể là một vấn đề: Tại sao ánh xạ uid / gid NFSv4 không hoạt động với AUTH_UNIX (AUTH_SYS) , nhưng điều đó không có giải pháp.

Có một cách đơn giản để khắc phục vấn đề này? Có cách nào phức tạp hơn ( ho Kerberos ho ) để giải quyết vấn đề này không?

Nghiêm túc mà nói, nếu Kerberos là câu trả lời, tôi sẽ thực hiện cú đánh đó, nhưng tôi muốn biết trước khi lãng phí một đống thời gian cho nó.

Cập nhật : trong khi tài liệu Synology nói về các tùy chọn Kerberos khác nhau, tôi không thể tìm thấy chúng trong UI. Bản phát hành ghi chú "Nếu hương vị bảo mật của Kerberos được thực hiện ...". Tôi đã tìm thấy (nhưng không thể tìm lại) một trang ngụ ý rằng nó có thể không nằm trên một số mô hình nhất định. Tôi có DS211, theo trang Thông tin hệ thống. Có lẽ tôi đã hết may mắn?

Để ánh xạ ID NFSv4 hoạt động chính xác, cả máy khách và máy chủ phải đang chạy idmapdtrình nền ID Mapper và có cùng Domaincấu hình /etc/idmapd.conf.

Bằng cách này, Máy khách NFS của bạn gửi thông tin đăng nhập ID của nó như roger@example.comtrong các lệnh NFS trên dây và máy chủ bản đồ NFS Server của bạn ánh xạ tới người dùng được gọi rogertrên Máy chủ NFS. UID và GID không quan trọng, chúng được ánh xạ trên mỗi hệ thống bởi idmapper.

Tuy nhiên tôi không bận tâm với điều đó trên Synology. Thư mục chia sẻ của tôi có các quyền sau:

• Quyền
  • Người dùng địa phương
    • Quản trị viên = đọc / ghi
• Quyền NFS
  • Bí đao
    • Ánh xạ tất cả người dùng vào quản trị

Điều này dẫn đến anonuid=1024,anongid=100( adminngười dùng và usersnhóm) được thêm vào xuất trong /etc/exportsNAS.

Máy khách NFS của tôi (không có ID Mapper đang chạy) gửi các lệnh NFS của tôi với tư cách là người dùng của tôi ( 1000:1000) và vì UID và GID không tồn tại trên NAS, nên nó dịch UID và GID của 1024:100tôi để tôi được coi là Người dùng quản trị viên có toàn quyền.

Đây là một cách sử dụng NFS cực kỳ không chuyên nghiệp và không an toàn cho môi trường kinh doanh, nhưng đối với tôi để truy cập các tệp của mình ở nhà thì đó là hành vi lạm dụng hành vi NFS được tôi chấp nhận.

Một tùy chọn khác là làm cho rogerUID và GID giống nhau trên NFS Client và NAS, sau đó bạn có thể sử dụng NFSv4 mà không cần ID Mapping, hoặc sau đó bạn có thể sử dụng NFSv3 chỉ dựa trên UID và GID.

Tôi đã thực sự vật lộn với cùng một vấn đề. Tôi đã trải qua nỗi đau lớn khi thiết lập máy chủ Kerberos với Docker trên Synology, thiết lập ánh xạ ID và tôi vẫn không thích hành vi đó. Kerberos quá phức tạp và khó có thể tiếp tục khởi động lại và tự động hóa. Thêm vào đó, ô mặc định của các tệp mới được tạo là 0000 và mọi tệp mới được tạo ở chế độ 777, bất kể ô địa phương của tôi là gì.

Giải pháp của tôi tương tự như của suprjami, nhưng tôi đã đưa nó đi xa hơn một chút:

• Tạo người dùng mới với giao diện người dùng web Synology, đặt tên cho nó giống như roger.remote . Thực hiện tương tự cho một nhóm người dùng và đặt tên giống như tên người dùng.
• Trên Synology là root, chỉnh sửa / etc / passwd và thay đổi roger.remote UID thành 1000 và GID thành 1000
• chỉnh sửa / etc / nhóm và thay đổi nhóm roger.remote thành 1000
• Trong giao diện người dùng web Synology, đặt squash thành "tất cả người dùng thành quản trị viên" và lưu
• Khi root lại, chỉnh sửa / etc / export và thay đổi UID / GID thành anonuid=1000,anongid=1000
• Khởi động lại NFS với /usr/syno/etc.defaults/rc.sysv/S83nfsd.sh restart
• Đây cũng là một chút hacky - nhưng chmod 777 /volume1. Tôi đã có rất nhiều vấn đề kỳ lạ với thư mục nhà của tôi được gắn kết. KDE sẽ không bắt đầu vì glibcaccess() hàm sẽ trả về quyền truy cập bị từ chối trên thư mục NFS được gắn kết. (Nhưng bất kỳ thư mục con nào cũng hoạt động) Firefox cũng gặp vấn đề tương tự, nơi nó từ chối lưu tệp vào thư mục được gắn vì kiểm tra truy cập. Mặc dù các quyền là chính xác và tôi có thể chạm / tạo / ghi tệp trong thư mục được gắn. Việc thay đổi thư mục cha / volume1 thành thế giới có thể ghi được đã khắc phục được sự cố ngu ngốc đó và đánh lừa các ứng dụng khách để ghi vào nó.
• Loại bỏ tất cả các ACL hệ thống tập tin khỏi chia sẻ. Thông qua rất nhiều thử nghiệm ngẫu nhiên, tôi thấy rằng các ACL này gây ra vấn đề với mặt nạ chế độ của các tệp được tạo. Tôi không phải là bậc thầy ACL, vì vậy có lẽ có một giải pháp thanh lịch hơn. Là root trên Synology, làm synoacltool -del /volume1/myshare. Bạn sẽ thấy +biểu tượng bị xóa khỏi đầu ra ls -l.
• Thay đổi quyền sở hữu của chia sẻ cho người dùng mới của bạn: chown roger.remote:roger.remote /volume1/myshare
• Thay đổi chế độ thành 755: chmod 755 /volume1/myshare
• Gắn âm lượng trên máy khách, kiểm tra quyền, nó sẽ hoạt động! Đảm bảo cũng chạm vào một tệp và xác minh ô bash của bạn được áp dụng chính xác.

$ um 
0002
$ cd / mnt / myshare
$ kiểm tra cảm ứng
$ ls -l kiểm tra
-rw-rw-r-- 1 roger roger 0 ngày 21 tháng 10 lúc 18 giờ 15 phút

Trên Synology bạn sẽ thấy:

# ls -l / volume1 / myshare / test
-rw-rw-r-- 1 roger.remote roger.remote 0 ngày 21 tháng 10 lúc 18 giờ 15 phút

Thưởng thức!