SFS 挂载后写入卡顿、权限被拒：按挂载、权限与配额三层定位的 6 步

周四上午，业务方反馈新上线的两个应用写日志、传文件都变慢了：有的请求要等好几秒才返回，有的直接报 Permission denied，还有一台机子干脆提示 No space left on device，但 SFS 控制台看容量明明还剩很多。文件服务本身没有宕机，也没有重启，上一周还好好的，最后查下来，问题出在三层叠加：挂载参数用错了协议版本、共享目录的属主与应用用户不一致、再加上一台机子触发了单文件系统配额。本文把当时用的 6 步定位法写下来，照着走基本能把 SFS 写入卡顿缩小到一个具体原因。

一、问题现象：先确认是写入卡顿，还是挂不上

写入卡顿和挂载失败，在业务侧看起来差不多，都是写不进去，但原因完全不同。挂载失败是目录根本不可用，写入卡顿是挂上了、但写得慢或偶尔被拒。先分清这一步，后面才不会白改权限。

最直接的办法是在出问题的 ECS 上同时看挂载状态和写入耗时：

mount | grep sfs
df -h /mnt/sfs
ls -ld /mnt/sfs
time dd if=/dev/zero of=/mnt/sfs/testfile bs=1M count=100 oflag=direct

如果 mount 里能看到挂载记录，但 dd 写 100MB 要几十秒甚至超时，说明问题在写入路径；如果 mount 里根本没有这条记录，或 df 直接报错，说明问题在挂载这一步，先不要去改文件权限。当时我们这一步的结果是三台机子表现不一样：一台写得慢、一台 Permission denied、一台 No space left on device，基本可以排除 SFS 服务整体挂掉，只看各自的挂载、权限与配额。

二、开始之前：先准备好这三样东西

动手改配置之前，先准备三样东西，避免边查边找权限。首先是 SFS 控制台的查看权限，至少能看到文件系统状态、容量、挂载地址和所属 VPC；其次是出问题的 ECS 的登录权限和 sudo 权限，能执行 mount、df、id、ls、dmesg；最后是出问题的时间点，包括业务第一次报慢的时间、最近一次改过挂载、改过权限或扩过容的时间。

另外注意一个原则：在确认原因之前，不要直接把文件系统扩容来“先恢复业务”。扩容确实能缓解容量类问题，但如果根因是挂载参数或权限，扩完还是写不进去，还会把账单抬高。正确的顺序是先定位，再针对性改挂载、改权限或清配额。

三、分步操作：6 步定位 SFS 写入卡顿

第 1 步：看挂载参数，先确认协议和地址对不对

先去 SFS 控制台复制挂载地址，再在 ECS 上比对当前实际挂载参数。SFS 通用文件系统走 NFS 协议，常用的是 NFSv3，端口是 2049，挂载时要显式指定版本和协议，不要只写一个裸 mount：

cat /proc/mounts | grep sfs
nfsstat -m
showmount -e <SFS挂载地址>

重点看三处：一是 vers 是不是 3，二是 proto 是不是 tcp，三是挂载地址是不是控制台给的那个、且和 ECS 在同一个 VPC、同一个可用区的网络可达范围内。当时有一台机子写的是 vers=4，另一台机子把挂载地址抄错了一个字符，这两台一个慢、一个挂不上，都是这一步就能发现的。

第 2 步：看网络与安全组，确认 2049 端口通不通

挂载参数对了还写不进去，再看网络。NFS 不走 80 或 443，走的是 2049，先确认 ECS 到 SFS 的这条路通不通：

ping -c 4 <SFS挂载地址>
nc -vz <SFS挂载地址> 2049
telnet <SFS挂载地址> 2049

再去控制台核对两处：一是 ECS 所在安全组有没有放行到 SFS 的出方向，二是 SFS 这侧有没有被别的策略挡住。如果 nc 直接报连接超时，先看安全组和 VPC 路由，不要先去重装客户端。当时我们有一台跨可用区的 ECS，就是安全组只放行了同可用区网段，跨区就被挡住了。

第 3 步：看权限与属主，确认应用用户到底是谁

挂载通了但报 Permission denied，问题大概率在权限。NFS 看的是数字 UID 和 GID，不是用户名，先同时看目录属主和应用进程的用户：

id appuser
ls -ld /mnt/sfs /mnt/sfs/app
namei -l /mnt/sfs/app/data.log

重点看两类：一是目录属主是 root、而应用跑在 appuser 下，二是目录权限是 755、应用用户既不是属主也不在属组里。当时报 Permission denied 的那台机子，目录是 root:root 755，应用用户 appuser 在别的组，写自然被拒。改法是把目录属主改成应用用户，或把应用用户加进属组，再用 chmod 750 收紧，不要直接 chmod 777。

sudo chown -R appuser:appuser /mnt/sfs/app
sudo chmod 750 /mnt/sfs/app
su - appuser -c 'touch /mnt/sfs/app/write-test && rm /mnt/sfs/app/write-test'

第 4 步：看容量与配额，确认 No space 是哪一层满了

No space left on device 不一定是文件系统真的满了，要分三层看：文件系统总容量、单个目录配额、inode 数量。

df -h /mnt/sfs
df -i /mnt/sfs
du -sh /mnt/sfs/* | sort -rh | head -20

如果 df -h 显示还有空间，但 df -i 显示 inode 用满了，说明是小文件太多，占满了 inode，要清理碎文件而不是扩容；如果 du 发现某个目录突然多出几百 GB 的日志或备份，要先看是不是日志轮转没开、备份没删。当时报 No space 的那台机子，总容量只用了六成，但一个日志目录一天写了几十万个小文件，inode 先满了。

第 5 步：看 dmesg 与耗时，确认是不是单点慢拖住了整体

权限和配额都没问题、但还是慢，再看系统日志和单次写耗时。NFS 出问题时，内核日志里常有超时重传的记录：

dmesg | grep -i nfs | tail -30
cat /proc/mounts | grep sfs
time dd if=/dev/zero of=/mnt/sfs/testfile bs=1M count=100 oflag=direct; rm -f /mnt/sfs/testfile

重点看 dmesg 里有没有 nfs: server not responding、timed out 这类记录，再看 dd 的耗时是不是稳定在秒级。如果只有一台机子慢、别的机子正常，偏向这台机子的网络或挂载参数；如果所有机子同时慢，再去看 SFS 控制台的读写时延和 IOPS，是不是业务高峰把带宽打满了。

第 6 步：看是谁最后改了挂载、权限或配额

如果以上五步都没找到原因，就去看变更记录，确认写入开始变慢的时间点前后，谁改过挂载参数、谁改过目录权限、谁调过配额或清理过文件。很多时候 SFS 写入变慢不是配置从一开始就错，而是某次变更之后，某个目录的属主、某个安全组规则或某个日志策略被顺手改了。把第 1 步的挂载参数、第 3 步的属主、第 4 步的配额拼在一起，通常就能圈定一个改动。当时我们最后锁定的是：一次批量部署脚本把 /mnt/sfs/app 的属主重置成了 root，而旧脚本用的是 appuser，重启后新进程就写不进去了。

四、验证：改完要做这三件事

改完挂载、权限或配额后，不要只看一次写入成功就以为修好了。这三件验证都通过了，再算修好：第一，用 appuser 身份 touch 一个测试文件再删掉，确认权限真的通了；第二，用 dd 写 100MB 再 rm，连续测三次，确认耗时稳定在合理区间，不再忽快忽慢；第三，让业务跑一个完整高峰时段，确认不再出现 Permission denied 和 No space left on device。我们当时还补了一件事：把本次改动的挂载命令、属主和配额存了一份记录，标清楚哪个目录归哪个用户、哪个机子用哪个挂载地址，后续再出问题，可以直接对照这张清单，而不用重新猜。

五、常见坑：五句话

一是“写不进去就先扩容”，不对，不先分清挂载、权限还是配额，扩完还是写不进去。二是“目录权限直接给 777”，不对，这会把所有用户都放进来，先用 chown 对齐应用用户，再用 750 收紧。三是“挂载地址凭记忆手敲”，不对，一定要从 SFS 控制台复制，抄错一个字符就会挂不上或跨区变慢。四是“只看 df -h、不看 df -i”，不对，小文件太多会先占满 inode，总容量有空也不顶用。五是“用 dd 不加 oflag=direct 就测性能”，不对，不加这个参数测到的是缓存速度，不是真实写入速度。

六、小结清单

• 复现：用 mount、df -h、ls -ld 和 dd 先确认是挂不上，还是挂上了写得慢，记录业务第一次报慢的时间。
• 定位顺序：挂载参数、网络与安全组、权限与属主、容量与配额、dmesg 与耗时、变更记录。
• 改挂载：用控制台复制的地址挂载，显式指定 vers=3、proto=tcp，确认 2049 端口通、VPC 与安全组放行。
• 改权限：用 chown 把目录属主对齐应用用户，用 750 收紧，不要用 777。
• 清配额：分清总容量、目录配额和 inode，小文件太多先清理碎文件和日志轮转。
• 验证：appuser 写删测试、dd 三次耗时、业务高峰复测三项全部通过；改动内容留档；下次只按这张清单先走一遍。