核心是确认服务是否依赖/tmp创建临时文件、socket或pidfile，并验证其实际访问行为是否被阻断；需结合ls -ld /tmp、mount、stat、getfacl等命令综合判断权限与挂载状态，再通过journalctl和sudo -u模拟精准定位问题，最后按chmod 1777 /tmp、修复tmpfs挂载、清理残留顺序修复。
排查 /tmp 权限异常导致服务启动失败，核心是确认服务是否依赖 /tmp 创建临时文件、socket 或 pidfile，并验证其实际访问行为是否被阻断。不能只看 ls -ld /tmp，而要结合服务运行上下文判断真实权限需求。
/tmp 权限如何影响服务启动
/tmp 是多数服务默认使用的临时目录，常见依赖场景包括：
- 服务启动时创建 socket 文件（如 systemd-socket-activated 服务）
- 写入 pidfile（尤其非 systemd 原生管理的旧式脚本）
- 解压运行时资源、生成缓存、执行临时脚本（如某些 Java 应用或 Python 工具链）
- systemd 自身在 early-boot 阶段使用 /tmp 作为 tmpfs 挂载点，若挂载失败或权限不兼容，可能连锁影响依赖
tmp.mount的服务
快速确认 /tmp 当前权限状态
执行以下命令获取关键信息：
-
ls -ld /tmp：正常应为drwxrwxrwt（最后一位t表示粘滞位） -
mount | grep ' /tmp '：确认是否被挂载为 tmpfs；若显示 ext4/xfs 等磁盘文件系统，且无粘滞位，则风险极高 -
stat -c "%a %A %U:%G" /tmp：检查八进制权限码（应为1777）及属主属组（通常为root:root） -
getfacl /tmp 2>/dev/null | grep -E "^(user|group|other):|effective"：排除 ACL 干扰
定位具体哪个服务因 /tmp 受阻
不要泛泛查日志，聚焦三类线索：
- 查失败服务的单元定义：
systemctl show --property=ExecStart,Environment,RuntimeDirectory nginx.service，看是否含/tmp路径或RuntimeDirectory=tmp类配置 - 查 journal 中明确提及 /tmp 的错误：
journalctl -b -p err | grep -i "/tmp\|permission.*denied\|no space.*left\|read-only" - 模拟服务用户行为：
sudo -u <service-user> touch /tmp/test.$$ && rm /tmp/test.$$</service-user>（例如sudo -u www-data touch /tmp/test.123），直接验证写权限
修复与验证步骤
确认问题后，按优先级顺序操作：
- 恢复标准权限：
sudo chmod 1777 /tmp && sudo chown root:root /tmp - 若 /tmp 是 tmpfs 挂载，检查
/etc/fstab是否误删或注释了对应行；必要时手动重挂：sudo mount -t tmpfs -o mode=1777,nosuid,nodev tmpfs /tmp - 重启受影响服务前，先清理残留：
sudo find /tmp -user <service-user> -type f -delete 2>/dev/null</service-user>（避免旧文件权限继承干扰） - 启动后验证：
systemctl status 服务名+journalctl -u 服务名 -n 20 --no-pager，确认无Permission denied或Failed to create类报错
