根本原因是linux文件系统权限优先于samba配置，用户必须对共享路径同时具备os级读写权限；create mask和directory mask仅控制新建文件目录的权限位，不影响已有文件。
为什么 smb.conf 里设了 read only = no 还是写不了
根本原因不是配置没生效，而是 Linux 文件系统权限压过了 Samba 权限。Samba 不会绕过 stat() 检查，用户必须对共享路径的目录和文件同时具备底层 OS 的读写权限。
- 检查共享路径的属主和权限：
ls -ld /path/to/share，确保 Samba 用户（如alice）属于该目录的属组，且组有w权限；或直接属主就是该用户 - 若用
valid users = alice，但alice在 Linux 中不存在，Samba 会退化为nobody，此时得让nobody有对应目录权限 - 避免用
force user = root临时“修复”——这会让所有操作都以 root 身份执行，极不安全，且可能触发 SELinux 拒绝
create mask 和 directory mask 到底控制谁的权限
它们只影响 Samba 新建的文件和目录的权限位（即 umask 的反向逻辑），不影响已有文件，也不覆盖 Linux ACL 或默认 umask。
-
create mask = 0664→ 新建文件权限为-rw-rw-r--（注意：Samba 会自动去掉执行位，除非显式加force create mode = 0775） -
directory mask = 0775→ 新建目录为drwxrwxr-x；但若客户端是 Windows，它不传执行位，所以实际依赖force directory mode - 常见坑：
create mask = 0644看似合理，但如果客户端用 macOS 写入，可能因扩展属性触发额外权限位，导致最终权限变成0646，建议统一用0664+force create mode = 0664
Windows 映射网络驱动器后提示“拒绝访问”，但 smbclient -L 能连上
大概率是认证方式或加密策略不匹配，尤其在较新版本 Windows（10 1809+ / 11）和较老 Samba（
- Windows 默认禁用 NTLMv1，而旧版 Samba 可能仍尝试协商它；确认 Samba 启用了 NTLMv2：
server min protocol = SMB2或至少ntlm auth = no - 检查是否启用了签名强制：
server signing = mandatory会导致 Windows 客户端因不支持而断连；生产环境建议设为auto - SELinux 开启时，
samba_share_t上下文缺失也会表现为“拒绝访问”，运行ls -Z /path/to/share，若非samba_share_t，补上：chcon -t samba_share_t /path/to/share
多人协作共享目录，如何让 A 创建的文件 B 也能编辑
靠 Samba 单独配置做不到，必须结合 Linux 的 setgid 目录 + 统一 GID + 合理 mask。
- 给共享目录设 setgid：
chmod g+s /path/to/share，这样新文件自动继承父目录属组 - 把所有协作用户加入同一组（如
teamshare），并确保他们登录 shell 的 primary group 是这个组（usermod -g teamshare alice） - 配置
force group = teamshare和create mask = 0664、directory mask = 0775，再加force directory mode = 0775确保目录可写 - 注意：
inherit permissions = yes对新建文件无效，它只影响子目录从父目录继承 ACL，别指望它解决协作写入问题
真正卡住人的从来不是 smb.conf 里哪行写错了，而是 Linux 权限、SELinux 上下文、Windows 加密策略这三层叠在一起时，错误提示全指向“拒绝访问”，却没人告诉你该看哪一层的日志 —— /var/log/samba/log.smbd 里搜 NT_STATUS_ACCESS_DENIED，再比对 getsebool samba_export_all_rw 和 testparm -v | grep protocol，才可能定位到那一行被忽略的 force user。
