普通用户跑 GPU 程序报"平台创建失败"，加进组才通

你在服务器上装好了显卡驱动和运行库，用 root 跑一段 GPU 程序，一切正常，加速卡认得好好的。可换成普通账号一跑，程序立刻报错：平台创建失败，连查询设备状态的工具也初始化失败。你反复确认库都装对了、路径也没错，却怎么都跑不起来。

现象

• 用 root 运行 GPU 程序：正常；
• 用普通用户运行：报错，典型如：

CUDA error: initialization error
no CUDA-capable device is detected

• 连设备查询工具也失败，报类似"平台创建失败 / 初始化失败"的错误。

规律：换个身份就坏，root 永远是好的。 这几乎总是指向"权限"。

根因

根因是：访问 GPU 设备节点需要特定权限，而普通用户不在拥有该权限的组里。

在 Linux 里，显卡不是抽象资源，它对应着 /dev 下的设备节点。可以用 ls -l 看：

ls -l /dev/nvidia* /dev/dri/*
# crw-rw-rw- 1 root root    195,   0 ... /dev/nvidia0
# crw-rw---- 1 root render  226,   0 ... /dev/dri/renderD128

注意关键的两栏：

• 权限位：crw-rw---- 这种，表示只有属主和属组可读写；中间那一组 rw 就是"属组的读权限"；
• 属组：render 或 video。

也就是说，GPU 相关设备节点的访问权被授予了 render 组（负责渲染/计算设备）或 video 组（负责视频/显示设备）的成员。只有这些组的成员，才有权打开设备节点。

root 为什么总是好的？因为 root 绕过常规权限检查（或它本就在这些组的能力范围内），所以它能访问任何设备。

普通用户为什么不行？因为它既不是设备属主、也不在 render/video 组里，所以打开设备节点时被内核拒绝。用户态的程序拿不到设备句柄，就只能报"初始化失败/平台创建失败"这种笼统的错误——它看不到"权限被拒"的细节，只知道自己连设备都拿不到。

所以本质是：设备访问权限不在"文件权限位给你看了什么"，而在"你在不在那个组、那个设备节点授给了谁"。 你 chmod 一个普通文件的经验在这里完全用不上——设备节点是另一回事。

解决

两条路，任选其一。

① 用 sudo 运行（最省事，适合临时/一次性任务）：

sudo ./gpu_program

缺点是每次都提权，且 root 跑出来的文件属主是 root，后续普通用户处理可能又碰到别的权限问题。

② 把账号加入 render / video 组（推荐，一次配置长期有效）：

# 加入组
sudo usermod -aG render,video <你的用户名>

# 让组变更生效：重新登录，或临时用 newgrp
newgrp render

必须重新登录（或新开一个会话） 组身份才会生效——已登录的会话不会自动刷新组信息，这是很多人"加了组还是不行"的原因。

改完验证：确认当前会话已带上新组，并能访问设备节点：

id                      # 输出里应出现 render、video
ls -l /dev/dri/         # 确认设备存在

然后重新跑 GPU 程序，应当能正常识别设备。

延伸与预防

这条坑的通用教训是：设备访问权限不在文件权限里，而在组和设备节点权限里。

可复用的思路：

1. "root 能跑、普通用户不能跑"= 权限问题。这个模式几乎百发百中，不用再查库和依赖。
2. 看设备节点的属组。ls -l /dev/dri/*、ls -l /dev/nvidia* 的属组，就是你需要加入的组。常见的是 render、video；摄像头是 video，串口是 dialout，Docker 是 docker——设备/子系统都习惯用一个专属组来授权。
3. 加组后一定重新登录。usermod -aG 只改账号的组成员记录，当前已登录的会话需要重新建立才读取到。用 id 确认。
4. 别用 chmod 666 去改设备节点。设备节点由系统动态管理，手动改权限不持久，也可能带来安全问题。正确的做法是加组（或配 udev 规则），而不是改设备文件的权限位。

一句话：碰到"访问某个设备"的权限问题，去找它的属组，然后把自己加进去——而不是改文件的权限位。