Fix 'nvidia-smi: command not found'

The nvidia-smi command not found error means the shell cannot find the program, and on a rented GPU VM there are three causes to check: you typed it inside a Docker container that was started without the GPU, you ran it through sudo or as root and the program is outside sudo's search path, or the image has no NVIDIA driver. NVIDIA's driver README says nvidia-smi is included with the NVIDIA Linux graphics driver, so a missing command points at the driver or the shell, not at the GPU. The NVIDIA, Docker and sudo facts below were checked on 12 November 2026.

bash: nvidia-smi: command not found

That wording comes from a report in NVIDIA's nvidia-docker tracker, where the fix was to start the container with the GPU. Docker words the same failure as exec: "nvidia-smi": executable file not found in $PATH, as in a toolkit report.

Find out where the command is missing

I run these on the VM's own shell, not inside a container:

command -v nvidia-smi
ls -l /usr/bin/nvidia-smi
cat /proc/driver/nvidia/version
lspci | grep -i nvidia
dpkg -l | grep -i nvidia

The README installs the program at /usr/bin/nvidia-smi. NVIDIA's post-installation page says /proc/driver/nvidia/version shows the driver version when the driver is loaded, and its CUDA installation guide checks that the GPU is visible with lspci | grep -i nvidia. The last command lists the NVIDIA packages on the disk. The table turns the output into a cause, and the sections below follow it in order.

Fix nvidia-smi command not found inside a Docker container

A container normally gets nvidia-smi from the host when it starts, not from its image. NVIDIA's container toolkit documentation says the NVIDIA_DRIVER_CAPABILITIES variable controls which driver libraries and binaries are mounted inside the container, that the utility capability is the one required for nvidia-smi and NVML, and that with NVIDIA_VISIBLE_DEVICES unset the runtime behaves like runc and exposes neither GPUs nor capabilities. So a container started without the GPU has no nvidia-smi. Docker's GPU documentation gives the flag that fixes it:

sudo docker run --rm --gpus all ubuntu nvidia-smi

If that prints the same table as the VM, the GPU reached the container. If Docker refuses with could not select device driver "" with capabilities: [[gpu]], the toolkit is not set up, and the container toolkit guide has the install and the Docker restart. If the container starts and nvidia-smi is still missing, an image or a command line may have set the capabilities variable without utility. NVIDIA says the variable replaces the default capabilities, which are utility and compute, instead of adding to them, so list both, as its documentation does:

sudo docker run --rm --gpus 'all,"capabilities=compute,utility"' ubuntu nvidia-smi

On an app template the container is deploygpu-workload, which DeployGPU starts with --gpus all, so run nvidia-smi on the VM to see the GPU. A missing nvidia-smi inside a container is not proof that the GPU is missing.

Through sudo or as root

The sudoers manual says that when secure_path is set, sudo uses it in place of your own PATH. A program in a directory that your shell searches and sudo does not is found without sudo and missing with it. Print the location and call it by its full path:

command -v nvidia-smi
sudo "$(command -v nvidia-smi)"

This is the usual story on WSL, where NVIDIA's CUDA on WSL guide says the root user, outside containers, will not find nvidia-smi at the expected location and tells you to use /usr/lib/wsl/lib/nvidia-smi or to add /usr/lib/wsl/lib/ to the PATH. The same guide says the Windows driver is stubbed into WSL, so you must not install a Linux driver there.

The image has no NVIDIA driver

If lspci lists an NVIDIA device and dpkg -l shows no NVIDIA packages, the image shipped without a driver. The deploy page pre-selects an OS image with CUDA and Docker, and an API call that leaves out os_image_id gets the provider's default image, which can be a different one. The public GET /api/v1/providers/{provider}/images endpoint lists what a provider offers.

If the packages are there and only the program is missing, the utilities package may be the missing piece. Ubuntu's server documentation installs a server driver with sudo ubuntu-drivers install --gpgpu and adds nvidia-utils-NNN-server as an additional component, and the package's file list on packages.ubuntu.com includes /usr/bin/nvidia-smi. The drivers guide covers choosing the branch. NVIDIA says the system must be rebooted after a driver installation to load the new kernel modules, so read the box first.

If nothing on the VM is worth keeping, relaunching on the pre-selected image is simpler than installing a driver. Stopping refunds the unused seconds of the current hour and deletes the disk, as the stop guide explains.

nvidia-smi not working when the command is found

When the command exists and prints an error instead of a table, the cause is no longer the shell. Each message has its own page:

Once it prints, the monitoring guide covers watching the GPU while a job runs.

When to contact support

Email support@deploygpu.ai if lspci lists fewer NVIDIA devices than the offer has GPUs, or if a VM launched from the dashboard's pre-selected image has no driver. Send the output of the five commands above, the provider and the deployment ID. The contact page is the other way in, and the first five minutes guide lists the checks for a new VM.