github-starred/firejail
2
0
Fork 0
mirror of https://github.com/netblue30/firejail.git synced 2026-05-15 14:16:14 -06:00
Code Issues 531 Projects Packages Wiki Activity Actions 6

[GH-ISSUE #3644] nvidia: opengl errors with nvidia proprietary driver due to "nogroups" #2294

New issue
Closed
opened 2026-05-05 08:58:54 -06:00 by gitea-mirror · 11 comments
gitea-mirror commented 2026-05-05 08:58:54 -06:00
Owner
Copy link

Originally created by @hlein on GitHub (Sep 24, 2020).
Original GitHub issue: https://github.com/netblue30/firejail/issues/3644

With recent nvidia+opengl+firejail, opengl apps getting nogroups in their profile fail at startup, due to the video group being required to access /dev/nvidia*. This might be similar to #841

I discovered this with Chromium 85+, on Gentoo, but a very simple reproducer is:

$ glxgears     # works
$ firejail --noprofile glxgears     # works
$ firejail --noprofile --nogroups glxgears
Parent pid 5629, child pid 5630
Child process initialized in 10.68 ms
X Error of failed request:  BadValue (integer parameter out of range for operation)
  Major opcode of failed request:  149 (GLX)
  Minor opcode of failed request:  3 (X_GLXCreateContext)
  Value in failed request:  0x0
  Serial number of failed request:  50
  Current serial number in output stream:  51

With chromium and the default profiles, you will get errors like:

$ firejail chromium
Reading profile /etc/firejail/chromium.profile
Reading profile /etc/firejail/chromium-common.profile
Reading profile /etc/firejail/disable-common.inc
Reading profile /etc/firejail/disable-devel.inc
Reading profile /etc/firejail/disable-exec.inc
Reading profile /etc/firejail/disable-interpreters.inc
Reading profile /etc/firejail/disable-programs.inc
Reading profile /etc/firejail/whitelist-common.inc
Reading profile /etc/firejail/whitelist-var-common.inc
Parent pid 18087, child pid 18088
Child process initialized in 89.08 ms
[36:36:0923/121755.556861:ERROR:angle_platform_impl.cc(43)] initialize(795): ANGLE Display::initialize error 12289: Could not create a backing OpenGL context.
[36:36:0923/121755.556949:ERROR:gl_surface_egl.cc(741)] EGL Driver message (Critical) eglInitialize: Could not create a backing OpenGL context.
[36:36:0923/121755.556973:ERROR:gl_surface_egl.cc(1247)] eglInitialize OpenGL failed with error EGL_NOT_INITIALIZED, trying next display type
[36:36:0923/121755.642851:ERROR:angle_platform_impl.cc(43)] initialize(795): ANGLE Display::initialize error 12289: Could not create a backing OpenGL context.
[36:36:0923/121755.642895:ERROR:gl_surface_egl.cc(741)] EGL Driver message (Critical) eglInitialize: Could not create a backing OpenGL context.
[36:36:0923/121755.642917:ERROR:gl_surface_egl.cc(1247)] eglInitialize OpenGLES failed with error EGL_NOT_INITIALIZED
[36:36:0923/121755.642945:ERROR:gl_initializer_linux_x11.cc(160)] GLSurfaceEGL::InitializeOneOff failed.
[36:36:0923/121755.643739:ERROR:viz_main_impl.cc(150)] Exiting GPU process due to errors during initialization

Chromium will start, but is super slow and pegs the CPU, so I guess without any acceleration.

I eventually figured out this is caused by not being able to access /dev/nvidia*. On my system (elogind, no systemd) these are root:video mode 660, and console logins get 'video' group membership, but chromium-common.profile's 'nogroups' drops that.

This setup worked w/o error a week ago, but I've updated multiple things since then that might be relevant - chromium, nvidia drivers, mesa probably, etc. Firejail has had 'nogroups' in chromium-common.profile forever, so it's one of the other things whose behavior has changed. Maybe chromium's startup process of its setuid & dropped-priv processes has changed in such a way that nogroups used to not apply to the GPU process and now it does (purely conjecture).

Environment

  • Linux distribution: Gentoo updated 2020-09-23
  • Firejail version: 0.9.62
  • nvidia drivers version: 455.23.04
  • mesa version: 20.2.0_rc4

Additional context

  • workaround: firejail --ignore=nogroups chromium behaves fine
Originally created by @hlein on GitHub (Sep 24, 2020). Original GitHub issue: https://github.com/netblue30/firejail/issues/3644 With recent nvidia+opengl+firejail, opengl apps getting `nogroups` in their profile fail at startup, due to the `video` group being required to access `/dev/nvidia*`. This might be similar to #841 I discovered this with Chromium 85+, on Gentoo, but a very simple reproducer is: ``` $ glxgears # works $ firejail --noprofile glxgears # works $ firejail --noprofile --nogroups glxgears Parent pid 5629, child pid 5630 Child process initialized in 10.68 ms X Error of failed request: BadValue (integer parameter out of range for operation) Major opcode of failed request: 149 (GLX) Minor opcode of failed request: 3 (X_GLXCreateContext) Value in failed request: 0x0 Serial number of failed request: 50 Current serial number in output stream: 51 ``` With chromium and the default profiles, you will get errors like: ``` $ firejail chromium Reading profile /etc/firejail/chromium.profile Reading profile /etc/firejail/chromium-common.profile Reading profile /etc/firejail/disable-common.inc Reading profile /etc/firejail/disable-devel.inc Reading profile /etc/firejail/disable-exec.inc Reading profile /etc/firejail/disable-interpreters.inc Reading profile /etc/firejail/disable-programs.inc Reading profile /etc/firejail/whitelist-common.inc Reading profile /etc/firejail/whitelist-var-common.inc Parent pid 18087, child pid 18088 Child process initialized in 89.08 ms [36:36:0923/121755.556861:ERROR:angle_platform_impl.cc(43)] initialize(795): ANGLE Display::initialize error 12289: Could not create a backing OpenGL context. [36:36:0923/121755.556949:ERROR:gl_surface_egl.cc(741)] EGL Driver message (Critical) eglInitialize: Could not create a backing OpenGL context. [36:36:0923/121755.556973:ERROR:gl_surface_egl.cc(1247)] eglInitialize OpenGL failed with error EGL_NOT_INITIALIZED, trying next display type [36:36:0923/121755.642851:ERROR:angle_platform_impl.cc(43)] initialize(795): ANGLE Display::initialize error 12289: Could not create a backing OpenGL context. [36:36:0923/121755.642895:ERROR:gl_surface_egl.cc(741)] EGL Driver message (Critical) eglInitialize: Could not create a backing OpenGL context. [36:36:0923/121755.642917:ERROR:gl_surface_egl.cc(1247)] eglInitialize OpenGLES failed with error EGL_NOT_INITIALIZED [36:36:0923/121755.642945:ERROR:gl_initializer_linux_x11.cc(160)] GLSurfaceEGL::InitializeOneOff failed. [36:36:0923/121755.643739:ERROR:viz_main_impl.cc(150)] Exiting GPU process due to errors during initialization ``` Chromium will start, but is super slow and pegs the CPU, so I guess without any acceleration. I eventually figured out this is caused by not being able to access `/dev/nvidia*`. On my system (elogind, no systemd) these are root:video mode 660, and console logins get 'video' group membership, but chromium-common.profile's 'nogroups' drops that. This setup worked w/o error a week ago, but I've updated multiple things since then that might be relevant - chromium, nvidia drivers, mesa probably, etc. Firejail has had 'nogroups' in chromium-common.profile forever, so it's one of the other things whose behavior has changed. Maybe chromium's startup process of its setuid & dropped-priv processes has changed in such a way that `nogroups` used to not apply to the GPU process and now it does (purely conjecture). **Environment** - Linux distribution: Gentoo updated 2020-09-23 - Firejail version: `0.9.62` - nvidia drivers version: `455.23.04` - mesa version: `20.2.0_rc4` **Additional context** - workaround: `firejail --ignore=nogroups chromium` behaves fine
gitea-mirror 2026-05-05 08:58:54 -06:00
  • closed this issue
  • added the
    graphics
         label
gitea-mirror commented 2026-05-05 08:58:57 -06:00
Author
Owner
Copy link

@netblue30 commented on GitHub (Oct 2, 2020):

Question: is it /dev/nvidia or /dev/nvidia0? Can you do a "ls /dev | grep nvidia"? Thanks.

<!-- gh-comment-id:702848435 --> @netblue30 commented on GitHub (Oct 2, 2020): Question: is it /dev/nvidia or /dev/nvidia0? Can you do a "ls /dev | grep nvidia"? Thanks.
gitea-mirror commented 2026-05-05 08:58:58 -06:00
Author
Owner
Copy link

@hlein commented on GitHub (Oct 2, 2020):

There are several, all but /dev/nvidia-caps/ get group 'video':

drwxr-xr-x   2 root root            80 Sep 21 13:54 nvidia-caps/
crw-rw----   1 root video     195, 254 Sep 23 11:17 nvidia-modeset
crw-rw----   1 root video     195,   0 Sep 23 11:17 nvidia0
crw-rw----   1 root video     195,   1 Sep 23 11:17 nvidia1
crw-rw----   1 root video     195, 255 Sep 23 11:17 nvidiactl

I have two cards, so that's likely the nvidiaN's, and I guess a single nvidiactl and nvidia-modeset created by the driver.

I have not tried giving access to only a subset of those (like, maybe write access to nvidiaN but not to nvidiactl would be sufficient?).

<!-- gh-comment-id:702852544 --> @hlein commented on GitHub (Oct 2, 2020): There are several, all but `/dev/nvidia-caps/` get group 'video': ```$ ls -l /dev | grep nvidia drwxr-xr-x 2 root root 80 Sep 21 13:54 nvidia-caps/ crw-rw---- 1 root video 195, 254 Sep 23 11:17 nvidia-modeset crw-rw---- 1 root video 195, 0 Sep 23 11:17 nvidia0 crw-rw---- 1 root video 195, 1 Sep 23 11:17 nvidia1 crw-rw---- 1 root video 195, 255 Sep 23 11:17 nvidiactl ``` I have two cards, so that's likely the nvidiaN's, and I guess a single nvidiactl and nvidia-modeset created by the driver. I have not tried giving access to only a subset of those (like, maybe write access to nvidiaN but not to nvidiactl would be sufficient?).
gitea-mirror commented 2026-05-05 08:58:58 -06:00
Author
Owner
Copy link

@netblue30 commented on GitHub (Oct 2, 2020):

Cool! I've just put a fix in - I disable nogroups automatically if a /dev/nvidiactl file is detected in the filesystem. Give it a try (after bringing back nogroups in your profile). We'll go with it in the next release, maybe we'll find later a better way to do it.

<!-- gh-comment-id:702857188 --> @netblue30 commented on GitHub (Oct 2, 2020): Cool! I've just put a fix in - I disable nogroups automatically if a /dev/nvidiactl file is detected in the filesystem. Give it a try (after bringing back nogroups in your profile). We'll go with it in the next release, maybe we'll find later a better way to do it.
gitea-mirror commented 2026-05-05 08:58:59 -06:00
Author
Owner
Copy link

@hlein commented on GitHub (Oct 3, 2020):

@netblue30 that did it!

Applied that to 0.9.62.4 and rebuilt; now without passing --ignore=nogroups, at startup I see:

Warning: Warning: NVIDIA card detected, nogroups command disabled

And there's no GL errors.

This does make me wonder a couple things, though:

  1. systemd systems might get write access to /dev/nvidia* some other way, I don't know. It's possible this workaround isn't required when using systemd.

  2. Is there any way, or an existing wishlist item, for keeping just a specific group but going ahead and dropping others? My UID has many supplemental groups; I would be glad to have firejail drop all of them except for the minimum required (video... maybe audio for /dev/snd/* ?) If that needs its own issue/discussion, since it's an enhancement not a bugfix, wfm.

<!-- gh-comment-id:703022805 --> @hlein commented on GitHub (Oct 3, 2020): @netblue30 that did it! Applied that to 0.9.62.4 and rebuilt; now without passing --ignore=nogroups, at startup I see: `Warning: Warning: NVIDIA card detected, nogroups command disabled` And there's no GL errors. This does make me wonder a couple things, though: 1. systemd systems might get write access to /dev/nvidia* some other way, I don't know. It's possible this workaround isn't required when using systemd. 1. Is there any way, or an existing wishlist item, for keeping just a specific group but going ahead and dropping others? My UID has many supplemental groups; I would be glad to have firejail drop all of them except for the minimum required (video... maybe audio for /dev/snd/* ?) If that needs its own issue/discussion, since it's an enhancement not a bugfix, wfm.
gitea-mirror commented 2026-05-05 08:58:59 -06:00
Author
Owner
Copy link

@rusty-snake commented on GitHub (Oct 3, 2020):

@hlein #2042 #3169 #3303

@netblue30 What about access("/dev/nvidiactl", R_OK) == 0 && arg_no3d == 0, so we only skip nogroups if OpenGL/Vulkan/3D is allowed.

<!-- gh-comment-id:703067860 --> @rusty-snake commented on GitHub (Oct 3, 2020): @hlein #2042 #3169 #3303 @netblue30 What about `access("/dev/nvidiactl", R_OK) == 0 && arg_no3d == 0`, so we only skip `nogroups` if OpenGL/Vulkan/3D is allowed.
gitea-mirror commented 2026-05-05 08:59:00 -06:00
Author
Owner
Copy link

@netblue30 commented on GitHub (Oct 3, 2020):

&& arg_no3d == 0

Good point! Thanks for the bug and testing @hlein, I'll close it for now. I'll have a test release out this weekend (0.9.64.rc1).

<!-- gh-comment-id:703093094 --> @netblue30 commented on GitHub (Oct 3, 2020): > && arg_no3d == 0 Good point! Thanks for the bug and testing @hlein, I'll close it for now. I'll have a test release out this weekend (0.9.64.rc1).
gitea-mirror commented 2026-05-05 08:59:00 -06:00
Author
Owner
Copy link

@s3rgeym commented on GitHub (Dec 1, 2021):

same shit

➜ firejail --version
firejail version 0.9.66

<!-- gh-comment-id:983229368 --> @s3rgeym commented on GitHub (Dec 1, 2021): same shit ➜ firejail --version firejail version 0.9.66
gitea-mirror commented 2026-05-05 08:59:00 -06:00
Author
Owner
Copy link

@kmk3 commented on GitHub (Dec 4, 2021):

@tz4678 commented on Dec 1:

same shit

➜ firejail --version
firejail version 0.9.66

What distro and version?

What's the output of ls -l /dev/nvidia*?

Could you build from #4732 and test to see if it makes any difference?

@hlein Do you still have this issue? If so, could you test as well?

<!-- gh-comment-id:985949316 --> @kmk3 commented on GitHub (Dec 4, 2021): @tz4678 commented [on Dec 1](https://github.com/netblue30/firejail/issues/3644#issuecomment-983229368): > same shit > > ➜ firejail --version > firejail version 0.9.66 What distro and version? What's the output of `ls -l /dev/nvidia*`? Could you build from #4732 and test to see if it makes any difference? @hlein Do you still have this issue? If so, could you test as well?
gitea-mirror commented 2026-05-05 08:59:01 -06:00
Author
Owner
Copy link

@s3rgeym commented on GitHub (Dec 8, 2021):

@tz4678 commented on Dec 1:

same shit
➜ firejail --version
firejail version 0.9.66

What distro and version?

What's the output of ls -l /dev/nvidia*?

Could you build from #4732 and test to see if it makes any difference?

@hlein Do you still have this issue? If so, could you test as well?

Downloads/Telegram Desktop/ChatExport_2021-12-08 
➜ ls -l /dev/nvidia*
crw-rw-rw- 1 root root   195,   0 Dec  7 03:44 /dev/nvidia0
crw-rw-rw- 1 root root   195, 255 Dec  7 03:44 /dev/nvidiactl
crw-rw-rw- 1 root root   195, 254 Dec  7 09:29 /dev/nvidia-modeset
crw-rw-rw- 1 root root   507,   0 Dec  7 03:44 /dev/nvidia-uvm
crw-rw-rw- 1 root root   507,   1 Dec  7 03:44 /dev/nvidia-uvm-tools

/dev/nvidia-caps:
total 0
cr-------- 1 root root 510, 1 Dec  7 09:29 nvidia-cap1
cr--r--r-- 1 root root 510, 2 Dec  7 09:29 nvidia-cap2

Downloads/Telegram Desktop/ChatExport_2021-12-08 
➜ uname -a     
Linux sergey-laptop 5.15.6-arch2-1 #1 SMP PREEMPT Thu, 02 Dec 2021 15:47:09 +0000 x86_64 GNU/Linux

Downloads/Telegram Desktop/ChatExport_2021-12-08 
➜ yay -Qi nvidia  
Name            : nvidia
Version         : 495.44-14
Description     : NVIDIA drivers for linux
Architecture    : x86_64
URL             : https://www.nvidia.com/
Licenses        : custom
Groups          : None
Provides        : NVIDIA-MODULE
Depends On      : linux  nvidia-utils=495.44  libglvnd
Optional Deps   : None
Required By     : None
Optional For    : None
Conflicts With  : None
Replaces        : None
Installed Size  : 25.70 MiB
Packager        : Jan Alexander Steffens (heftig) <heftig@archlinux.org>
Build Date      : Thu 02 Dec 2021 07:18:04 PM MSK
Install Date    : Sat 04 Dec 2021 11:04:35 AM MSK
Install Reason  : Explicitly installed
Install Script  : No
Validated By    : Signature
<!-- gh-comment-id:988478169 --> @s3rgeym commented on GitHub (Dec 8, 2021): > @tz4678 commented [on Dec 1](https://github.com/netblue30/firejail/issues/3644#issuecomment-983229368): > > > same shit > > ➜ firejail --version > > firejail version 0.9.66 > > What distro and version? > > What's the output of `ls -l /dev/nvidia*`? > > Could you build from #4732 and test to see if it makes any difference? > > @hlein Do you still have this issue? If so, could you test as well? ```bash Downloads/Telegram Desktop/ChatExport_2021-12-08 ➜ ls -l /dev/nvidia* crw-rw-rw- 1 root root 195, 0 Dec 7 03:44 /dev/nvidia0 crw-rw-rw- 1 root root 195, 255 Dec 7 03:44 /dev/nvidiactl crw-rw-rw- 1 root root 195, 254 Dec 7 09:29 /dev/nvidia-modeset crw-rw-rw- 1 root root 507, 0 Dec 7 03:44 /dev/nvidia-uvm crw-rw-rw- 1 root root 507, 1 Dec 7 03:44 /dev/nvidia-uvm-tools /dev/nvidia-caps: total 0 cr-------- 1 root root 510, 1 Dec 7 09:29 nvidia-cap1 cr--r--r-- 1 root root 510, 2 Dec 7 09:29 nvidia-cap2 Downloads/Telegram Desktop/ChatExport_2021-12-08 ➜ uname -a Linux sergey-laptop 5.15.6-arch2-1 #1 SMP PREEMPT Thu, 02 Dec 2021 15:47:09 +0000 x86_64 GNU/Linux Downloads/Telegram Desktop/ChatExport_2021-12-08 ➜ yay -Qi nvidia Name : nvidia Version : 495.44-14 Description : NVIDIA drivers for linux Architecture : x86_64 URL : https://www.nvidia.com/ Licenses : custom Groups : None Provides : NVIDIA-MODULE Depends On : linux nvidia-utils=495.44 libglvnd Optional Deps : None Required By : None Optional For : None Conflicts With : None Replaces : None Installed Size : 25.70 MiB Packager : Jan Alexander Steffens (heftig) <heftig@archlinux.org> Build Date : Thu 02 Dec 2021 07:18:04 PM MSK Install Date : Sat 04 Dec 2021 11:04:35 AM MSK Install Reason : Explicitly installed Install Script : No Validated By : Signature ```
gitea-mirror commented 2026-05-05 08:59:01 -06:00
Author
Owner
Copy link

@kmk3 commented on GitHub (Dec 8, 2021):

@tz4678 commented on Dec 8:

What distro and version?

What's the output of ls -l /dev/nvidia*?

➜ ls -l /dev/nvidia*
crw-rw-rw- 1 root root   195,   0 Dec  7 03:44 /dev/nvidia0
crw-rw-rw- 1 root root   195, 255 Dec  7 03:44 /dev/nvidiactl
crw-rw-rw- 1 root root   195, 254 Dec  7 09:29 /dev/nvidia-modeset
crw-rw-rw- 1 root root   507,   0 Dec  7 03:44 /dev/nvidia-uvm
crw-rw-rw- 1 root root   507,   1 Dec  7 03:44 /dev/nvidia-uvm-tools

Weird, AFAIK they are usually owned by either the "render" or the "video" group
(example from this thread), unless you're not using (e)udev.

/dev/nvidia-caps:
total 0
cr-------- 1 root root 510, 1 Dec  7 09:29 nvidia-cap1
cr--r--r-- 1 root root 510, 2 Dec  7 09:29 nvidia-cap2

These might be normal.

What is the output of these commands:

$ pacman -Q logind udev
$ getfacl /dev/nvidia0 /dev/nvidiactl
$ udevadm info /dev/nvidia0 /dev/nvidiactl | grep SUBSYSTEM
$ udevadm test "$(udevadm info --query=path --name=/dev/nvidia0)" 2>&1 |
  grep -e GROUP -e MODE
$ udevadm test "$(udevadm info --query=path --name=/dev/nvidiactl)" 2>&1 |
  grep -e GROUP -e MODE
$ getent group | grep "$(udevadm test "$(udevadm info --query=path \
  --name=/dev/nvidia0)" 2>&1 | grep -e GROUP | rev | cut -f 1 -d ' ' | rev)"
$ getent group | grep "$(udevadm test "$(udevadm info --query=path \
  --name=/dev/nvidiactl)" 2>&1 | grep -e GROUP | rev | cut -f 1 -d ' ' | rev)"

For reference, this is the output on my system (using the path for AMD):

$ pacman -Q logind udev
elogind 246.10-5
eudev 249.7-2
$ getfacl /dev/dri/renderD128
getfacl: Removing leading '/' from absolute path names
# file: dev/dri/renderD128
# owner: root
# group: render
user::rw-
group::rw-
other::rw-

$ udevadm info /dev/dri/renderD128 | grep SUBSYSTEM
E: SUBSYSTEM=drm
$ udevadm test "$(udevadm info --query=path --name=/dev/dri/renderD128)" 2>&1 |
  grep -e GROUP -e MODE
renderD128: /usr/lib/udev/rules.d/50-udev-default.rules:39 GROUP 988
renderD128: /usr/lib/udev/rules.d/50-udev-default.rules:39 MODE 0666
$ getent group | grep "$(udevadm test "$(udevadm info --query=path \
  --name=/dev/dri/renderD128)" 2>&1 | grep -e GROUP | rev | cut -f 1 -d ' ' | rev)"
render:x:988:

➜ uname -a     
Linux sergey-laptop 5.15.6-arch2-1 #1 SMP PREEMPT Thu, 02 Dec 2021 15:47:09 +0000 x86_64 GNU/Linux

Is this normal Arch Linux or a derivative?

➜ yay -Qi nvidia  
Name            : nvidia
Version         : 495.44-14
Description     : NVIDIA drivers for linux
Architecture    : x86_64
URL             : https://www.nvidia.com/
Licenses        : custom
Groups          : None
Provides        : NVIDIA-MODULE
Depends On      : linux  nvidia-utils=495.44  libglvnd
Optional Deps   : None
Required By     : None
Optional For    : None
Conflicts With  : None
Replaces        : None
Installed Size  : 25.70 MiB
Packager        : Jan Alexander Steffens (heftig) <heftig@archlinux.org>
Build Date      : Thu 02 Dec 2021 07:18:04 PM MSK
Install Date    : Sat 04 Dec 2021 11:04:35 AM MSK
Install Reason  : Explicitly installed
Install Script  : No
Validated By    : Signature
<!-- gh-comment-id:988523518 --> @kmk3 commented on GitHub (Dec 8, 2021): @tz4678 commented [on Dec 8](https://github.com/netblue30/firejail/issues/3644#issuecomment-988478169): > > What distro and version? > > > > What's the output of `ls -l /dev/nvidia*`? > > ```shell > ➜ ls -l /dev/nvidia* > crw-rw-rw- 1 root root 195, 0 Dec 7 03:44 /dev/nvidia0 > crw-rw-rw- 1 root root 195, 255 Dec 7 03:44 /dev/nvidiactl > crw-rw-rw- 1 root root 195, 254 Dec 7 09:29 /dev/nvidia-modeset > crw-rw-rw- 1 root root 507, 0 Dec 7 03:44 /dev/nvidia-uvm > crw-rw-rw- 1 root root 507, 1 Dec 7 03:44 /dev/nvidia-uvm-tools > > ``` Weird, AFAIK they are usually owned by either the "render" or the "video" group ([example from this thread][1]), unless you're not using (e)udev. > ``` > /dev/nvidia-caps: > total 0 > cr-------- 1 root root 510, 1 Dec 7 09:29 nvidia-cap1 > cr--r--r-- 1 root root 510, 2 Dec 7 09:29 nvidia-cap2 > > ``` These might be normal. What is the output of these commands: ```console $ pacman -Q logind udev $ getfacl /dev/nvidia0 /dev/nvidiactl $ udevadm info /dev/nvidia0 /dev/nvidiactl | grep SUBSYSTEM $ udevadm test "$(udevadm info --query=path --name=/dev/nvidia0)" 2>&1 | grep -e GROUP -e MODE $ udevadm test "$(udevadm info --query=path --name=/dev/nvidiactl)" 2>&1 | grep -e GROUP -e MODE $ getent group | grep "$(udevadm test "$(udevadm info --query=path \ --name=/dev/nvidia0)" 2>&1 | grep -e GROUP | rev | cut -f 1 -d ' ' | rev)" $ getent group | grep "$(udevadm test "$(udevadm info --query=path \ --name=/dev/nvidiactl)" 2>&1 | grep -e GROUP | rev | cut -f 1 -d ' ' | rev)" ``` For reference, this is the output on my system (using the path for AMD): ```console $ pacman -Q logind udev elogind 246.10-5 eudev 249.7-2 $ getfacl /dev/dri/renderD128 getfacl: Removing leading '/' from absolute path names # file: dev/dri/renderD128 # owner: root # group: render user::rw- group::rw- other::rw- $ udevadm info /dev/dri/renderD128 | grep SUBSYSTEM E: SUBSYSTEM=drm $ udevadm test "$(udevadm info --query=path --name=/dev/dri/renderD128)" 2>&1 | grep -e GROUP -e MODE renderD128: /usr/lib/udev/rules.d/50-udev-default.rules:39 GROUP 988 renderD128: /usr/lib/udev/rules.d/50-udev-default.rules:39 MODE 0666 $ getent group | grep "$(udevadm test "$(udevadm info --query=path \ --name=/dev/dri/renderD128)" 2>&1 | grep -e GROUP | rev | cut -f 1 -d ' ' | rev)" render:x:988: ``` > ``` > ➜ uname -a > Linux sergey-laptop 5.15.6-arch2-1 #1 SMP PREEMPT Thu, 02 Dec 2021 15:47:09 +0000 x86_64 GNU/Linux > ``` Is this normal Arch Linux or a derivative? > ``` > ➜ yay -Qi nvidia > Name : nvidia > Version : 495.44-14 > Description : NVIDIA drivers for linux > Architecture : x86_64 > URL : https://www.nvidia.com/ > Licenses : custom > Groups : None > Provides : NVIDIA-MODULE > Depends On : linux nvidia-utils=495.44 libglvnd > Optional Deps : None > Required By : None > Optional For : None > Conflicts With : None > Replaces : None > Installed Size : 25.70 MiB > Packager : Jan Alexander Steffens (heftig) <heftig@archlinux.org> > Build Date : Thu 02 Dec 2021 07:18:04 PM MSK > Install Date : Sat 04 Dec 2021 11:04:35 AM MSK > Install Reason : Explicitly installed > Install Script : No > Validated By : Signature > ``` [1]: https://github.com/netblue30/firejail/issues/3644#issuecomment-702852544
gitea-mirror commented 2026-05-05 08:59:02 -06:00
Author
Owner
Copy link

@s3rgeym commented on GitHub (Dec 8, 2021):

@tz4678 commented on Dec 8:

What distro and version?
What's the output of ls -l /dev/nvidia*?

➜ ls -l /dev/nvidia*
crw-rw-rw- 1 root root   195,   0 Dec  7 03:44 /dev/nvidia0
crw-rw-rw- 1 root root   195, 255 Dec  7 03:44 /dev/nvidiactl
crw-rw-rw- 1 root root   195, 254 Dec  7 09:29 /dev/nvidia-modeset
crw-rw-rw- 1 root root   507,   0 Dec  7 03:44 /dev/nvidia-uvm
crw-rw-rw- 1 root root   507,   1 Dec  7 03:44 /dev/nvidia-uvm-tools

Weird, AFAIK they are usually owned by either the "render" or the "video" group (example from this thread), unless you're not using (e)udev.

/dev/nvidia-caps:
total 0
cr-------- 1 root root 510, 1 Dec  7 09:29 nvidia-cap1
cr--r--r-- 1 root root 510, 2 Dec  7 09:29 nvidia-cap2

These might be normal.

What is the output of these commands:

$ pacman -Q logind udev
$ getfacl /dev/nvidia0 /dev/nvidiactl
$ udevadm info /dev/nvidia0 /dev/nvidiactl | grep SUBSYSTEM
$ udevadm test "$(udevadm info --query=path --name=/dev/nvidia0)" 2>&1 |
  grep -e GROUP -e MODE
$ udevadm test "$(udevadm info --query=path --name=/dev/nvidiactl)" 2>&1 |
  grep -e GROUP -e MODE
$ getent group | grep "$(udevadm test "$(udevadm info --query=path \
  --name=/dev/nvidia0)" 2>&1 | grep -e GROUP | rev | cut -f 1 -d ' ' | rev)"
$ getent group | grep "$(udevadm test "$(udevadm info --query=path \
  --name=/dev/nvidiactl)" 2>&1 | grep -e GROUP | rev | cut -f 1 -d ' ' | rev)"

For reference, this is the output on my system (using the path for AMD):

$ pacman -Q logind udev
elogind 246.10-5
eudev 249.7-2
$ getfacl /dev/dri/renderD128
getfacl: Removing leading '/' from absolute path names
# file: dev/dri/renderD128
# owner: root
# group: render
user::rw-
group::rw-
other::rw-

$ udevadm info /dev/dri/renderD128 | grep SUBSYSTEM
E: SUBSYSTEM=drm
$ udevadm test "$(udevadm info --query=path --name=/dev/dri/renderD128)" 2>&1 |
  grep -e GROUP -e MODE
renderD128: /usr/lib/udev/rules.d/50-udev-default.rules:39 GROUP 988
renderD128: /usr/lib/udev/rules.d/50-udev-default.rules:39 MODE 0666
$ getent group | grep "$(udevadm test "$(udevadm info --query=path \
  --name=/dev/dri/renderD128)" 2>&1 | grep -e GROUP | rev | cut -f 1 -d ' ' | rev)"
render:x:988:

➜ uname -a     
Linux sergey-laptop 5.15.6-arch2-1 #1 SMP PREEMPT Thu, 02 Dec 2021 15:47:09 +0000 x86_64 GNU/Linux

Is this normal Arch Linux or a derivative?

➜ yay -Qi nvidia  
Name            : nvidia
Version         : 495.44-14
Description     : NVIDIA drivers for linux
Architecture    : x86_64
URL             : https://www.nvidia.com/
Licenses        : custom
Groups          : None
Provides        : NVIDIA-MODULE
Depends On      : linux  nvidia-utils=495.44  libglvnd
Optional Deps   : None
Required By     : None
Optional For    : None
Conflicts With  : None
Replaces        : None
Installed Size  : 25.70 MiB
Packager        : Jan Alexander Steffens (heftig) <heftig@archlinux.org>
Build Date      : Thu 02 Dec 2021 07:18:04 PM MSK
Install Date    : Sat 04 Dec 2021 11:04:35 AM MSK
Install Reason  : Explicitly installed
Install Script  : No
Validated By    : Signature

normal
i does not have logind

systemd 249.7-2

# file: dev/nvidia0
# owner: root
# group: root
user::rw-
group::rw-
other::rw-

# file: dev/nvidiactl
# owner: root
# group: root
user::rw-
group::rw-
other::rw-
<!-- gh-comment-id:988567614 --> @s3rgeym commented on GitHub (Dec 8, 2021): > @tz4678 commented [on Dec 8](https://github.com/netblue30/firejail/issues/3644#issuecomment-988478169): > > > > What distro and version? > > > What's the output of `ls -l /dev/nvidia*`? > > > > > > ```shell > > ➜ ls -l /dev/nvidia* > > crw-rw-rw- 1 root root 195, 0 Dec 7 03:44 /dev/nvidia0 > > crw-rw-rw- 1 root root 195, 255 Dec 7 03:44 /dev/nvidiactl > > crw-rw-rw- 1 root root 195, 254 Dec 7 09:29 /dev/nvidia-modeset > > crw-rw-rw- 1 root root 507, 0 Dec 7 03:44 /dev/nvidia-uvm > > crw-rw-rw- 1 root root 507, 1 Dec 7 03:44 /dev/nvidia-uvm-tools > > ``` > > Weird, AFAIK they are usually owned by either the "render" or the "video" group ([example from this thread](https://github.com/netblue30/firejail/issues/3644#issuecomment-702852544)), unless you're not using (e)udev. > > > ``` > > /dev/nvidia-caps: > > total 0 > > cr-------- 1 root root 510, 1 Dec 7 09:29 nvidia-cap1 > > cr--r--r-- 1 root root 510, 2 Dec 7 09:29 nvidia-cap2 > > ``` > > These might be normal. > > What is the output of these commands: > > ``` > $ pacman -Q logind udev > $ getfacl /dev/nvidia0 /dev/nvidiactl > $ udevadm info /dev/nvidia0 /dev/nvidiactl | grep SUBSYSTEM > $ udevadm test "$(udevadm info --query=path --name=/dev/nvidia0)" 2>&1 | > grep -e GROUP -e MODE > $ udevadm test "$(udevadm info --query=path --name=/dev/nvidiactl)" 2>&1 | > grep -e GROUP -e MODE > $ getent group | grep "$(udevadm test "$(udevadm info --query=path \ > --name=/dev/nvidia0)" 2>&1 | grep -e GROUP | rev | cut -f 1 -d ' ' | rev)" > $ getent group | grep "$(udevadm test "$(udevadm info --query=path \ > --name=/dev/nvidiactl)" 2>&1 | grep -e GROUP | rev | cut -f 1 -d ' ' | rev)" > ``` > > For reference, this is the output on my system (using the path for AMD): > > ``` > $ pacman -Q logind udev > elogind 246.10-5 > eudev 249.7-2 > $ getfacl /dev/dri/renderD128 > getfacl: Removing leading '/' from absolute path names > # file: dev/dri/renderD128 > # owner: root > # group: render > user::rw- > group::rw- > other::rw- > > $ udevadm info /dev/dri/renderD128 | grep SUBSYSTEM > E: SUBSYSTEM=drm > $ udevadm test "$(udevadm info --query=path --name=/dev/dri/renderD128)" 2>&1 | > grep -e GROUP -e MODE > renderD128: /usr/lib/udev/rules.d/50-udev-default.rules:39 GROUP 988 > renderD128: /usr/lib/udev/rules.d/50-udev-default.rules:39 MODE 0666 > $ getent group | grep "$(udevadm test "$(udevadm info --query=path \ > --name=/dev/dri/renderD128)" 2>&1 | grep -e GROUP | rev | cut -f 1 -d ' ' | rev)" > render:x:988: > ``` > > > ``` > > ➜ uname -a > > Linux sergey-laptop 5.15.6-arch2-1 #1 SMP PREEMPT Thu, 02 Dec 2021 15:47:09 +0000 x86_64 GNU/Linux > > ``` > > Is this normal Arch Linux or a derivative? > > > ``` > > ➜ yay -Qi nvidia > > Name : nvidia > > Version : 495.44-14 > > Description : NVIDIA drivers for linux > > Architecture : x86_64 > > URL : https://www.nvidia.com/ > > Licenses : custom > > Groups : None > > Provides : NVIDIA-MODULE > > Depends On : linux nvidia-utils=495.44 libglvnd > > Optional Deps : None > > Required By : None > > Optional For : None > > Conflicts With : None > > Replaces : None > > Installed Size : 25.70 MiB > > Packager : Jan Alexander Steffens (heftig) <heftig@archlinux.org> > > Build Date : Thu 02 Dec 2021 07:18:04 PM MSK > > Install Date : Sat 04 Dec 2021 11:04:35 AM MSK > > Install Reason : Explicitly installed > > Install Script : No > > Validated By : Signature > > ``` normal i does not have logind ``` systemd 249.7-2 # file: dev/nvidia0 # owner: root # group: root user::rw- group::rw- other::rw- # file: dev/nvidiactl # owner: root # group: root user::rw- group::rw- other::rw- ```
Sign in to join this conversation.
No Branch/Tag specified
Branches Tags
master
serialize_remounts_v2
landlock_v4
landlock
release-0.9.64
release-0.9.62
gitlab_ci
LTSbase
fred_ctests
docs
0.9.80
0.9.80-rc1
0.9.78
0.9.76
0.9.76-rc4
0.9.76-rc3
0.9.76-rc2
0.9.76-rc1
0.9.74
landlock-split
0.9.72
0.9.72rc1
0.9.70
0.9.68
0.9.68rc1
0.9.66
0.9.66rc1
0.9.64.4
0.9.64.2
0.9.64
0.9.64rc1
0.9.62.4
0.9.62.2
0.9.62
0.9.56.2-LTS
0.9.60
0.9.60-rc1
0.9.58.2
0.9.58
0.9.58-rc1
0.9.56-LTS-release
0.9.56-LTS
0.9.56
0.9.56-rc1
0.9.54
0.9.54-rc2
0.9.54-rc1
0.9.52
0.9.38.12
0.9.50
0.9.50-rc1
0.9.48
0.9.46
0.9.46-rc1
0.9.44.10
0.9.44.8
0.9.44.6
0.9.38.10
0.9.44.4
0.9.38.8
0.9.44.2
0.9.44
0.9.44-rc1
0.9.38.4
0.9.42
0.9.42-rc2
0.9.38.2
0.9.42-rc1
disable-globalcfg
0.9.40
0.9.40-rc1
0.9.38
0.9.38-rc1
0.9.36
0.9.36-rc1
0.9.34
0.9.34-rc1
0.9.32
0.9.32-rc1
0.9.30
0.9.30-rc1
Labels
Clear labels   
LTS merge

   
LTS merge

   
bug

   
bug

   
converted-to-discussion

   
doc-todo

   
documentation

   
duplicate

   
enhancement

   
file-transfer

   
firecfg

   
firejail-in-firejail

   
firetools

   
graphics

   
help wanted

   
information_old

   
installation

   
invalid

   
modif

   
moved

   
needinfo

   
networking

   
notabug

   
notourbug

   
old-version

   
overlayfs

   
packaging

   
profile-request

   
pull-request

Mirrored from GitHub Pull Request

  
question

   
question_old

   
removal

   
runtime-permissions

   
sandbox-ipc

   
security

   
stale

   
wiki

   
wiki

   
wontfix

   
wordpress

   
workaround
No labels
LTS merge
LTS merge
bug
bug
converted-to-discussion
doc-todo
documentation
duplicate
enhancement
file-transfer
firecfg
firejail-in-firejail
firetools
graphics
help wanted
information_old
installation
invalid
modif
moved
needinfo
networking
notabug
notourbug
old-version
overlayfs
packaging
profile-request
pull-request
question
question_old
removal
runtime-permissions
sandbox-ipc
security
stale
wiki
wiki
wontfix
wordpress
workaround
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/firejail#2294
No description provided.
Delete branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?