权限错误：Permission denied

适用范围

已经连上共享，但读、写、新建、删除、重命名失败：Windows 提示「你需要权限才能执行此操作」，shell 里报 Permission denied，容器日志里有 Permission denied，NFS 客户端报权限错误，rsync 报 Operation not permitted。

不适用：登录阶段就被拒绝，见SMB 访问被拒绝或反复要密码；报 Read-only file system，见文件系统变成只读。

开始排查前

OMV 的权限分三层：共享层（只作用于 SMB 等服务）、ACL、文件系统自身的属主和权限位，有效权限是它们的交集。三层的关系见三层权限：共享权限、ACL 与文件系统权限。这一页教你查出到底是哪一层拦住了你。

不要用 chmod -R 777 或递归改属主来「解决」

影响范围：递归修改会作用于目录下所有文件，数量大时耗时很长，并且会破坏容器和应用依赖的属主。界面 ACL 页面里的递归和取代选项，会把权限应用到全部子文件夹和文件，并覆盖原有的权限条目。

前置条件：先用下面的只读检查查清是谁、访问什么路径、被哪一层拒绝。

回退办法：检查类命令不用回退。要修改之前，先备份当前的 ACL 与属主：

# 在 OMV 的 shell 里执行（只读备份）；<目录> 是要修改的目录
getfacl -R -p <目录> > /root/acl-backup-$(date +%Y%m%d).txt

需要还原时可以用 setfacl --restore，使用前先读它的手册。大目录上的递归修改，请先在一个小的测试目录里演练。

排查步骤

1. 搞清楚「谁，访问什么，做什么」

访问方式	以谁的身份访问文件系统
SMB	登录的那个 OMV 用户
SSH、SFTP	登录的用户
容器	容器里进程的 UID 和 GID（compose 文件里的 PUID、PGID 或 user:）
NFS	客户端的 UID 和 GID，还受 root 映射等设置影响
rsync 任务	任务里设置的用户

记下：用户名、完整路径、动作（读、写、新建、删除、重命名）。

2. 只读地查路径上的每一级

# 在 OMV 的 shell 里执行（只读）；<用户名> 是 OMV 里的用户
id <用户名>
namei -l /srv/dev-disk-by-uuid-<UUID>/<共享文件夹>/<子目录>/<文件>
getfacl -p /srv/dev-disk-by-uuid-<UUID>/<共享文件夹>/<子目录>

• namei -l 逐级列出路径上每一部分的权限、属主和属组。用户要访问某个文件，路径上的每一级目录都要给他执行（x）权限，目标目录再有对应的读或写权限。
• OMV 创建的共享文件夹，默认属主是 root、属组是 users、权限是 2775。末尾的 2 是 setgid，新建的文件会继承 users 组。创建时 OMV 还会为路径中的上级目录，给 users 组加上执行权限。所以普通用户要读写，通常需要在 users 组里。
• 通过 SMB 新建的文件，默认权限是 0664，目录是 0775，组成员可写。
• 如果路径里某一级是你手工创建的目录，权限是 700，或者属主是别人，它就是拦路的那一环。

3. 对照常见原因

现象	原因	处理
所有 OMV 用户都读写失败，目录属主或权限被改过	被容器、手工 chown 或 chmod 改动了	在 存储器 → 共享文件夹（Storage → Shared Folders）里用访问控制列表（Access control list）恢复，见访问控制列表（ACL）详解
只有某个用户失败	用户不在 users 组，或在共享层被设为「只读」「禁止读写」	在 用户 → 用户（Users → Users）里加组并点应用；共享层见SMB 访问被拒绝或反复要密码
容器写入失败	容器进程的 UID、GID 与目录属主不匹配	见容器权限：PUID、PGID 与共享文件夹
NFS 客户端失败	UID、GID 对不上，或 root 被映射成匿名用户	见NFS 共享：给 Linux 和虚拟化平台用
目录在 NTFS、exFAT 或 FAT 上	这类文件系统没有 Linux 的属主和权限位，权限由挂载选项统一决定，界面里的访问控制列表也是灰的（只有支持 POSIX ACL 的文件系统才可用）	见挂载已有数据的硬盘，长期应迁移到 ext4、XFS 或 Btrfs
提示 Disk quota exceeded	不是权限问题，是磁盘配额用完了	见磁盘配额
rsync 报 Operation not permitted (1)，涉及 aquota.user、aquota.group	这是磁盘根目录下的配额文件，不是你的权限设置有问题	omv-extras 的文档建议同步时排除这两个文件：--exclude='aquota.user' --exclude='aquota.group'

4. 在界面里修改，先不递归

1. 用户没在 users 组：用户 → 用户（Users → Users）里编辑用户，加入 users 组，点应用，再让客户端重新连接。
2. 目录属主或权限被改乱：存储器 → 共享文件夹 里选中它，点访问控制列表。取代（Replace all existing permissions）和递归（Apply permissions to files and subfolders）两个选项都会作用到所有文件，先不要勾选；确认只需要改这一层目录时，再考虑是否递归。
3. 只改动要处理的那一个目录，改完用第 2 步的命令验证。

最后手段：重置权限插件

omv-extras 的 openmediavault-resetperms 插件，入口是 服务 → 重置权限（Services → Reset Permissions），能按预设把共享文件夹的权限整体重置，并可清除 ACL。它的所有修改都是递归的，会作用于所选文件夹下的全部子文件夹和文件。它的文档还明确警告：不要对系统盘所在的目录、Docker 的安装目录和容器的持久化数据目录使用。使用前必须先备份，并确认被重置的目录没有别的用途。详见小工具合集。

确认恢复

1. 用出问题的那个用户，重复触发问题的原始操作（读、写、新建、删除），都成功。
2. 再用另一个不该有权限的用户试一次，应该仍被拒绝，说明没有把权限放得过宽。
3. 重新运行第 2 步的 namei -l，路径上每一级的属主和权限都符合预期。
4. 容器场景：重启容器，确认应用能正常写入自己的数据目录。

仍未解决

附上：id <用户名> 的输出、namei -l 和 getfacl -p 的输出（遮盖用户名和路径中的敏感部分）、访问方式（SMB、容器、NFS）、文件系统类型，以及报错原文。读如何有效求助。

参考资料

• OMV 官方文档：FAQ（共享文件夹默认的属主与权限）
• omv-extras wiki：Utilities, Maintenance and Backup（aquota.user 导致 rsync 报错的说明）、Reset Permissions 插件
• 本站：设置共享文件夹权限、常见权限方案