NFS 中的檔案訪問許可權會限制掛接 NAS 磁碟區之後，使用者和群組可以執行的動作。 模式位元是 Azure NetApp Files 中 NFS 檔案存取權限的重要功能。
NFS 模式位元
NFS 中的模式位元存取權限使用存取控制的標準數值表示法，提供檔案和資料夾的基本存取權限。 模式位可以搭配 NFSv3 或 NFSv4.1 使用，但模式位是保護 NFSv3 的標準選項，如 RFC-1813 中所定義。 下表顯示這些數值如何對應至存取控制。
| 模式位元數值 |
|---|
| 1 – 執行 (x) |
| 2：寫入 (w) |
| 3：寫入/執行 (wx) |
| 4：讀取 (r) |
| 5：讀取/執行 (rx) |
| 6：讀取/寫入 (rw) |
| 7：讀取/寫入/執行 (rwx) |
數值會套用至存取控制的不同區段：擁有者、群組及其他所有人，這表示基本 NFSv3 沒有細微的使用者存取控制。 下圖顯示的範例說明如何建構模式位元存取控制，以搭配使用 NFSv3 物件。
Azure NetApp Files 不支援 POSIX ACL。 因此，當使用NTFS安全性樣式的磁碟區並通過像是Active Directory LDAP這樣的名稱服務執行有效的UNIX到Windows名稱對應時，只有NFSv3支持細粒度的ACL。 或者，您可以使用 NFSv4.1 搭配 Azure NetApp Files 和 NFSv4.1 ACL。
下表比較NFSv3模式位與 NFSv4.x ACL 之間的許可權粒度。
| NFSv3 模式位 | NFSv4.x ACL |
|---|---|
|
|
如需詳細資訊，請參閱 瞭解 NFSv4.x 存取控制清單 ACL。
黏性位、setuid 和 setgid
當使用 NFS 掛載模式位時，檔案和目錄的擁有權取決於建立這些檔案和目錄的使用者的 uid 和 gid。 此外，當進程執行時，它會以啟動它的使用者身分執行，因此會有對應的許可權。 具有特殊許可權（例如 setuid、setgid黏性位）可以控制此行為。
Setuid
setuid位是由許可權擁有者位的執行部分中的 「s」 所指定。 位元 setuid 的設定可讓可執行檔案以檔案擁有者的身分執行，而不是以嘗試執行檔案的使用者身分執行。 例如，/bin/passwd 應用程式預設啟用 setuid 位元，因此當使用者嘗試變更密碼時，應用程式會以 root 權限執行。
# ls -la /bin/passwd
-rwsr-xr-x 1 root root 68208 Nov 29 2022 /bin/passwd
setuid如果移除位，密碼變更功能將無法正常運作。
# ls -la /bin/passwd
-rwxr-xr-x 1 root root 68208 Nov 29 2022 /bin/passwd
user2@parisi-ubuntu:/mnt$ passwd
Changing password for user2.
Current password:
New password:
Retype new password:
passwd: Authentication token manipulation error
passwd: password unchanged
setuid還原位時，passwd 應用程式會以擁有者 （root） 的形式執行並正常運作，但僅適用於執行 passwd 命令的使用者。
# chmod u+s /bin/passwd
# ls -la /bin/passwd
-rwsr-xr-x 1 root root 68208 Nov 29 2022 /bin/passwd
# su user2
user2@parisi-ubuntu:/mnt$ passwd user1
passwd: You may not view or modify password information for user1.
user2@parisi-ubuntu:/mnt$ passwd
Changing password for user2.
Current password:
New password:
Retype new password:
passwd: password updated successfully
Setuid 對目錄沒有任何影響。
Setgid
setgid位可用於檔案和目錄。
使用目錄時，setgid 可用來繼承位集在父目錄下方所建立之檔案和資料夾的擁有者群組。 如同 setuid，可執行檔位會變更為 「s」 或 「S」。。
備註
大寫「S」表示尚未設定可執行位，例如當目錄權限為「6」或「rw」時。
例如：
# chmod g+s testdir
# ls -la | grep testdir
drwxrwSrw- 2 user1 group1 4096 Oct 11 16:34 testdir
# who
root ttyS0 2023-10-11 16:28
# touch testdir/file
# ls -la testdir
total 8
drwxrwSrw- 2 user1 group1 4096 Oct 11 17:09 .
drwxrwxrwx 5 root root 4096 Oct 11 16:37 ..
-rw-r--r-- 1 root group1 0 Oct 11 17:09 file
對於檔案，setgid 的行為與 類似 setuid，可執行檔會使用群組擁有者的群組許可權來執行。 如果使用者位於擁有者群組中，表示用戶有權在 setgid 設定時執行可執行檔。 如果他們不在群組中，則不會取得存取權。 例如，如果系統管理員想要限制哪些用戶可以在用戶端上執行 mkdir 命令，他們可以使用 setgid。
一般而言， /bin/mkdir 具有755個具有根擁有權的許可權。 這表示任何人都可以在用戶端上執行 mkdir 。
# ls -la /bin/mkdir
-rwxr-xr-x 1 root root 88408 Sep 5 2019 /bin/mkdir
若要修改行為以限制哪些使用者可以執行 mkdir 命令，請變更擁有 mkdir 應用程式的群組，將 /bin/mkdir 的許可權變更為 750，然後設置 setgid 位至 mkdir。
# chgrp group1 /bin/mkdir
# chmod g+s /bin/mkdir
# chmod 750 /bin/mkdir
# ls -la /bin/mkdir
-rwxr-s--- 1 root group1 88408 Sep 5 2019 /bin/mkdir
因此，應用程式會以group1的許可權執行。 如果使用者不是的成員 group1，則使用者無法存取執行 mkdir。
User1 是 group1 的成員，但 user2 不是。
# id user1
uid=1001(user1) gid=1001(group1) groups=1001(group1)
# id user2
uid=1002(user2) gid=2002(group2) groups=2002(group2)
在此變更之後， user1 可以執行 mkdir，但 user2 無法執行 ，因為 user2 不在 中 group1。
# su user1
$ mkdir test
$ ls -la | grep test
drwxr-xr-x 2 user1 group1 4096 Oct 11 18:48 test
# su user2
$ mkdir user2-test
bash: /usr/bin/mkdir: Permission denied
粘性位
黏性位只用於目錄，而且在使用時，會控制該目錄中可以修改哪些檔案，而不論其模式位許可權為何。 設定黏性位時，只有檔案擁有者 （和 root） 可以修改檔案，即使檔案許可權顯示為 “777”。
在下列範例中，目錄「sticky」位於 Azure NetApp Files 磁碟區中，並具有廣泛的開放權限，但已設定黏著位元。
# mkdir sticky
# chmod 777 sticky
# chmod o+t sticky
# ls -la | grep sticky
drwxrwxrwt 2 root root 4096 Oct 11 19:24 sticky
資料夾內是不同使用者所擁有的檔案。 全部都有777個許可權。
# ls -la
total 8
drwxrwxrwt 2 root root 4096 Oct 11 19:29 .
drwxrwxrwx 8 root root 4096 Oct 11 19:24 ..
-rwxr-xr-x 1 user2 group1 0 Oct 11 19:29 4913
-rwxrwxrwx 1 UNIXuser group1 40 Oct 11 19:28 UNIX-file
-rwxrwxrwx 1 user1 group1 33 Oct 11 19:27 user1-file
-rwxrwxrwx 1 user2 group1 34 Oct 11 19:27 user2-file
一般而言，任何人都可以修改或刪除這些檔案。 但由於父資料夾已設定黏性位，因此只有檔案擁有者可以變更檔案。
例如，user1 無法修改或移除 user2-file：
# su user1
$ vi user2-file
Only user2 can modify this file.
Hi
~
"user2-file"
"user2-file" E212: Can't open file for writing
$ rm user2-file
rm: can't remove 'user2-file': Operation not permitted
相反地， user2 無法修改和刪除 user1-file ，因為它們不擁有檔案，而且黏性位是在父目錄上設定。
# su user2
$ vi user1-file
Only user1 can modify this file.
Hi
~
"user1-file"
"user1-file" E212: Can't open file for writing
$ rm user1-file
rm: can't remove 'user1-file': Operation not permitted
不過，root用戶仍然可以移除檔案。
# rm UNIX-file
若要變更根用戶的檔案修改能力，您必須透過 Azure NetApp Files 的匯出政策規則，將根用戶改成其他使用者。 如需詳細資訊，請參閱 root squashing。
Umask
在 NFS 作業中，可以透過模式位來控制許可權，以利用數值屬性來判斷檔案和資料夾存取權。 這些模式位會決定讀取、寫入、執行和特殊屬性。 在數值上，許可權會以下列方式表示：
- Execute = 1
- Read = 2
- 寫 = 4
總許可權取決於新增或減去上述的組合。 例如：
- 4 + 2 + 1 = 7 （可以做一切）
- 4 + 2 = 6 （讀取/寫入）
如需詳細資訊，請參閱 UNIX 許可權說明。
Umask 是一項功能，可讓系統管理員限制用戶端所允許的許可權層級。 根據預設，大部分用戶端的 umask 會設定為 0022。 0022 表示從該用戶端建立的檔案會指派給 umask。 umask 會從物件的基本權限中減去。 如果磁碟區具有 0777 許可權，並使用 NFS 掛接至具有 0022 的 umask 用戶端，則從用戶端寫入該磁碟區的物件具有 0755 存取權（0777 – 0022）。
# umask
0022
# umask -S
u=rwx,g=rx,o=rx
不過，許多作系統不允許使用執行許可權建立檔案，但允許資料夾具有正確的許可權。 因此，以 umask 0022 建立的檔案最後可能會有 0644 的許可權。 下列範例使用 RHEL 6.5：
# umask
0022
# cd /cdot
# mkdir umask_dir
# ls -la | grep umask_dir
drwxr-xr-x. 2 root root 4096 Apr 23 14:39 umask_dir
# touch umask_file
# ls -la | grep umask_file
-rw-r--r--. 1 root root 0 Apr 23 14:39 umask_file