三层权限：共享权限、ACL 与文件系统权限

OMV 新手最常见的困惑是：「我明明在界面里给了读写权限，为什么还是写不进去？」原因几乎都是把几套互不相干的权限当成了一套。读完这篇，你能判断某个人通过某个协议为什么能或不能读写，也能选定一种不会自相矛盾的授权方式。

三层权限各是什么

层	在哪里设置	控制什么	谁会检查它
第 1 层：共享权限	存储器 → 共享文件夹（Storage → Shared Folders）的 权限（Permissions），或 用户 页的 共享文件夹权限；再加上 SMB 共享自己的选项（公开、只读、允许主机等）	谁能连上这个共享，连上后能读还是能写	只有 SMB 和 FTP
第 2 层：文件系统权限	创建共享文件夹时的 权限 下拉框；访问控制列表 对话框上半部分（所有者、用户组、其它）	磁盘上文件的属主、属组、其他人各自能不能读、写、执行	所有访问方式，最终都要过这一关
第 3 层：ACL	访问控制列表（Access control list）对话框里的用户/用户组表格	在属主、属组、其他人之外，给指定的用户或组单独加权限或禁止	和第 2 层一起，由内核检查

两个名字都叫「权限」的地方要分清：共享文件夹创建表单里的 权限 下拉框，改的是第 2 层；共享文件夹工具栏上的 权限 按钮，改的是第 1 层。OMV 官方文档把第 1 层叫「服务层」权限，界面上也有提示：这些设置用来配置服务里用户和组的访问权限，不会对文件系统的权限有影响。

哪种访问方式会经过哪一层

访问方式	第 1 层	第 2、3 层	说明
SMB	是	是	Samba 认证后，以登录用户的身份读写文件，所以文件系统权限完全生效
FTP（官方插件）	是	是	同上
NFS	否	是	NFS 用「客户端」地址和只读/读写选项控制，再按客户端传来的 UID、GID 检查文件系统权限
rsync 服务端	否	是	以模块里设置的用户和组身份读写
SSH、SFTP	否	是	以登录用户的身份
容器	否	是	以容器进程的 UID、GID（常见的 PUID、PGID）
本机 shell	否	是	以当前用户的身份

截至 2026-10-23 核查的源码，OMV 核心和官方插件里读取「共享权限」的只有 Samba 和 ProFTPD 两处。所以：

第 1 层只管 SMB 和 FTP。要让限制对所有访问方式都生效，必须落在第 2、3 层。

有效权限是各层的交集

共享权限只能在文件系统权限的基础上进一步收窄，不能放宽。以 SMB 为例，要写一个文件，需要同时满足：Samba 这一层允许写，并且文件系统（权限位加 ACL 的综合结果）允许这个用户写。ACL 属于文件系统层：它既可以给指定的用户额外的权限，也可以收窄，两者综合后才是文件系统层的结论。

共享权限	文件系统	结果
读/写	目录 2775 root:users，用户在 users 组	可读写
读/写	目录 770，用户不在目录的属组里	拒绝，文件系统挡住了
只读	目录可读写	只读，Samba 挡住了写
禁止读写	目录可读写	连不上 SMB，但 NFS、SFTP 不受影响
没有任何条目	目录可读写	任何已认证的用户都能连上并读写

OMV 怎样把共享权限翻译给 Samba

打开共享文件夹的 权限 对话框，每个用户和用户组有四种状态：读/写（Read/Write）、只读（Read-only）、禁止读写（No access）、未设置（再点一次已选中的按钮就取消）。生成 SMB 配置时的规则是（前三条以 SMB 共享的 公开 为「否」为前提）：

• 没有任何条目：所有已认证用户都能连上。Samba 里 valid users 为空就表示任何用户都可以登录。
• 有「读/写」或「只读」条目：只有这些用户和这些组的成员能连上，其他人被拒。
• 「禁止读写」条目：这些用户和组的成员被明确拒绝连接。
• 「只读」和「读/写」：分别进入 Samba 的 read list 和 write list，决定连上之后能不能写。
• SMB 共享上勾选了「只读」：对所有人只读，共享权限里的「读/写」不能覆盖它，因为 OMV 在这时不会生成 write list。
• 公开（Public）设为「允许访客」：共享权限不再限制谁能连接，「禁止读写」也失效，任何人都能连，没提供凭据的按访客（系统用户 nobody）访问。共享权限只负责区分已登录用户的读写。设为「仅访客」时，共享权限整个被忽略。

用户和组同时出现时，结果取决于 Samba 对列表的处理，容易出人意料。只按组授权，不要给同一个人既设用户条目又靠组条目，是最省心的做法。

共享权限里没有 users 组

users 是系统组，不在共享权限对话框的列表里。要按组授权，先建自己的用户组，见 用户与用户组。

推荐做法

1. 家庭场景尽量不动文件系统层。默认的 2775 root:users 加上「所有家人都在 users 组」，已经是「全家可读写」。想区分谁能连哪个共享，用第 1 层按组授权就够，见 设置共享文件夹权限。
2. 共享给多种协议，或要精确到子目录时，限制落在第 2、3 层：用专用用户组加目录权限，再用 ACL 补例外。
3. 别把同一件事在三层里各做一遍。选定「以哪一层为准」，其他层保持默认，否则排错时你要在三处找矛盾。
4. 始终通过组授权。人员变动时只改组成员，不用回头改每个共享。
5. 访问共享用普通用户，不用 admin。admin 不能被授权，也没有 SMB 密码。
6. ACL 是最后的手段，不是起点。用得不熟，容易把原本简单的权限弄乱，见 ACL 详解 里的恢复办法。

按场景套用的方案见 常见权限方案。

排错时按这个顺序查

「写不进去」或「被拒绝」时，从上到下依次排除，每一步都只改一处：

1. 服务启用并应用了吗？ SMB 设置页的 已启动（Enabled）有没有勾，顶部黄色提示条上的 应用（Apply）有没有点。
2. 第 1 层：共享权限里这个用户和他的组是什么状态？SMB 共享是否勾了「只读」、设了允许主机？
3. 第 2 层：路径上每一级目录，这个用户都有权限吗？
4. 第 3 层：这个目录有没有 ACL 在作怪？
5. 用户所在的组：刚改过组成员的话，要点应用，并让客户端断开重连。

第 2、3 层可以在 OMV 的 shell（SSH 或本机控制台，root 身份）里用只读命令查看：

namei -l <共享文件夹的绝对路径>
getfacl <共享文件夹的绝对路径>
id <用户名>

namei -l 会把路径上每一级目录的权限和属主都列出来，只要有一级目录挡住了，后面的权限再宽也没用。getfacl 显示 ACL，id 显示用户所在的组。绝对路径可以在共享文件夹列表里点复制图标得到。

更具体的症状排查见 SMB 访问被拒绝或反复要密码 和 权限错误：Permission denied。

检查结果

用一个测试共享文件夹验证你对三层的理解：

1. 新建共享文件夹 permtest，权限选默认的 775，添加 SMB 共享，公开选「否」。
2. 建两个测试用户，都在 users 组。用其中一个连上 SMB，能读写。
3. 在共享权限里把另一个用户设为「禁止读写」，应用后他连不上，第一个用户不受影响。
4. 在 shell 里 chmod 750 这个目录，第一个用户在 SMB 上就只剩读，说明第 2 层在起作用。

每一步的结果都和上文对得上，就说明你已经掌握了。验证完删除测试用户和测试共享文件夹；在界面里删除共享文件夹只删记录，测试目录留着也无妨。

常见问题

共享权限里设成了「读/写」，用户还是写不进去。 第 1 层只是放行，文件系统层也要允许。按上面的顺序检查目录权限、属组和 ACL。

把用户设成「禁止读写」，他还是能用 SFTP 或 NFS 访问。 共享权限只管 SMB 和 FTP。要对所有协议都禁止，在文件系统层限制，见 ACL 详解。

为什么不干脆把目录改成 777。 777 让所有人都能读写，包括 SMB 访客 nobody、容器和任何以其他身份访问的进程，等于放弃了第 2 层。需要的话，用专用用户组加 770。

NFS 为什么不受共享权限影响。 NFS 有自己的一套：客户端地址、只读或读/写选项，以及按 UID、GID 检查的文件系统权限，见 NFS 共享。

参考资料

• OMV 官方文档：共享文件夹：权限与 ACL、Samba
• OMV 源码：Samba 共享的 Salt 模板 srv/salt/omv/deploy/samba/files/shares.j2，共享权限的生成规则在这里
• Samba 手册：smb.conf 中的 valid users、read list、write list