CUDA works on Windows but not inside WSL2

nvidia-smi works in PowerShell, fails in Ubuntu

Written by Jakub Rusinowski

The error

NVIDIA-SMI has failed because it couldn't communicate with the NVIDIA driver. Make sure that the latest NVIDIA driver is installed and running.

/sbin/ldconfig.real: /usr/lib/wsl/lib/libcuda.so.1 is not a symbolic link

>>> torch.cuda.is_available()
False

1. 1

   Remove any NVIDIA Linux driver you installed inside the distro

   Do this first, before installing anything else. If dpkg -l | grep nvidia lists driver packages — nvidia-driver-*, libnvidia-*, nvidia-dkms-* — inside WSL, they are the problem. Purging them lets the host projection take over again on the next restart. A .run installer needs its own uninstaller (sudo /usr/bin/nvidia-uninstall) instead.

   Careful: This removes packages from the WSL distro only. It does not touch your Windows driver, your GPU, or anything outside WSL — but read the list apt prints before you confirm it.

   bashCopy

   # bash, inside WSL — see what is installed
   dpkg -l | grep -i nvidia
   
   # Purge Linux driver packages (NOT the CUDA toolkit)
   sudo apt-get purge -y "nvidia-driver-*" "libnvidia-*" "nvidia-dkms-*"
   sudo apt-get autoremove -y

   Did it work?Run wsl --shutdown in PowerShell, reopen the distro, and check the projection is intact. The library should be present under /usr/lib/wsl/lib.

   bashCopy

   ls -l /usr/lib/wsl/lib/libcuda.so*
   /usr/lib/wsl/lib/nvidia-smi

2. 2

   Install only the WSL-Ubuntu CUDA toolkit variant

   The CUDA toolkit and the display driver are separate things, and inside WSL you want the toolkit without the driver. NVIDIA publishes a WSL-Ubuntu package variant that deliberately excludes it. Choose that one from the CUDA downloads page, and do not select the cuda, cuda-13-x or cuda-drivers meta-packages — those pull the Linux driver back in and put you straight back where you started. If nvidia-smi is not on your PATH after this, it lives at /usr/lib/wsl/lib/nvidia-smi.

   bashCopy

   # bash, inside WSL — install the toolkit ONLY, never the driver meta-packages
   sudo apt-get install -y cuda-toolkit-13-0
   
   # NOT these:
   #   sudo apt-get install cuda
   #   sudo apt-get install cuda-drivers

   Did it work?The compiler reports a version and the runtime sees the device. If nvcc works but nvidia-smi does not, you still have a driver problem, not a toolkit problem.

   bashCopy

   nvcc --version
   /usr/lib/wsl/lib/nvidia-smi
   python3 -c "import torch; print(torch.cuda.is_available())"

3. 3

   Restart the whole WSL VM before you debug anything else

   wsl --shutdown is the cheapest fix on this page and it resolves a real class of failure: the WSL VM holds its projection of the host driver from when it started, so a Windows driver update installed under a running distro leaves the VM with a stale one. Closing the terminal window does not do this — the VM keeps running in the background for several seconds after and often longer.

   PowerShellCopy

   # PowerShell, on the Windows side
   wsl --shutdown
   wsl --status
   
   # then reopen your distro

   Did it work?Inside the freshly started distro, nvidia-smi should print the same GPU and driver version you see in PowerShell.

   bashCopy

   nvidia-smi --query-gpu=name,driver_version --format=csv

4. 4

   Check the platform floor — Windows build, WSL kernel, and GPU generation

   GPU passthrough needs Windows 11 or Windows 10 build 19043 or newer, and a WSL kernel of at least 4.19.121 — 5.10.16.3 or newer is what you actually want. Maxwell-generation cards are not supported under WSL, and Pascal or newer is the practical requirement, which is a stricter bar than native Windows. wsl.exe --update pulls the current kernel.

   PowerShellCopy

   # PowerShell
   winver                 # Windows version and build
   wsl.exe --update
   wsl cat /proc/version  # the WSL kernel version

5. 5

   Fix the libcuda symlink warning without editing the read-only projection

   /usr/lib/wsl/lib is a read-only projection of the Windows driver, so the is not a symbolic link warning cannot be fixed in place — and trying is how people break a working setup. The safe form is to copy the libraries somewhere writable, recreate the symlinks there, and put that directory ahead of the WSL path in the loader config. Note that this is cosmetic for most workloads: the warning is harmless unless a loader you use actually follows the symlink.

   Careful: A wsl --shutdown resets the projection at /usr/lib/wsl/lib, not your copy — so after a Windows driver update your copied libraries are stale and must be recreated, or you will be running against an old libcuda.

   bashCopy

   # bash, inside WSL
   sudo mkdir -p /usr/lib/wsl/drivers-copy
   sudo cp /usr/lib/wsl/lib/libcuda.so.1.1 /usr/lib/wsl/drivers-copy/
   sudo ln -sf /usr/lib/wsl/drivers-copy/libcuda.so.1.1 /usr/lib/wsl/drivers-copy/libcuda.so.1
   sudo ln -sf /usr/lib/wsl/drivers-copy/libcuda.so.1   /usr/lib/wsl/drivers-copy/libcuda.so
   echo "/usr/lib/wsl/drivers-copy" | sudo tee /etc/ld.so.conf.d/000-wsl-cuda.conf
   sudo ldconfig

   Did it work?The warning should be gone from the next sudo ldconfig run, and the loader should resolve libcuda to your copy.

   bashCopy

   sudo ldconfig 2>&1 | grep -i libcuda || echo "no libcuda warnings"
   ldconfig -p | grep libcuda

6. 6

   Consider whether you need WSL at allMost common fix

   Worth saying plainly, because a lot of guides imply otherwise: for a single-GPU machine running Ollama or LM Studio, native Windows is simpler and about as fast. WSL earns its keep when you need a Linux toolchain — vLLM, a CUDA build, a Python stack that fights you on Windows. It costs you Unified Memory, which is not available under WSL, and pinned system memory, which is limited there. If you came to WSL only because a tutorial used bash, running natively removes this entire page from your life. Size the model to your card and you are done.

   Check what fits your hardwarecheck which models fit your card before you spend an evening on driver plumbingOpen the VRAM checker →