NAS 的「使用者權限」怎麼設：群組與 ACL 的實際差異
使用者帳號與群組的關係
「使用者帳號」代表一個可以登入 NAS 的身分，通常包含帳號名稱、密碼、以及一些個人設定（例如是否允許 SSH 登入、是否有兩步驟驗證）。「群組」則是使用者的集合，用來批次管理權限。一個使用者可以同時屬於多個群組，這點在大多數系統上都成立。
關鍵在於：當系統判斷「某個使用者能不能存取某個資料夾」時，它會把該使用者「本人」以及「他所屬的所有群組」的權限一起納入計算。這就產生了兩種常見的權限累加邏輯：一種是「取聯集」（只要任何一個群組有權限，就給過），另一種是「取最嚴格」（只要有任何一個群組被拒絕，就擋下）。不同 NAS 系統的預設行為不一樣，這也是為什麼同樣的群組設定，在 A 牌 NAS 上可以用、搬到 B 牌 NAS 就出問題。
舉例來說，小明同時屬於「業務部」與「專案A」兩個群組。「業務部」對「客戶名單」資料夾有讀寫權限，「專案A」對同一個資料夾只有唯讀權限。如果系統採「取聯集」，小明就能讀寫；如果採「取最嚴格」，小明就只能唯讀。多數企業級系統會採用「拒絕優先（Deny overrides Allow）」的規則，但家用 NAS 為了操作簡單，常常採用「允許優先」。這個差異在規劃權限時一定要先確認，否則你會發現「明明設了唯讀，怎麼還能寫」。
三種常見權限模型：POSIX、Windows ACL、混合模式
NAS 的權限模型大致可以分成三類。第一類是「POSIX 權限」，也就是 Linux／Unix 傳統的權限模型，把權限分成「擁有者（Owner）」、「群組（Group）」、「其他人（Others）」三個層級，每個層級各有讀（r）、寫（w）、執行（x）三種權限。這種模型簡單、效能好，但只能表達「三種人、三種權限」，對於「同一個資料夾要給五個不同群組不同權限」的需求就力不從心。
第二類是「Windows ACL」，也就是 Windows NTFS 檔案系統使用的權限模型。它允許一個檔案或資料夾擁有一長串「存取控制項目（ACE）」，每一項指定「某個使用者或群組」擁有「某種權限」（例如完全控制、修改、讀取與執行、寫入、特殊權限等），並且可以設定「允許」或「拒絕」。這種模型表達能力極強，可以做到非常細緻的權限控制，但設定起來也比較複雜，而且需要檔案系統支援（例如 ext4 搭配 ACL 套件、Btrfs、ZFS 等）。
第三類是「混合模式」，也就是多數現代 NAS 的預設做法：底層仍然是 POSIX 權限，但上層提供一個「ACL 介面」，讓管理者可以用類似 Windows ACL 的方式設定權限，系統再自動轉譯成底層可理解的格式。這種做法兼顧了相容性與易用性，但也意味著「你看到的 ACL 設定」與「系統實際套用的權限」之間可能有一層轉換，當權限行為不如預期時，就需要更仔細地排查。
群組權限（POSIX / 傳統模式）的實際運作方式
群組權限的核心精神是「分類管理」。你先建立群組（例如「家人」、「會計」、「訪客」），把使用者放進對應的群組，然後對資料夾設定「哪個群組可以讀、哪個群組可以寫」。這種模式的好處是「一次設定、整組生效」，當有新員工加入會計部，你只需要把他加入「會計」群組，他就自動擁有會計資料夾的權限，不需要逐一調整資料夾設定。
群組權限的優點與限制
群組權限最大的優點是「可預測性高」。因為權限只看「擁有者、群組、其他人」三層，任何一個使用者對任何一個檔案的最終權限，都可以用一個簡單的規則推導出來。這對於需要稽核、需要交接的環境非常重要：你可以很清楚地把「誰屬於哪個群組、哪個群組有什麼權限」寫成一張表，任何人接手都能看懂。
但群組權限的限制也很明顯。第一，一個檔案在 POSIX 模型下只能指定「一個群組」擁有權限（嚴格來說是「一個主要群組」，雖然可以透過 ACL 擴充，但那就不是純 POSIX 了）。所以如果你希望「業務部可讀寫、行銷部唯讀、會計部完全看不到」，你就必須把這個資料夾的群組設成「業務部」，然後用「其他人」來處理行銷部（但這樣一來，所有不屬於業務部的人都能唯讀，包括會計部）。這種「非黑即白」的模型，在需要「多群組、多層級」的場景就會卡住。
第二，群組權限的「繼承」行為比較單純：子資料夾通常會繼承父資料夾的群組與權限，但如果你在某個子資料夾手動改了權限，它就可能與父資料夾不一致，而且不容易看出來。第三，群組權限對於「單一使用者例外」的處理很麻煩。例如「業務部所有人都能讀寫客戶名單，但工讀生只能讀」，你就必須把工讀生從「業務部」移出，另外建一個「業務部-唯讀」群組，久而久之群組數量就會失控。
實例：家庭成員共用資料夾怎麼設
假設一個四口之家：爸爸、媽媽、小明（高中生）、小美（小學生）。需求是：家庭相片資料夾「全家都能讀寫」、爸爸的工作資料夾「只有爸爸能讀寫」、小明的作業資料夾「小明可讀寫、爸妈可讀」、小美的資料夾「小美可讀寫、爸妈可讀」、共享電影資料夾「全家可讀、只有爸爸可寫」。用群組權限怎麼設？
第一步，建立群組：「家長組」包含爸爸媽媽，「小孩組」包含小明小美，「全家組」包含四个人。第二步，設定資料夾權限：「家庭相片」設為「全家組：讀寫」；「爸爸工作」設為「家長組：讀寫，但只有爸爸是擁有者」——這裡就會遇到問題，因為「家長組」包含媽媽，但媽媽不應該能讀寫爸爸的工作資料夾。於是只能改成「爸爸：讀寫、媽媽：讀取」，但這樣就不是「群組」而是「個別使用者」設定了。第三步，「小明作業」設為「小明：讀寫、家長組：讀取」，這沒有問題；「小美資料夾」設為「小美：讀寫、家長組：讀取」，也沒問題；「電影」設為「全家組：讀取、爸爸：讀寫」，這也可以。
你會發現，只要出現「群組內某個人需要例外」的需求，群組模型就開始捉襟見肘。家用環境尚且如此，公司環境的例外只會更多。這就是為什麼多數 NAS 在群組權限之外，還會提供 ACL 介面。
ACL（存取控制清單）到底差在哪裡
ACL 的核心概念是「每一個檔案或資料夾，都帶著一張自己的規則清單」。這張清單上可以有很多條規則，每條規則指定「某個使用者或群組」擁有「某種權限」，並且可以標記為「允許」或「拒絕」。當使用者嘗試存取時，系統會從清單第一條開始比對，找到符合的規則就套用（或依系統設計，先檢查所有「拒絕」規則）。
ACL 的核心概念：每個檔案都有自己的規則清單
打個比方：群組權限像是「社區大門的門禁卡」，你屬於哪一戶、那一戶有什麼門禁權限，你就擁有什麼權限。ACL 則像是「每一間房間門上貼著的名單」，名單上寫著「張三可進、李四不可進、王五隻能看不能動」。前者管理的是「人」，後者管理的是「門」。所以 ACL 的設定是「掛在資料夾上」的，而不是「掛在人身上」的。
這種設計帶來兩個重要特性。第一，ACL 可以做到「同一個資料夾，給 A 群組讀寫、給 B 群組唯讀、給 C 使用者完全控制、拒絕 D 使用者存取」，完全不需要為此新增群組。第二，ACL 的規則可以「繼承」：你可以設定某個資料夾的 ACL 讓子資料夾「繼承」這些規則，這樣新建立的子資料夾會自動套用相同的權限，不需要逐一設定。
但 ACL 也帶來新的複雜度。第一，規則是有「順序」的，不同順序可能導致不同結果（尤其在「允許」與「拒絕」混用時）。第二，ACL 的權限種類比 POSIX 多很多，例如「讀取權限」、「寫入權限」、「執行」、「刪除」、「變更權限」、「取得擁有權」等，這些權限還可以組合。第三，ACL 的「繼承」行為如果設定不當，會出現「子資料夾權限與父資料夾不同」的狀況，而且不容易從介面上看出來。
繼承（Inheritance）與權限傳遞
繼承是 ACL 最容易讓人踩雷的地方。簡單說，繼承就是「子資料夾自動套用父資料夾的權限規則」。例如你對「公司共用」資料夾設定了「業務部：讀寫」，並勾選「套用到子資料夾」，那麼在「公司共用」底下新建的「2024 客戶名單」資料夾，就會自動擁有「業務部：讀寫」的權限。
但問題來了：如果你在「2024 客戶名單」這個子資料夾上，手動把「業務部」的權限改成「唯讀」，會發生什麼事？這取決於系統設計。有些系統會「覆蓋」繼承來的規則，有些系統會「新增」一條規則，還有些系統會「阻斷繼承」（也就是切斷與父資料夾的關聯，從此不再繼承）。這三種行為的結果完全不同，而多數 NAS 的介面並沒有把這件事講得很清楚。
更麻煩的是「移動」與「複製」的差異。在大多數系統上，把一個資料夾「移動」到另一個位置，它會保留原本的 ACL 規則（因為移動只是改變路徑，不改變 inode）；但把資料夾「複製」到另一個位置，新資料夾會套用「目標位置」的繼承規則（因為複製是建立新檔案）。這意味著同一個資料夾，用移動和複製會得到不同的權限結果，如果管理者沒有意識到這件事，就會出現「明明搬過去了，權限怎麼不一樣」的困惑。
實例：部門資料夾的細緻權限
回到前面的公司情境。假設有三個部門：業務部、行銷部、會計部，以及一個「全公司共用」資料夾。需求是：「全公司共用」所有人可讀寫；「業務部」只有業務部可讀寫，但行銷部可讀取（為了拿素材）；「會計部」只有會計部可讀寫，其他人完全看不到；「主管專區」只有三位主管可讀寫，其他人看不到。
用 ACL 怎麼設？第一步，建立「全公司」群組包含所有人，對「全公司共用」設「全公司：讀寫」。第二步，對「業務部」設「業務部：讀寫、行銷部：讀取、其他：無」。第三步，對「會計部」設「會計部：讀寫、其他：無」。第四步，對「主管專區」設「主管群組：讀寫、其他：無」。整個過程不需要為「行銷部可讀業務部」這條規則新增任何群組，也不需要把行銷部的人塞進業務部群組。這就是 ACL 的威力。
但要注意：如果「業務部」資料夾底下有很多子資料夾，而你只對「業務部」最上層設了 ACL，子資料夾是否會繼承？這就要看你有沒有勾選「套用到子資料夾與檔案」。如果沒有勾，子資料夾可能還是套用預設權限（例如只有擁有者可存取），這時候業務部的人就會發現「上層進得去，子資料夾卻進不去」。這是 ACL 設定最常見的錯誤之一。
群組 vs ACL 的實際差異對照表
為了讓差異更清楚，以下用表格整理群組權限與 ACL 在各個面向的比較。這張表可以直接當作規劃權限時的檢查清單。
比較面向
群組權限（POSIX / 傳統模式）
ACL（存取控制清單）
管理單位
以「群組」為單位，權限掛在群組上
以「資料夾／檔案」為單位，權限掛在資料上
表達能力
三層（擁有者、群組、其他人），表達能力有限
可指定多個使用者與群組，表達能力強
例外處理
困難，需新增群組或改擁有者
容易，直接加一條規則即可
設定複雜度
低，規則單純
高，需注意順序、繼承、允許／拒絕
可預測性
高，規則可手動推導
較低，需實際測試確認
繼承行為
單純，子資料夾通常跟隨父資料夾
複雜，可選擇繼承、阻斷繼承、覆蓋
適用場景
家庭、小型團隊、角色單純的環境
多部門、交叉授權、需要精細控制的環境
跨系統相容性
高，Linux／Unix 普遍支援
中，需檔案系統與 NAS 系統支援
稽核與交接
容易，看群組成員名單即可
較難，需逐一檢查資料夾的 ACL
從表中可以看出，群組與 ACL 並不是「誰比較好」的問題，而是「適用場景不同」。群組適合「角色固定、變動少」的環境；ACL 適合「角色重疊、例外多」的環境。實務上，多數 NAS 會兩者並用：用群組處理「大分類」，用 ACL 處理「例外與交叉授權」。
什麼時候該用群組、什麼時候該用 ACL？
這個問題沒有標準答案，但可以歸納出幾個判斷原則。第一，如果某個權限需求「可以用一個群組表達」，就用群組。例如「會計部所有人對會計資料夾有讀寫權限」，這用群組最直覺，也最好維護。第二，如果某個權限需求「會讓群組數量爆炸」，就用 ACL。例如「行銷部需要讀取業務部的素材，但不需要寫入」，這用群組就要新增「業務部-唯讀給行銷部」這種奇怪的群組，用 ACL 只要加一條「行銷部：讀取」的規則。
判斷原則與建議流程
建議的流程是這樣：第一步，先列出「所有使用者」與「所有資料夾」，並在紙上畫出「誰需要碰哪個資料夾、需要什麼權限」。第二步，把「權限需求完全相同」的使用者歸成同一個群組，這是群組的基礎。第三步，檢查有沒有「跨群組的例外需求」（例如 A 群組需要讀 B 群組的資料），如果有，就標記為「需要用 ACL 處理」。第四步，先建立群組與基本的群組權限，確保「大方向正確」。第五步，再針對例外需求，用 ACL 逐一補上。第六步，實際用不同帳號登入測試，確認每個人都能看到該看的、不能看到不該看的。
這個流程的重點是「先群組、後 ACL」。因為群組權限比較好理解、好稽核，先把大架構用群組撐起來，再用 ACL 補洞，會比一開始就到處設 ACL 來得容易維護。反過來說，如果你一開始就用 ACL 處理所有權限，你會發現每個資料夾都有一堆規則，過三個月連自己都看不懂為什麼某條規則會在那裡。
另外一個實務建議是「盡量用允許、少用拒絕」。ACL 的「拒絕」規則優先權通常很高，一旦設了拒絕，即使其他規則允許，也可能被擋下。而且「拒絕」規則很容易在繼承時造成意外，例如你對某個子資料夾設了「拒絕某使用者」，但該使用者其實應該從父資料夾繼承權限，結果就被這條拒絕規則擋住。多數情況下，用「不給允許」來達成「拒絕」的效果會比較安全，除非你真的很需要「阻斷某個特定例外」。
常見的 NAS 權限設定陷阱與排錯
權限設定最讓人挫折的地方，不是「不會設」，而是「設了卻沒效」。以下整理幾個最常見的陷阱，以及對應的排錯方向。
權限設定了卻沒生效？五個檢查點
第一個檢查點是「使用者是否真的屬於該群組」。很多時候管理者以爲自己把某人加進群組了，但其實只加了「次要群組」而系統只認「主要群組」，或是加錯了帳號（例如加了「小明」而不是「小明2」）。請務必到使用者設定頁面確認「群組成員」清單，而不是只看群組頁面的成員列表。
第二個檢查點是「共用資料夾權限」與「資料夾 ACL」是否衝突。多數 NAS 有兩層權限：一層是「共用資料夾」層級的權限（決定誰能看到這個共用資料夾），另一層是「資料夾內部」的權限（決定誰能進到哪個子資料夾）。如果共用資料夾層級沒有給某個使用者權限，那麼即使內部 ACL 給了他完全控制，他還是看不到這個共用資料夾。反過來說，如果共用資料夾層級給了權限，但內部 ACL 沒給，他看得到資料夾但進不去。
第三個檢查點是「繼承是否正確套用」。請檢查父資料夾的 ACL 是否有勾選「套用到子資料夾與檔案」，以及子資料夾是否「阻斷繼承」。如果子資料夾阻斷了繼承，它就會有自己的獨立規則，父資料夾的設定不會影響它。
第四個檢查點是「快取與重新登入」。NAS 的權限判斷有時會快取，尤其是在 SMB／CIFS 連線下。如果使用者已經登入，權限變更可能不會立即生效，需要中斷連線或重新登入。有些系統甚至需要重啟 SMB 服務。這不是 bug，而是設計上的取捨，但很容易讓人誤以為「設定沒生效」。
第五個檢查點是「檔案系統是否支援 ACL」。如果你把硬碟格式化成不支援 ACL 的檔案系統（例如某些舊的 ext3 或 FAT32），那麼 ACL 設定介面可能還是存在，但實際套用時會被忽略或轉成 POSIX 權限。請確認你的儲存空間格式（Btrfs、ext4 with ACL、ZFS 等）有正確啟用 ACL 支援。
其他常見錯誤：Everyone 權限、巢狀群組、匿名存取
「Everyone」是另一個常見陷阱。很多系統預設會給「Everyone」某種權限（例如讀取），如果你沒有特別注意，可能會發現「明明沒給訪客權限，訪客卻看得到」。請務必檢查共用資料夾的權限清單中是否有「Everyone」或「來賓」項目，並依需求移除或限制。
「巢狀群組」（群組中包含群組）雖然方便，但並非所有 NAS 都完整支援，而且會讓權限計算變得更複雜。如果你的系統支援巢狀群組，請確保你理解它的權限累加邏輯；如果不支援，那就老老實實地把使用者放進群組，不要試圖用巢狀結構來偷懶。
「匿名存取」或「來賓帳號」也是資安漏洞的常見來源。有些 NAS 為了方便，會啟用「允許匿名使用者存取」或「來賓可讀取共用資料夾」，這些設定在內網可能無傷大雅，但一旦 NAS 對外開放，就等於把資料公開。建議除非有明確需求，否則一律關閉匿名存取。
實務建議：一套不會出事的權限規劃流程
最後，把前面的觀念整理成一套可執行的流程，適合家庭與小型辦公室參考。
第一步，「先定義角色，再定義人」。不要一開始就想「小明要什麼權限」，而是想「這個環境有哪些角色」（例如家長、小孩、訪客、主管、業務、會計）。角色定義清楚後，再把「人」放進「角色」裡。這一步的產出是一份「角色清單」與「人員對應表」。
第二步，「先定義資料分層，再定義權限」。把資料夾依「敏感度」與「共用範圍」分層，例如「公開區」（所有人可讀）、「部門區」（部門內可讀寫）、「敏感區」（特定人可讀寫）、「備份區」（只有管理者可存取）。這一步的產出是一份「資料夾清單」與「每一層的預設權限」。
第三步，「用群組實作大分類」。把角色轉成群組，把資料夾的預設權限設給對應群組。例如「家長組」對「家庭相片」有讀寫權限、「小孩組」對「家庭相片」有讀取權限。這一步的目標是「讓 80% 的權限需求用群組搞定」。
第四步，「用 ACL 處理例外」。把剩下 20% 的例外需求（例如「行銷部可讀業務部素材」、「工讀生只能讀客戶名單」）用 ACL 補上。這一步的重點是「每條 ACL 規則都要有明確理由」，並且把理由記錄下來（例如寫在資料夾名稱或文件裡），方便日後稽核。
第五步，「實際測試與交接」。用不同角色的帳號實際登入，測試「該看的看得到、不該看的看不到、該寫的寫得進去、不該寫的寫不進去」。測試完後，把「群組清單」、「資料夾權限表」、「ACL 例外清單」整理成一份文件，放在安全的地方。這份文件在人員異動或系統遷移時，會是救命稻草。
第六步，「定期檢視與清理」。每季或每半年檢查一次：有沒有離職員工的帳號還在？有沒有群組已經沒有成員？有沒有 ACL 規則已經失效？權限設定不是「設一次就永遠有效」，而是需要隨著組織變動持續調整。定期清理不只是資安要求，也能讓權限架構保持可讀性。
結語：權限不是「設好就好」，而是「持續維護」
NAS 的使用者權限設定，本質上是一場「方便」與「安全」的拉鋸。群組權限讓你用最少的規則管理最多的人，適合角色穩定的環境；ACL 讓你用最精細的規則處理最複雜的例外，適合角色重疊的環境。兩者沒有優劣，只有適用與否。
真正該避免的，是「沒有規劃就開始設」。很多人的 NAS 權限是在「遇到問題時臨時補救」的過程中長出來的，結果就是群組越開越多、ACL 規則越加越亂、最後沒有人搞得清楚誰有什麼權限。如果你正準備架設 NAS，或是正想整理既有的權限架構，建議照著本文的流程走一遍：先定義角色、再定義資料分層、用群組處理大分類、用 ACL 處理例外、實際測試、留下文件、定期清理。這樣做出來的權限架構，才會是「一年後還看得懂、還敢改」的架構。
最後提醒一句：權限設定的目的，不是「讓管理者覺得很安全」，而是「讓每個人在安全的前提下，順利完成該做的事」。與其追求「最嚴格的權限」，不如追求「最適合的權限」。畢竟，一套沒人看得懂、沒人敢動的權限規則，到頭來只會讓大家想辦法繞過它，那才是最大的資安風險。
💬 想說點什麼？
歡迎到留言板分享你的想法、心得或疑問。
💬 前往留言板 →