配置共享的只读、读写与目录权限

Azure Files 的访问需要同时通过网络、身份认证和授权检查。共享级角色决定是否能进入共享，目录和文件 ACL 决定具体能做什么。两层权限的关系

1. 按业务需求选择权限

希望的效果	共享级角色	目录权限与检查重点
能阅读，不能新增、修改或删除	Storage File Data SMB Share Reader	目标目录授予读取；检查其他组、继承和上级角色没有额外授权
能新增、修改和删除业务文件	Storage File Data SMB Share Contributor	对指定业务目录授予修改权限；不要因此授予全共享管理权
仅能访问本部门文件夹	按业务操作选 Reader 或 Contributor	给部门组配置对应目录 ACL，同时检查根目录遍历和继承
没有业务访问权	不授予相关共享角色	同时检查默认共享权限、继承角色和已有组成员关系
管理目录权限	使用受控的管理员身份	按选用的 ACL 工具配置必要管理权限，不给普通用户管理员级角色

Contributor 包含删除能力；“可以上传”不能简单等同于“只能上传”。只收文件、不能读取别人文件、不能删除等投递目录需求，需要单独设计高级 ACL 并测试，或使用专门的文件提交应用。共享级内置角色

2. 在具体共享上分配角色

纯云方案若还没有业务组，由获授权的管理员进入 Entra 管理中心 → Entra ID → 组 → 所有组 → 新建组。选择“安全”组，成员身份类型选“已分配”，分别为只读和编辑用途命名并添加测试成员。用于文件访问的业务组不需要开启“可分配 Microsoft Entra 角色”。混合身份方案按身份源要求在本地 AD 创建组并同步到 Entra。创建和管理组

操作路径：Portal → 存储账户 → 经典文件共享 → 目标共享 → 访问控制（IAM）。

点击“添加 → 添加角色分配”。
按用途搜索上述角色的完整英文名称，核对角色说明。
选择业务安全组作为成员。例如分别建立只读组和编辑组，避免逐个账号长期维护。
在“审阅 + 分配”中核对：范围为该文件共享，成员和角色正确，再保存。
等待权限传播后，使用组内测试用户重新建立连接。

搜索 SMB 并选择存储文件数据 SMB 共享读取者，避免选择资源管理用的 Reader · 点击查看原图

搜索并选择普通 AVD 测试用户；本例直接分配用户，业务环境优先维护安全组 · 点击查看原图

核对共享范围，必要时改用 Azure CLI

这次实跑中，Portal 审阅页生成的范围包含 fileServices/default/fileshares/…，与实际共享资源 ID 的 fileServices/default/shares/… 不一致。已使用实际资源 ID 修正并回读；此现象仅代表本次操作结果，不应视为所有租户都会出现。

遇到类似情况，先停止分配。可在有权操作的 Azure CLI 会话中获取真实 ID，再在该范围分配所需角色：

$subscriptionId = '<你的订阅 ID>'
$principalId = '<测试用户或业务组的对象 ID>'
$shareScope = az storage share-rm show `
  --subscription $subscriptionId --resource-group test-wiki `
  --storage-account stjylearnfiles1105 --name docs-readonly `
  --query id --output tsv

az role assignment create --subscription $subscriptionId `
  --assignee-object-id $principalId --assignee-principal-type User `
  --role 'Storage File Data SMB Share Reader' --scope $shareScope

az role assignment list --subscription $subscriptionId `
  --scope $shareScope --query '[].{Role:roleDefinitionName,Scope:scope}' --output table

业务组使用 --assignee-principal-type Group。为 team-work 分配读写权限时，重新获取该共享的 ID，并选择 Storage File Data SMB Share Contributor。不要把范围扩大到整个存储账户来绕过此问题。

资源管理用的 Reader、Contributor、Owner，与 SMB 数据角色用途不同。不要因为用户是资源组 Owner，就认定其以普通身份挂载共享一定成功；也不要把可获取账户密钥的管理员身份用于验证只读效果。

3. 配置目录 ACL

Entra Kerberos 为身份源时，Portal 支持为纯云或混合用户、组管理 ACL：

打开目标文件共享 → “浏览”。
根目录使用顶部“管理访问权限”；子目录或文件通过对应项目的“管理访问权限”打开。
选择目标组，编辑所需的读取或修改权限，并核对适用范围与继承。
保存后检查有效权限，特别是默认广泛组与继承项。

修改 Portal 中的可继承权限，不代表所有现有子项目会自动更新。已有文件需要按官方“管理继承”流程处理，再分别验证已有文件与新建文件。纯云身份使用 Portal 或官方 RestSetAcls 方案；不要用 Windows 资源管理器或 icacls 代替纯云身份 ACL 配置。工具支持、继承与操作步骤

本例使用官方 RestSetAcls 模块，在可访问专用终结点的管理环境中通过 REST 设置 ACL，并回读确认。使用 Entra 用户的实际安全标识符；保留 SYSTEM 与管理员项，给业务用户配置读取或修改及所需继承。published 子目录使用独立读取 ACL。没有给普通用户保存存储账户密钥，也没有使用密钥建立 SMB 映射。

管理工具的选用应与身份场景、网络和管理员权限匹配。若从 Portal 浏览目录，运行浏览器的管理环境也必须能够访问账户数据终结点；公共网络禁用后，本机直连失败不等于资源不存在。

优先用明确的组和允许权限表达业务范围；修改 ACL 前保存原配置，避免随意添加大范围拒绝项造成管理员或其他业务失去访问。

4. “只读”是否等于“禁止下载”

只读仍然允许读取文件内容，也通常允许把文件复制到有写权限的位置。 Reader 角色适合限制更改共享内容，不能用来保证文件只能看、不能带走。

如果希望限制“从 AVD 到本机”的传输，继续配置磁盘、剪贴板和打印机重定向。浏览器上传、邮件、同步客户端等其他通道，需要按应用和网络另行控制，不能靠一个文件共享角色全部阻断。

5. 用三个普通账号做验收

测试身份	打开文件	新建/覆盖	删除测试文件
只读组用户	成功	拒绝	拒绝
编辑组用户	成功	按授权成功	按授权成功
未授权用户	拒绝	拒绝	拒绝

只使用可丢弃的验收文件。每个账号分别登录自己的 AVD 会话，核对现有文件、新建文件、子目录和跨部门目录。角色或组成员发生变化后，重新登录并重建 SMB 连接，避免旧会话掩盖结果。