Optix 7.7 in WSL + Docker works with sudo but not as default user

[kappi.patterson]

Hi there,

I’m using a windows machine and trying to develop in wsl via my company’s docker-contained environment. All this is required by the company so I can’t change development setup.

I spent a while setting up the container to work with WSL and can successfully run glxgears, rviz, gazebo etc as the default (non root) user using the NVIDIA GPU.

However, trying to run the application I need to, which uses Optix 7.7, works just fine if I run with sudo, but if I run with the default non-root user it gives me:
what(): Optix call (optixInit()) failed with code 7805 (line 340): OPTIX_ERROR_ENTRY_SYMBOL_NOT_FOUND, Entry symbol not found

I find this odd, as there is only one instance of libnvoptix.so.1, and clearly the command is finding it, and the symbol it’s searching for is definitely present:

$ sudo find / -type f -name "libnvoptix.so.1" 2>/dev/null
/usr/lib/wsl/lib/libnvoptix.so.1
$  nm -D /usr/lib/wsl/lib/libnvoptix.so.1 | grep -i optixQueryFunctionTable
0000000000003c60 T optixQueryFunctionTable

my $LD_LIBRARY_PATH is identical between the root and default user.

Running with sudo is a real pain as I’m using ROS2. I am hoping you have some advice on how to debug this, because it seems like it should be solvable.

Maybe relevant is that I initially had to run glxgears with sudo as well, but the combination of the flags below fixed it and allowed me to run as default:

Docker flags:

    GRAPHICS_SETTINGT+=" -e LIBGL_ALWAYS_INDIRECT=0 "
    GRAPHICS_SETTINGS+=" --volume /usr/lib/wsl:/usr/lib/wsl "
    GRAPHICS_SETTINGS+=" -e LD_LIBRARY_PATH=/usr/lib/wsl/lib "
    GRAPHICS_SETTINGS+=" -e 
 MESA_D3D12_DEFAULT_ADAPTER_NAME=NVIDIA "

Container flags:

        unset __NV_PRIME_RENDER_OFFLOAD
        unset __GLX_VENDOR_LIBRARY_NAME

Thank you very much in advance

nvidia-smi (in the container and just in wsl):

Tue Mar 18 10:08:45 2025       
+-----------------------------------------------------------------------------------------+
| NVIDIA-SMI 570.124.03             Driver Version: 572.60         CUDA Version: 12.8     |
|-----------------------------------------+------------------------+----------------------+
| GPU  Name                 Persistence-M | Bus-Id          Disp.A | Volatile Uncorr. ECC |
| Fan  Temp   Perf          Pwr:Usage/Cap |           Memory-Usage | GPU-Util  Compute M. |
|                                         |                        |               MIG M. |
|=========================================+========================+======================|
|   0  NVIDIA RTX 4000 Ada Gene...    On  |   00000000:01:00.0  On |                  Off |
| N/A   48C    P8              8W /  105W |     736MiB /  12282MiB |      0%      Default |
|                                         |                        |                  N/A |
+-----------------------------------------+------------------------+----------------------+
                                                                                         
+-----------------------------------------------------------------------------------------+
| Processes:                                                                              |
|  GPU   GI   CI              PID   Type   Process name                        GPU Memory |
|        ID   ID                                                               Usage      |
|=========================================================================================|
|  No running processes found                                                             |
+-----------------------------------------------------------------------------------------+

[dhart]

Hi @kappi.patterson,

So if I understand correctly, when you run an OptiX application as sudo it works, but you get the symbol error when running without root access?

I’m just speculating, but this tends to indicate a permissions problem, perhaps. Does your find command also require sudo? Maybe the first thing to check is output from strace when running without root access… maybe you will see a failure to open one of the driver libraries. If failures are hard to spot, you might capture strace logs in both cases (with and without sudo) and try to diff them, which might require some clever sorting or filtering to avoid getting too much noise.

Do CUDA samples run in your environment without sudo? Are you using NVIDIA_DRIVER_CAPABILITIES=all?

–
David.

[kappi.patterson]

Hi @dhart ,
Thanks very much for getting back to me. Your understanding is correct, the application runs as sudo but not without root access.

NVIDIA_DRIVER_CAPABILITIES=all doesn’t help unfortunately, though I was running with compute,utility,graphics previously.

The find command does not require sudo, it still finds the file and symbol fine without.

I will try to capture some strace logs, and if you think of anything else that could be causing this I’d be really grateful, I really can’t find anything that differs between the root and non root users that seems like it could cause this.

Thank you

[kappi.patterson]

Hi again

Just to report back on this, the issue was my find command: by filtering for type -f I inadvertently missed the libnvoptix.so.1 symlink in /usr/lib/x86_64-linux-gnu, so there were actually two libnvoptix.so.1 files.

sudo commands were reading the /usr/lib/x86_64-linux-gnu one, whereas default user commands were trying to use /usr/lib/wsl/lib/libnvoptix.so.1, which was just a stub. strace showed this difference, for those curious:

sudo strace -f -e trace=file -o strace.sudo.log {MY_COMMAND}
strace -f -e trace=file -o strace.nosudo.log {MY_COMMAND}
diff -u <(grep -i libnvoptix strace.sudo.log) <(grep -i libnvoptix strace.nosudo.log)

The diff showed:

-18836 openat(AT_FDCWD, "/lib/x86_64-linux-gnu/libnvoptix.so.1", O_RDONLY|O_CLOEXEC) = 18

vs

+19024 openat(AT_FDCWD, "/usr/lib/wsl/lib/libnvoptix.so.1", O_RDONLY|O_CLOEXEC) = 18

I fixed it by copying across the library from /usr/lib/x86_64-linux-gnu/libnvoptix.so.570.144 to /usr/lib/wsl/lib/ and renaming it to /libnvoptix.so.1, which is part of the instructions in the workaround forum post for Optix here.

I had previously tried that workaround without success, I think probably because of not properly matching the windows driver version to a compatible linux driver version, but I’m guessing. In the workaround instructions it doesn’t detail which Linux driver to use for your chosen windows driver, which may be helpful to add.

So I ended up installing the Linux driver in WSL on top of the Windows driver, which is what “worked” and gave my sudo commands access to Optix. I chose a Linux driver in the same family (560) to my Windows one and it seems to be compatible, though I may have broken other things I don’t know about yet.