mount.cifs multiuser 和 cache 选项怎么配合使用

把 SMB 共享挂载到 Linux 后，multiuser 和 cache 解决的是两件不同的事：前者决定“访问者用哪套凭据连接服务器”，后者决定“客户端怎样缓存文件数据”。多用户共享场景通常先明确服务器 ACL，再考虑缓存一致性；不要因为加了 multiuser 就以为客户端会自动获得更强的本地权限控制。

先把 multiuser 和 cache 分到两条线上

默认情况下，一个 CIFS 挂载主要使用执行挂载时提供的那套凭据访问共享。启用 multiuser 后，客户端会在新的本地用户访问时尝试使用该用户的凭据创建服务器会话，后续访问继续使用这套身份。内核不能替用户交互式询问密码，所以实际使用还依赖不需要现场输入密码的认证方式和现成凭据。

cache 不改变服务器会话身份，它只影响文件数据是否进入客户端 page cache，以及客户端在什么条件下相信缓存内容。可以把一次访问拆成“谁在访问”和“客户端能否暂时相信本地数据”两步来理解。

三种 cache 模式分别改变什么

当前内核的默认缓存模式是 strict。手册还特别提醒，多个客户端读写同一文件时，cache=loose 可能造成数据一致性问题；它不是“更快但完全等价”的开关。

按访问模型选择挂载组合

如果同一台 Linux 主机上的多个用户访问同一共享，且服务器需要依据各自账号执行 ACL 判断，可以把 multiuser 作为身份层选项，再从 cache=strict 起步。注意：multiuser 会隐含 noperm，本地客户端不再替你做通常的权限检查，最终授权仍由服务器端账号和 ACL 决定。

# 用占位路径说明组合关系；真实凭据请放在受保护的凭据机制中
sudo mount -t cifs //fileserver/team /mnt/team \
  -o multiuser,sec=ntlmssp,vers=3.1.1,cache=strict

# 查看当前内核记录的挂载参数，确认组合是否被实际采用
grep ' /mnt/team ' /proc/mounts

如果应用对缓存一致性极其敏感，或需要观察服务器上的最新文件内容，可以选择 cache=none，但要把额外网络往返和吞吐代价纳入评估。若共享主要是单客户端、读多写少的工作集，strict 通常比 loose 更容易解释和排障。

遇到权限或旧数据现象时怎么判断

第一步看访问者是否真的拿到了自己的服务器会话，而不是只检查本地文件的 uid/gid。第二步确认挂载参数中的 multiuser、cache 和 sec 是否符合预期。第三步再查看服务器 ACL；本地看到的权限表现不能单独证明服务器已经允许或拒绝了某次操作。

如果怀疑是缓存陈旧，先把并发读写关系和文件锁语义说清楚，再在受控窗口比较 cache=strict 与 cache=none。不要直接把 cache=loose 当成修复方案，更不要把 noperm 理解成“放开服务器权限”。

常见问题

multiuser 能不能和 cache=none 一起用？

可以。两者分别属于身份层和数据缓存层，组合后仍由 multiuser 负责按访问者使用凭据，cache=none 负责不缓存普通文件数据。

cache=strict 是不是完全不会读到旧数据？

不是。它是更严格地遵循协议缓存规则，是否能信任缓存还与 oplock、lease、服务器行为和具体访问方式有关。

加了 multiuser 后还要看服务器 ACL 吗？

要看。multiuser 让服务器看到更准确的访问身份，但授权结果仍由服务器账号、共享权限和文件 ACL 等因素共同决定。

实际配置时，可以先固定身份模型，再选择缓存模型：多用户按账号授权，优先考虑 multiuser,cache=strict；一致性优先且能接受额外往返时考虑 cache=none；只有明确知道并发写入风险可控时才使用 cache=loose。