Go MkdirAll 为什么在受限目录下创建失败

我第一次遇到 os.MkdirAll “创建失败”时，直觉是把 0755 改成 0777。后来发现这通常不是目标目录权限位的问题：如果进程连父目录都没有搜索权限，或者父路径所在挂载点只读，MkdirAll 再努力也无法越过这个边界。

先看清 MkdirAll 能做什么

官方文档对 MkdirAll(path, perm) 的定义很直接：它会创建目标目录及必要的父目录；如果目标路径已经是目录，则返回 nil。这里的 perm 是“新建目录”的初始权限，并不是一次性授予进程访问整条路径的权限。

因此，下面这段代码有两个容易混淆的边界：app-data 之前的目录必须允许当前进程逐级穿过，真正新建的目录才会参考 0750；若中间某一段已经存在但其实是普通文件，调用也会在那一段停止。

package main

import (
	"errors"
	"fmt"
	"io/fs"
	"os"
)

func prepareDataDir(path string) error {
	// 0750 只约束本次新建的目录，最终权限还会受 umask 影响。
	if err := os.MkdirAll(path, 0o750); err != nil {
		// 用 errors.Is 识别权限类错误，避免只匹配脆弱的错误字符串。
		if errors.Is(err, fs.ErrPermission) {
			return fmt.Errorf("创建数据目录权限不足: %w", err)
		}
		return fmt.Errorf("创建数据目录失败: %w", err)
	}
	return nil
}

为什么改大 perm 仍然失败

排查时我会先把失败拆成三类。第一类是父目录不可搜索：在 Unix 权限里，目录的执行位代表“进入/搜索”能力，没有它，即使目标目录想创建得更宽松也无从谈起。第二类是父目录不可写：创建下一层目录需要对直接父目录有写权限。第三类是路径环境本身受限，例如挂载点只读、容器内的运行用户与宿主机预期不同。

这也是为什么把 0750 改成 0777 常常没有效果。它最多改变新目录的权限请求，不能改变当前进程的 UID/GID，也不能绕过父目录的 ACL、只读挂载或安全策略。并且 Unix 下实际结果还要经过 umask；文档里的权限值是创建前的请求值。

用 PathError 找到真正卡住的那一级

MkdirAll 返回的通常是 *os.PathError。不要只把整段错误打印出来就结束，应该保留原始错误并读取它的操作名和路径。下面的辅助函数不改变错误，只把排查信息结构化。

package main

import (
	"errors"
	"fmt"
	"io/fs"
	"os"
)

func explainMkdirError(err error) string {
	// 先保留 errors.Is 链，包装后的 PathError 仍能被识别。
	if errors.Is(err, fs.ErrPermission) {
		var pathErr *os.PathError
		if errors.As(err, &pathErr) {
			// Op 和 Path 能指出是哪个文件系统操作、哪条路径失败。
			return fmt.Sprintf("权限错误: op=%s path=%s cause=%v", pathErr.Op, pathErr.Path, pathErr.Err)
		}
		return "权限错误，但未拿到 PathError 细节"
	}
	return fmt.Sprintf("非权限类错误: %v", err)
}

如果路径落在某个中间目录，说明问题很可能发生在那一级，而不是最末端目录。若返回的是“not a directory”一类错误，则沿路径检查是否存在同名普通文件；若返回权限错误，则继续核对进程的实际身份，而不是只看当前登录用户。

我的修复顺序：先换可写根目录，再处理部署权限

在服务里，我更愿意让应用写入明确的应用数据目录、临时目录或由部署脚本提前创建的目录，而不是让进程临时去碰系统目录。这样既能缩小写权限范围，也能让容器、systemd 或 CI 环境使用同一套路径契约。

如果路径确实应该由服务创建，修复顺序通常是：确认服务实际运行用户；确认每一级父目录的搜索和写入权限；确认挂载点不是只读；再选择合适的组权限或部署阶段预创建。chmod、ACL 或改服务用户都属于运维变更，应和目录的归属、审计要求一起评估。

代码侧只需要把错误带回调用方，并记录不包含敏感信息的路径上下文。不要在失败后自动提权，也不要为了“成功”把权限无限放大。

常见问题

目标目录已经存在，MkdirAll 为什么还可能失败？

只有当路径已经是目录时才会直接成功；如果同名路径是普通文件，或者进程无法搜索到它所在的父目录，仍然会返回错误。

把权限参数写成 0777 就一定能创建吗？

不能。它不改变父目录权限、进程身份、ACL 或只读挂载，而且最终权限还会受到 umask 影响。

应该用字符串判断 permission denied 吗？

不建议。优先使用 errors.Is(err, fs.ErrPermission)，需要展示位置时再用 errors.As 取出 *os.PathError。

回头看，这个问题的关键不是“给 MkdirAll 传多大的数字”，而是确认程序是否拥有创建路径所需的完整权限链。把运行身份、父目录、挂载状态和 umask 记录清楚，通常比重复尝试更快找到原因。