Sublime Text在Samba共享目录保存卡死，主因是CIFS挂载参数与Linux文件锁冲突：需添加cache=strict、noperm、uid/gid参数，并确保Sublime以匹配UID用户启动，避免renameat2()系统调用阻塞。
Sublime Text 在 Samba 共享目录里保存文件卡死，根本不是编辑器的问题，而是 CIFS 挂载参数和 Linux 文件锁机制在打架。
为什么保存时卡住或报“Permission denied”
Sublime Text 保存文件默认先写临时文件（如 .sublXXXX.tmp），再原子性地 rename() 替换原文件。但 CIFS 协议对 rename() 的支持依赖服务端 SMB 版本和挂载参数——如果服务端不支持 POSIX rename（比如 Windows 默认 SMBv1/v2 且未启用“SMB1 Legacy”），或者挂载时没开 cache=strict 或 noperm，Linux 内核就会阻塞等待服务端响应，导致 Sublime Text 界面无响应。
- 常见现象：光标停在“正在保存…”、磁盘灯狂闪、
strace -p $(pidof sublime_text)显示卡在renameat2()系统调用 - Windows 共享默认禁用 SMB1，Ubuntu 22.04+ 默认挂载使用 SMBv3，但 rename 行为仍不稳定
- 银河麒麟/统信 UOS 等系统若启用了 SELinux 或 AppArmor，还会额外拦截 CIFS 文件锁操作
挂载时必须加的三个关键参数
不用改 Samba 服务配置，只改客户端挂载命令就能解决 90% 的卡死问题。核心是绕过服务端 rename 限制 + 关闭内核级权限校验：
-
cache=strict：强制内核缓存元数据，避免每次 rename 都发网络请求 -
noperm：跳过挂载点本地权限检查（否则chmod失败会导致 Sublime Text 认为写入失败） -
uid=1000,gid=1000：显式指定挂载后文件属主，避免 Sublime Text 以 root 权限启动时写入失败
完整挂载示例：sudo mount -t cifs //192.168.1.100/share /mnt/share -o credentials=/etc/samba/cred,iocharset=utf8,cache=strict,noperm,uid=1000,gid=1000,vers=3.0
/etc/fstab 中的写法与陷阱
fstab 不会自动继承 shell 环境变量，credentials= 路径必须绝对且可被 root 读取；同时注意 vers= 必须和服务端实际支持的版本一致：
- Windows Server 2016+ / Win10 1809+：用
vers=3.0或vers=3.1.1 - 旧版 Windows 7 / Samba 4.7 以下：只能用
vers=2.0或vers=1.0（不推荐） - 务必避开
soft参数——它会让 rename 失败直接报错，而不是卡住，但 Sublime Text 依然无法保存 - 不要加
noac：它禁用属性缓存，反而加剧 rename 延迟
fstab 示例行：//192.168.1.100/share /mnt/share cifs credentials=/etc/samba/cred,iocharset=utf8,cache=strict,noperm,uid=1000,gid=1000,vers=3.0 0 0
Sublime Text 启动方式要匹配挂载用户
如果挂载用了 uid=1000，但你是用 sudo sublime_text 启动的，进程实际以 root 运行，对挂载点只有读权限——这时保存必然失败，且不会弹窗提示，只会卡住。
- 确认当前用户 UID：
id -u，确保和挂载参数中uid=一致 - 图形界面下不要用 sudo 启动 Sublime Text；终端中用
subl而非sudo subl - 若必须用 root 编辑（如编辑系统配置），先
cp到本地临时目录修改，再cp回共享目录——别直接打开共享路径下的文件
真正麻烦的从来不是“怎么挂”，而是挂完之后谁在用、怎么用、用什么协议版本——这三个变量一错，Sublime Text 就会在 rename 上吊死，连 Ctrl+C 都杀不掉。
