根本原因是Linux文件系统权限优先于Samba配置，用户必须对共享路径同时具备OS级读写权限；Samba不绕过stat()检查，即使read only = no，若Samba用户对目录无属组写权限或属主权限，仍会“拒绝访问”。
Linux 中 Samba 权限控制失效，90% 不是 smb.conf 写错了，而是底层文件系统权限没对齐——Samba 从不绕过 stat() 检查，用户必须对目录和文件同时具备 OS 级读写权限。
为什么 read only = no 还是写不了
根本卡点在 Linux 文件权限层。即使 Samba 配置全开，只要 Samba 用户（比如 alice）对共享路径没有对应组写权限或属主权限，Windows 映射后就会“拒绝访问”。
- 用
ls -ld /path/to/share检查目录权限和属组，确保该用户属于目录的属组，且组有w位（如drwxrws---） - 若用户不在属组中，
usermod -aG teamgroup alice后必须让alice重新登录（SSH 重连或图形界面登出再进），否则id -Gn不会更新 - 避免用
force user = root临时“修复”，它会让所有操作以 root 身份执行，触发 SELinux 拒绝或留下安全隐患
create mask 和 directory mask 到底管什么
这两个参数只影响 Samba 新建的文件/目录的权限位，对已有文件完全无效，也不覆盖 Linux ACL 或默认 umask。
-
create mask = 0664→ 新建文件权限为-rw-rw-r--（Samba 自动屏蔽执行位） -
directory mask = 0775→ 新建目录为drwxrwxr-x；但 Windows 客户端不传执行位，实际依赖force directory mode = 0775 - 若要确保新建文件可被组内编辑，推荐组合：
create mask = 0664+force create mode = 0664，避免 macOS 或某些客户端扩展属性导致权限意外变成0646
多人协作时 A 创建的文件 B 编辑不了怎么办
靠 Samba 单独配置做不到。必须让新文件自动继承统一属组，否则每个用户创建的文件都按自己主组归属，B 就永远碰不到 A 的文件。
- 给共享目录设 setgid：
chmod 2770 /data/teamshare（开头的2是关键） - 把所有协作用户加入同一组（如
teamshare），并设为他们的 primary group：usermod -g teamshare alice（不是-aG） - Samba 配置里加
force group = teamshare和directory mask = 2770，补双重保险 - 注意：
chmod -R 2770对已有子目录生效，但对已存在普通文件无影响（setgid 只作用于目录）
ACL 是 setgid 失效时的兜底方案
当目录跨文件系统挂载、容器环境禁用 setgid，或需给单个非组用户临时授权时，ACL 比改用户组更轻量。
- 给用户
kitty单独加写权限：setfacl -m u:kitty:rwx /data/teamshare - 确认生效：
getfacl /data/teamshare应显示user:kitty:rwx行 - 注意：NFS/Samba 默认不透传 ACL，需在
smb.conf中启用vfs objects = acl_xattr，且底层文件系统（如 ext4、xfs）必须支持 xattr
最常被忽略的是：setgid 生效后，用户必须重登才能获得新组上下文；而 ACL 配好后，若 smb.conf 没配 vfs objects，Windows 客户端根本看不到效果——这两步缺一不可。
