A user encounters "permission denied" errors when running GPU-accelerated containers on a Secure Boot-enabled system. What resolves this?

When UEFI Secure Boot is enabled, the operating system kernel will only load modules that have a valid digital signature. The "permission denied" error occurs because the unsigned NVIDIA kernel modules are blocked from loading, making the GPU devices (/dev/nvidia) unavailable to any process, including containers. The correct resolution is to sign the NVIDIA kernel modules using a Machine Owner Key (MOK) that is enrolled in the system's firmware. This allows the kernel to trust and load the drivers, restoring GPU access while maintaining the integrity protections of Secure Boot.

Disabling Secure Boot: This is an insecure workaround that compromises the system's boot-time security posture, rather than correctly resolving the module signing issue.

Running containers in privileged mode: This does not solve the underlying problem, as the kernel has already blocked the necessary NVIDIA driver from loading.

Reinstalling the container runtime: The issue is at the kernel driver level, not with the container runtime (e.g., Docker, containerd), so reinstallation would have no effect.

1. NVIDIA CUDA Toolkit Documentation, Installation Guide for Linux, Section 7.3 "Install with DKMS and for Secure Boot". The guide details the process of enrolling a MOK and how the installer can automatically sign the kernel modules.

2. Ubuntu Documentation, "Kernel/SecureBoot". This official OS documentation explains the principles of Secure Boot and the requirement for signed kernel modules.

3. Red Hat Enterprise Linux Documentation, "Signing Kernel Modules for Secure Boot". This guide provides detailed steps for creating keys and signing third-party modules like the NVIDIA driver.