Skip to content

docker image requires nvcc to run plugin #1491

Closed
Closed
docker image requires nvcc to run plugin#1491
Labels
bugSomething isn't working

Description

@rustyscottweber
rustyscottweber
opened on Apr 16, 2026

Which version of recognize are you using?

11.01

Enabled Modes

Object recognition, Face recognition, Video recognition

TensorFlow mode

GPU mode

Downstream App

Photos App

Which Nextcloud version do you have installed?

33.01

Which Operating system do you have installed?

docker

Which database are you running Nextcloud on?

postgresql

Which Docker container are you using to run Nextcloud? (if applicable)

Stock docker container from truenas

How much RAM does your server have?

64 GiB

What processor Architecture does your CPU have?

X86_64

Describe the Bug

Attempting to run recognize in the stock docker image for truenas results in the docker image not having everything it needs to run. Looking at the configuration for the app in nextcloud:

 Successfully loaded libtensorflow in Node.js, but couldn't load GPU. Make sure CUDA Toolkit and cuDNN are installed and accessible, or turn off GPU mode.

If the shipped Node.js binary doesn't work on your system for some reason you can set the path to a custom node.js binary. Currently supported is Node v20.9 and newer v20 releases.

The GPU is detected and the driver is loaded as determined by nvidia-smi. However, I'm curious as to what additional packages need to be installed in order to ensure that recognize will work properly.

Expected Behavior

recognize will work without needing additional intervention of creating a custom docker image.

To Reproduce

install the plugin on truenas docker with an nvidia GPU.

Debug log

No response

Activity

  1. rustyscottweber
    added
    bugSomething isn't working
    on Apr 16, 2026

  2. rustyscottweber commented on Apr 16, 2026

    @rustyscottweber
    rustyscottweber
    on Apr 16, 2026
    Author

    Linking to the ticket on the truenas project.
    truenas/apps#4709 (comment)

  3. marcelklehr commented on Apr 21, 2026

    @marcelklehr
    marcelklehr
    on Apr 21, 2026
    Member

    Hello,

    thank you for raising this issue! Could you point to the Docker image that you are using?

    Note that while you are using x86 64-bit your CPU may not have support for AVX instructions, or your system in docker may not have glibc (usually the norm on Linux; FreeBSD, Alpine linux and thus also Nextcloud AIO are not such systems).

  4. FVotherego commented on May 11, 2026

    @FVotherego
    FVotherego
    on May 11, 2026

    I have the same problem, i use the https://github.com/trueforge-org/containerforge/blob/main/apps/nextcloud-fpm that add some little customization to https://github.com/nextcloud/docker/blob/f73ce56e0d64bf1ddea74cd60cb3914eeb808440/32/fpm/Dockerfile the nextcloud-fpm image. My pod in which nextcloud run use a runtime provided by https://github.com/nvidia/k8s-device-plugin . It seems that the app need the Nvidia developer toolkit. specifically the nvidia-smi command works in the nextcloud pod and is present between the others the libcuda.so library. the test_gputensorflow.js needs libraries like libcudart,so or libcudnn.so that are not present. I don't know if it would be useful it that is the issue, to add these requirements somewhere, so that how create the docker image can add the dependency to support fully recognize. I am not an expert in neither nextcloud nor cuda so i don't know if i tracked the issue correctly

  5. FVotherego commented on May 11, 2026

    @FVotherego
    FVotherego
    on May 11, 2026

    Linking to the ticket on the truenas project. truenas/apps#4709 (comment)

    in particular who extends the nextcloud official image say that he need to know the requirements. I think that should exist a CUDA image (maybe https://hub.docker.com/r/nvidia/cuda) that provide all these missing libraries

  6. marcelklehr
    added this to Recognizeon May 13, 2026
  7. marcelklehr
    moved this to Triaging in Recognizeon May 13, 2026

  8. rustyscottweber commented on Jul 7, 2026

    @rustyscottweber
    rustyscottweber
    on Jul 7, 2026
    Author

    Looking at the source code further, I can see that the message has been updated in the latest unreleased version. It looks like the docker version is missing the cuda runtime libraries.

    Running a test script seems to support this notion.

    root@f9711481abd6:/var/www/html/custom_apps/recognize# ./bin/node -e "const tf=require('@tensorflow/tfjs-node-gpu'); console.log(tf.getBackend())"
Platform node has already been set. Overwriting the platform with node.
2026-07-07 14:43:58.105270: W tensorflow/stream_executor/platform/default/dso_loader.cc:64] Could not load dynamic library 'libcudart.so.11.0'; dlerror: libcudart.so.11.0: cannot open shared object file: No such file or directory
2026-07-07 14:43:58.105480: I tensorflow/stream_executor/cuda/cudart_stub.cc:29] Ignore above cudart dlerror if you do not have a GPU set up on your machine.
2026-07-07 14:43:58.557600: I tensorflow/core/platform/cpu_feature_guard.cc:193] This TensorFlow binary is optimized with oneAPI Deep Neural Network Library (oneDNN) to use the following CPU instructions in performance-critical operations:  AVX2 AVX512F FMA
To enable them in other operations, rebuild TensorFlow with the appropriate compiler flags.
2026-07-07 14:43:58.579704: W tensorflow/stream_executor/platform/default/dso_loader.cc:64] Could not load dynamic library 'libcudart.so.11.0'; dlerror: libcudart.so.11.0: cannot open shared object file: No such file or directory
2026-07-07 14:43:58.580083: W tensorflow/stream_executor/platform/default/dso_loader.cc:64] Could not load dynamic library 'libcublas.so.11'; dlerror: libcublas.so.11: cannot open shared object file: No such file or directory
2026-07-07 14:43:58.580363: W tensorflow/stream_executor/platform/default/dso_loader.cc:64] Could not load dynamic library 'libcublasLt.so.11'; dlerror: libcublasLt.so.11: cannot open shared object file: No such file or directory
2026-07-07 14:43:58.580611: W tensorflow/stream_executor/platform/default/dso_loader.cc:64] Could not load dynamic library 'libcufft.so.10'; dlerror: libcufft.so.10: cannot open shared object file: No such file or directory
2026-07-07 14:43:58.580874: W tensorflow/stream_executor/platform/default/dso_loader.cc:64] Could not load dynamic library 'libcurand.so.10'; dlerror: libcurand.so.10: cannot open shared object file: No such file or directory
2026-07-07 14:43:58.581113: W tensorflow/stream_executor/platform/default/dso_loader.cc:64] Could not load dynamic library 'libcusolver.so.11'; dlerror: libcusolver.so.11: cannot open shared object file: No such file or directory
2026-07-07 14:43:58.581348: W tensorflow/stream_executor/platform/default/dso_loader.cc:64] Could not load dynamic library 'libcusparse.so.11'; dlerror: libcusparse.so.11: cannot open shared object file: No such file or directory
2026-07-07 14:43:58.581585: W tensorflow/stream_executor/platform/default/dso_loader.cc:64] Could not load dynamic library 'libcudnn.so.8'; dlerror: libcudnn.so.8: cannot open shared object file: No such file or directory
2026-07-07 14:43:58.581633: W tensorflow/core/common_runtime/gpu/gpu_device.cc:1850] Cannot dlopen some GPU libraries. Please make sure the missing libraries mentioned above are installed properly if you would like to use GPU. Follow the guide at https://www.tensorflow.org/install/gpu for how to download and setup the required libraries for your platform.
Skipping registering GPU devices...
tensorflow

    The docker image that nextcloud uses has no cuda runtime libaries. We, have access to cuda 12.4 in the driver, but no runtime binaries for any version of cuda. We don't need nvcc necessarily, but the cuda runtimes could be VERY helpful.

  9. rustyscottweber commented on Jul 7, 2026

    @rustyscottweber
    rustyscottweber
    on Jul 7, 2026
    Author

    Looks like we might be able to work around the issue by making a custom image of the nextcloud docker.
    Per the AI:

      Method 1: The Modern Dockerfile Approach (Cleanest & Most Portable)
  If you want to build and tag a self-contained image, the most elegant and fastest way is using a multi-stage build. Instead of managing APT keys, source lists, and network downloads, you
  can copy the pre-compiled Debian 12 libraries directly from the official nvidia/cuda image into your Nextcloud image.

   1. Create a Dockerfile:

   1    # Start from the exact Nextcloud image used in your deployment
   2    FROM nextcloud:33.0.0
   3
   4    # Multi-stage copy CUDA 11.x & cuDNN 8.x runtimes from the official NVIDIA image
   5    COPY --from=nvidia/cuda:11.8.0-cudnn8-runtime-debian12 /usr/local/cuda/ /usr/local/cuda/
   6    COPY --from=nvidia/cuda:11.8.0-cudnn8-runtime-debian12 /usr/lib/x86_64-linux-gnu/libcudnn* /usr/lib/x86_64-linux-gnu/
   7
   8    # Inject the LD_LIBRARY_PATH directly so it's active by default
   9    ENV LD_LIBRARY_PATH=/usr/local/cuda/lib64:/usr/lib/x86_64-linux-gnu

   2. Build and tag your custom image:

   1    docker build -t my-registry/nextcloud:33.0.0-cuda .

   3. Deploy it:
      * In Docker Compose: Swap image: nextcloud:33.0.0 with image: my-registry/nextcloud:33.0.0-cuda.
      * In TrueNAS SCALE: Push this to a public or private registry, and edit 2.3.12/ix_values.yaml to point the app to your custom image repo:

   1      images:
   2        image:
   3          repository: my-registry/nextcloud
   4          tag: 33.0.0-cuda

    However, maybe this should be pushed down to the base image layer instead of being a custom mod.

  10. szaimen commented on Aug 28, 2026

    @szaimen
    szaimen
    on Aug 28, 2026
    Contributor

    I guess this is also done now with #1500

  11. rustyscottweber commented on Aug 28, 2026

    @rustyscottweber
    rustyscottweber
    on Aug 28, 2026
    Author

    Does #1500 eliminate the need for the nvidia cuda run time?

  12. marcelklehr commented on Sep 2, 2026

    @marcelklehr
    marcelklehr
    on Sep 2, 2026
    Member

    Yes, with #1500 there is a new recognize_backend exapp, packaged using docker that already comes with the nvidia runtime out of the box. Starting with v13 of recognize, you can now choose whether you want processing to happen the old way or in the new backend.

  13. marcelklehr
    closed this as completedon Sep 2, 2026
  14. github-project-automation
    moved this from Triaging to Done in Recognizeon Sep 2, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    bugSomething isn't working

    Type

    No type

    Projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions