"Permission denied" on /dev/kfd — the AMD GPU group fix

Works with sudo, fails as my user

作者 Jakub Rusinowski

错误信息

Unable to open /dev/kfd read-write: Permission denied
rocminfo: HSA_STATUS_ERROR_OUT_OF_RESOURCES

hsa api call failure at: ... HSA_STATUS_ERROR_OUT_OF_RESOURCES

1. 1

   Add your user to the render and video groups

   One command, and it is the documented prerequisite in AMD's own ROCm installation guide. -a matters: without it, usermod -G replaces your entire group list rather than appending to it, which can remove you from sudo and lock you out of administration on the machine.

   注意：Always include -a. sudo usermod -G video,render $LOGNAME without it replaces every secondary group you belong to, sudo included, and on a machine with no other administrator that is a recovery-media problem.

   bash复制

   # bash
   sudo usermod -a -G video,render $LOGNAME
   
   # Confirm the account record was updated (this does NOT mean it is active yet)
   id -nG $LOGNAME
   ls -l /dev/kfd /dev/dri/render*

   生效了吗？id -nG lists render and video. Note this reads the account database — your current session still does not have them, which fix 2 is about.

   bash复制

   id -nG $LOGNAME | tr ' ' '\n' | grep -E '^(render|video)$'

2. 2

   Log out and back in — this is the step that makes people think it failed

   Group membership is established when your session is created. Your shell, and every process it will ever start, is still carrying the group list from before you ran usermod, and no amount of re-running the command changes that. Log out of your desktop session entirely, or reconnect your SSH session, and try again. newgrp render grants the group in the current shell only — useful for a quick test, not a fix, and a fresh terminal will not have it.

   bash复制

   # bash — quick test without logging out (this shell only)
   newgrp render
   rocminfo | grep -i "Marketing Name:"
   
   # The real check, after logging out and back in
   groups
   rocminfo | grep -i "Marketing Name:"

   生效了吗？groups — not id -nG — includes render and video in a brand-new terminal, and rocminfo names your card without sudo.

   bash复制

   groups
   rocminfo | grep -c gfx

3. 3

   Add the ollama service user too, not just your own

   This is the half that gets missed. When Ollama runs as a systemd service it runs as the ollama user, and that account needs the same group membership. Fixing your own login does nothing for it — which is exactly why rocminfo succeeds in your terminal while the service insists there is no GPU. The service picks up new groups on restart rather than needing a login.

   bash复制

   # bash
   sudo usermod -a -G render,video ollama
   sudo systemctl restart ollama
   
   # What groups does the service user actually have?
   id -nG ollama
   journalctl -u ollama --no-pager -n 40 | grep -i -E "gpu|rocm|vulkan"

   生效了吗？The service log reports a GPU, and a loaded model shows GPU placement rather than CPU.

   bash复制

   ollama run gemma3:1b "hi" && ollama ps

4. 4

   Pass the numeric group IDs into containers

   Inside a container the group names mean nothing — the image has its own /etc/group and its render group, if it has one, will have a different number. What the kernel checks is the numeric GID, so pass those. Get them from ls -lnd, where -n prints numbers instead of names, and hand them to --group-add.

   bash复制

   # bash — -n gives numeric owners, which is what you need here
   ls -lnd /dev/kfd /dev/dri /dev/dri/*
   
   docker run --rm --device /dev/kfd --device /dev/dri \
     --group-add 44 --group-add 993 \
     rocm/dev-ubuntu-22.04 rocminfo

   生效了吗？rocminfo inside the container lists a GPU agent. Only a CPU agent means the GIDs are still wrong.

   bash复制

   docker run --rm --device /dev/kfd --device /dev/dri --group-add 44 --group-add 993 rocm/dev-ubuntu-22.04 rocminfo | grep -i "Marketing Name"

5. 5

   Write a udev rule where the distribution differs

   Not every distribution uses the same names or ownership for these nodes, and on some the group can be reset by a driver package update. A udev rule pins the ownership yourself and survives updates, which makes it the durable answer on a machine you maintain. Check what the nodes actually look like first — the rule should match your system, not a copied example.

   注意：A udev rule with mode 0666 makes the GPU compute node world-accessible to every local user. Set the group and use 0660 instead unless you have a specific reason not to.

   bash复制

   # bash — inspect first
   ls -l /dev/kfd /dev/dri/render*
   
   # Then pin ownership
   sudo tee /etc/udev/rules.d/70-amdgpu-compute.rules >/dev/null <<'EOF'
   KERNEL=="kfd", GROUP="render", MODE="0660"
   SUBSYSTEM=="drm", KERNEL=="renderD*", GROUP="render", MODE="0660"
   EOF
   sudo udevadm control --reload-rules && sudo udevadm trigger

   生效了吗？Both device nodes show group render and mode crw-rw----, and they keep those values after a reboot.

   bash复制

   ls -l /dev/kfd /dev/dri/render*

6. 6

   Stop running inference as root最常见的修复方法

   Worth saying directly, because sudo ollama serve works and is therefore tempting. Running inference as root means every model you pull, every file the process writes, and every bug in a fast-moving stack executes with full system privileges — and it creates root-owned files in your model store that your normal user then cannot manage. It is not a fix; it is the diagnosis restated as a habit. The group change above takes one command and a logout.

   bash复制

   # bash — undo root-owned artefacts from earlier sudo runs
   sudo chown -R $LOGNAME:$LOGNAME ~/.ollama
   ls -ld ~/.ollama ~/.ollama/models

   生效了吗？Your model directory is owned by you, and inference runs without sudo.

   bash复制

   ls -ld ~/.ollama/models && rocminfo | grep -c gfx

   检查哪些模型适配你的硬件see what your Radeon can run once ROCm can reach it打开显存检查器 →