Golang实现对只读文件系统挂载点的访问检查-Golang-PHP中文网

最可靠方式是尝试写临时文件并检查错误：errors.is(err, syscall.erofs)或错误信息含"read-only file system"；linux下可辅以syscall.statfs查st_rdonly标志，跨平台应优先试写 fallback解析错误。

golang实现对只读文件系统挂载点的访问检查

如何用 Go 判断挂载点是否只读

Go 标准库没有直接提供“判断挂载点是否只读”的函数，os.Stat 和 os.IsPermission 对只读文件系统无效——即使整个挂载点是 ro，只要用户对某个目录有执行权限，os.Stat 仍能成功返回。真正可靠的方式是尝试写一个临时文件并捕获错误。

关键不是“能不能读”，而是“能不能写”。只读挂载下，任何写操作（包括 open(O_CREAT|O_WRONLY)、os.Create、os.Mkdir）都会返回特定错误。

os.ErrPermission 在部分系统（如 ext4 + ro mount）下可能不出现，实际常见的是 <nil></nil> 错误返回但后续 Write 失败，或更典型的是 read-only file system 字符串出现在 error.Error() 中
不要依赖 syscall.EPERM 或 syscall.EACCES：它们表示权限不足，而非文件系统只读；只读挂载通常触发的是 syscall.EROFS（Error Read-Only File System）
最稳妥的做法：在目标路径下调用 os.OpenFile(path, os.O_CREATE|os.O_WRONLY, 0200)，检查错误是否为 syscall.EROFS 或其字符串是否含 "read-only file system"

用 syscall.Statfs 检查挂载标志（Linux 专用）

Linux 下可通过 syscall.Statfs 获取挂载选项，直接读取 Statfs_t.Flags 中的 ST_RDONLY 位。这比试写更快、更干净，且不产生副作用，但仅限 Linux，且需确保目标是挂载点根目录（非子路径）。

注意：syscall.Statfs 接收路径，但返回的是该路径所在文件系统的统计信息——如果传入的是挂载点内嵌套的子目录，依然能正确反映该文件系统是否只读；但如果路径跨了 bind mount 或 overlayfs，行为可能不符合预期。

Golang Naming

Go（Golang）命名规范 — 包括包、构造函数、结构体、接口、常量、枚举、错误、布尔值、接收器、getter/setter、函数等。

下载

必须 import "syscall"（非 golang.org/x/sys/unix，后者在部分老版本 Go 中未导出 Statfs）
调用后检查 statfsBuf.Flags & syscall.ST_RDONLY 是否非零
若 syscall.Statfs 返回 error（如路径不存在），应 fallback 到试写法

示例片段：

var sfs syscall.Statfs_t
if err := syscall.Statfs(path, &sfs); err != nil {
    return false, err
}
return sfs.Flags&syscall.ST_RDONLY != 0, nil

跨平台兼容写法：封装可读/可写探测函数

生产环境往往要兼顾 Linux/macOS/Windows。Windows 没有“挂载点只读”概念（只有 ACL 或 FAT 只读属性），macOS 的 statfs 有 MNT_RDONLY 但字段名和位定义与 Linux 不同。因此统一策略是：优先试写，失败后解析错误文本；Linux 额外加 Statfs 快速路径。

避免在 /proc/mounts 或 mount 命令输出中做字符串匹配——依赖 shell、解析脆弱、权限受限
试写路径应选目标挂载点下的可访问子路径（如 path + "/.rocheck-xxx"），写完立即 os.Remove；若 Remove 也失败（比如只读又不可删），至少说明写已被拒，可判定为只读

错误判断逻辑建议：

errStr := err.Error()
isRO := strings.Contains(errStr, "read-only file system") ||
        strings.Contains(errStr, "EROFS") ||
        errors.Is(err, syscall.EROFS)

不要忽略 ENOSPC 或 EDQUOT：它们可能和只读混淆，需单独排除（例如先 os.Stat 确认路径存在且是 dir）

常见误判场景和绕过风险

只读检查常被用于“自动降级”或“拒绝启动”，但实际部署中容易踩坑。

容器环境里，/proc、/sys 是只读挂载，但应用不该去那里写；检查前应明确目标路径是否属于业务数据挂载点（如 /data），而非任意 os.Getwd()
bind mount 或 overlayfs 可能导致 Statfs 返回底层 fs 标志，而非上层表现——比如 overlay lowerdir 是 ro，但 upperdir 是 rw，整体仍是可写的
某些 NFS 挂载在服务器端设为 ro，但客户端 mount 时没加 ro，此时 Statfs 可能不报 ST_RDONLY，但实际写会卡住或超时；这时必须依赖试写 + 设置 timeout（通过 context.WithTimeout 包裹 I/O）
root 用户在只读挂载下仍可能创建设备节点或修改扩展属性，所以单纯检查 os.Create 不够，建议用 os.WriteFile(path, []byte("x"), 0600) 更贴近真实写行为