Could not execute the Node.js binary. You may need to set the path to a working binary manually.

[retiolus]

Which version of recognize are you using?

6.1.1

Enabled Modes

Object recognition, Face recognition

TensorFlow mode

WASM mode

Downstream App

Memories App

Which Nextcloud version do you have installed?

28.0.5

Which Operating system do you have installed?

Debian 11

Which database are you running Nextcloud on?

mysql 10.5.23

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

No response

How much RAM does your server have?

4GiB

What processor Architecture does your CPU have?

aarch64

Describe the Bug

I updated from Nextcloud 27 to Nextcloud 28 and now I get this error. Node is located in /var/www/nextcloud/apps/recognize/bin/node so I guess it is automatically installed be Recognize.

root@home:/var/www/nextcloud/apps/recognize/bin# ./node --version
v14.18.2

I installed manually Node executable and changed to it, but I get the same error.

Expected Behavior

Node should work?

To Reproduce

...

Debug log

No response

[github-actions[bot]]

Hello :wave:

Thank you for taking the time to open this issue with recognize. I know it's frustrating when software causes problems. You have made the right choice to come here and open an issue to make sure your problem gets looked at and if possible solved. I try to answer all issues and if possible fix all bugs here, but it sometimes takes a while until I get to it. Until then, please be patient. Note also that GitHub is a place where people meet to make software better together. Nobody here is under any obligation to help you, solve your problems or deliver on any expectations or demands you may have, but if enough people come together we can collaborate to make this software better. For everyone. Thus, if you can, you could also look at other issues to see whether you can help other people with your knowledge and experience. If you have coding experience it would also be awesome if you could step up to dive into the code and try to fix the odd bug yourself. Everyone will be thankful for extra helping hands! One last word: If you feel, at any point, like you need to vent, this is not the place for it; you can go to the forum, to twitter or somewhere else. But this is a technical issue tracker, so please make sure to focus on the tech and keep your opinions to yourself. (Also see our Code of Conduct. Really.)

I look forward to working with you on this issue Cheers :blue_heart:

[marcelklehr]

Is there anything in the nextcloud logs?

[nyok92]

Recognize & Node used to work correctly before. Same issue by updating to the last version of recognize : 7.0.0 Now Node path is : /data/config/www/nextcloud/apps/recognize/bin/node There is indeed a node in this path but it seems not working.

[marcelklehr]

You need node.js v20 since recognize v7 can you check the node binary?

[marcelklehr]

You may need to install your own version of node.js

[nyok92]

Directly on my host, it seems the node binary installed by the Recognizez app is working (v20.9.0)

rock@rock-5b-blue:/usr/share/hassio/addons/data/db21ed7f_nextcloud_ocr/config/www/nextcloud/apps/recognize/bin$ ./node -v
v20.9.0

In my Nextcloud container,

root@db21ed7f-nextcloud-ocr:/data/config/www/nextcloud/apps/recognize/bin# ./node -v
Error relocating /data/config/www/nextcloud/apps/recognize/bin/node: fcntl64: symbol not found

Donwloaded the last prebuit binaries LTS node version 20.13.1 in my container : same issue

[nyok92]

Solved by installing nodejs through the docker ENV : https://github.com/alexbelgium/hassio-addons/tree/master/nextcloud

Added nodejs,npm as additionnal apps

[retiolus]

Hi, in my case, the node executable was not executable... chmod +x fixed the problem

[varosengineer]

Solved by installing nodejs through the docker ENV : https://github.com/alexbelgium/hassio-addons/tree/master/nextcloud

Added nodejs,npm as additionnal apps

Hi, can you elaborate on this answer? I'm facing the same problem, I don't know if your solution can be valid for my machine.

Thanks in advance.

[Hopp0]

I've a similar problem with Nextcloud Hub 8 29.0.2 installed via snap. In my case the problem seems to be that recognize installs the pie version of node. "file node" outputs ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib/ld-musl-x86_64.so.1, with debug_info, not stripped and it's running on a standard x86_64 Ubuntu server. occ maintenance:repair reinstalls the same thing. If I manually download node and replace the node binary (so I can run it OK manually) the nextcloud admin settings for recognize still says "Could not execute the Node.js binary."

How does the install work out which architecture to use when downloading node? If I use the admin page for recognize to point it at the version of node in an old snap (not the "current" one) it does work, but that's running Node.js v14.18.2.

[marcelklehr]

@Hopp0 I think your problem is not that it's a pie executable but that it's linked to musl instead of glibc.

If I manually download node and replace the node binary (so I can run it OK manually) the nextcloud admin settings for recognize still says "Could not execute the Node.js binary."

Can you elaborate on the steps you do for this so I can see what might be going wrong there?

[Hopp0]

@Hopp0 I think your problem is not that it's a pie executable but that it's linked to musl instead of glibc.

If I manually download node and replace the node binary (so I can run it OK manually) the nextcloud admin settings for recognize still says "Could not execute the Node.js binary."

Can you elaborate on the steps you do for this so I can see what might be going wrong there?

OK, I'm running on Ubuntu 24.04 LTS nextcloud installed using snap

$ snap list nextcloud
Name       Version      Rev    Tracking       Publisher   Notes
nextcloud  29.0.2snap1  42890  latest/stable  nextcloud✓  -

If I uninstall recognize and the add it back (using the "+ Apps" menu) it adds version 7.0.0. and /var/snap/nextcloud/current/nextcloud/extra-apps/recognize/bin is empty.

I can then go into the Administration Settings for recognize it says: The machine learning models still need to be downloaded. Could not execute the Node.js binary. You may need to set the path to a working binary manually.

If I run nextcloud.occ recognize:download-models it fixes the first, but still no node binary, so I can run: nextcloud.occ maintenance:repair

The output includes:

 - Install recognize dependencies
     - WARNING: Failed to install node binary
     - WARNING: Failed to automatically install dependencies for recognize. Check the recognize admin panel for potential problems.

and I get log entries which say:

[recognize] Error: Failed to install Tensorflow.js: sh: 1: /var/snap/nextcloud/current/nextcloud/extra-apps/recognize/bin/node: not found and

 Exception Failed to install Tensorflow.js: sh: 1: /var/snap/nextcloud/current/nextcloud/extra-apps/recognize/bin/node: not found
Failed to automatically install dependencies for recognize. Check the recognize admin panel for potential problems. 

/var/snap/nextcloud/current/nextcloud/extra-apps/recognize/bin# ls -l
total 143424
-rwxr-xr-x 1 root root 99490840 Jun 24 23:19 node
-rw-r--r-- 1 root root 47364724 Jun 24 23:19 x64.tar.gz
/var/snap/nextcloud/current/nextcloud/extra-apps/recognize/bin# file node
node: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib/ld-musl-x86_64.so.1, with debug_info, not stripped
/var/snap/nextcloud/current/nextcloud/extra-apps/recognize/bin# ./node
bash: ./node: cannot execute: required file not found
/var/snap/nextcloud/current/nextcloud/extra-apps/recognize/bin# ldd node
	linux-vdso.so.1 (0x00007ffc0eaee000)
	libstdc++.so.6 => /lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007fd7da800000)
	libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007fd7e01c1000)
	libc.musl-x86_64.so.1 => not found
	libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007fd7e00d8000)
	libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fd7da400000)
	/lib/ld-musl-x86_64.so.1 => /lib64/ld-linux-x86-64.so.2 (0x00007fd7e0205000)

Looks like the missing library is actually in /lib/x86_64-linux-musl/libc.so

And for reference, the previous version had:

file /var/snap/nextcloud/42563/nextcloud/extra-apps/recognize/bin/node 
/var/snap/nextcloud/42563/nextcloud/extra-apps/recognize/bin/node: ELF 64-bit LSB executable, x86-64, version 1 (GNU/Linux), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 2.6.32, BuildID[sha1]=3d052a3d1391f7d7e13f3b9f33f7ebc1dd4ff449, with debug_info, not stripped

Any ideas welcome! Thanks.

[marcelklehr]

@Hopp0 It seems that it assumes you are running on a musl system and then downloads an executable that doesn't work on your system. You should be able to download a working node.js binary from nodejs.org and point recognize to it.

[mr-bryn]

I am also running Nextcoud snap in an x86_64 VM and have run into exactly the same issue as @Hopp0

I added some debug lines to lib/Migration/InstallDeps.php within the installNodeBinary function - this appears to be what controls the version of node.js downloaded.

My machine is correctly detected as x86_64 (line 118), however the call to the testBinary function on line 122 returns null, hence the code then installs the musl version.

I don't have time right now, but might be worth debugging the testBinary function from line 163 on.

[Hopp0]

OK, Thanks @mr-bryn,

Progress so far is: It looks like installNodeBinary for x86_64 is set to try to download the 'Official' node and if testBinary fails it downloads the 'Unofficial' one linked with musl. I've currently commented that bit out as I want the Official node really.

testBinary tries to run node - in my case: /var/snap/nextcloud/42890/nextcloud/extra-apps/recognize/bin/node '--version' and that results in return code = 1 and the command output being: /var/snap/nextcloud/42890/nextcloud/extra-apps/recognize/bin/node: /lib/x86_64-linux-gnu/libc.so.6: version 'GLIBC_2.28' not found (required by /var/snap/nextcloud/42890/nextcloud/extra-apps/recognize/bin/node)

I can run that command on the Ubuntu command line and it works fine and ldd shows all the libraries are present:

$ ldd ../../bin/node 
	linux-vdso.so.1 (0x00007ffc5d3d9000)
	libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x0000780d1f34d000)
	libstdc++.so.6 => /lib/x86_64-linux-gnu/libstdc++.so.6 (0x0000780d1f000000)
	libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x0000780d1ef17000)
	libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x0000780d1f320000)
	libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x0000780d1f31b000)
	libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x0000780d1ec00000)
	/lib64/ld-linux-x86-64.so.2 (0x0000780d1f369000)

I'm guessing that the snap that is running nextcloud doesn't have the right version...

[Hopp0]

After some trial and error I just tried going back to node version v16.20.2, which seems new enough that TensorFlow will install and old enough that the glibc library is in the snap image.

"Checking libtensorflow" is still spinning though, so it may not be happy with that version of node... :(

[mr-bryn]

@Hopp0 do you have a link to the node version that worked for you so I can test it later?

[Hopp0]

@Hopp0 do you have a link to the node version that worked for you so I can test it later?

I changed line 37 of InstallDeps.php to say: public const NODE_VERSION = 'v16.20.2'; and re-ran nextcloud.occ maintenance:repair which ran through without errors: As I added to my previous post, I'm not sure it's actually working. "Checking libtensorflow" is still spinning though, so it may not be happy with that version of node.

[mr-bryn]

Exactly the same results here trying to use node v20. It works fine from the shell.

I opened a shell within the snap environment snap run --shell nextcloud.php-fpm

When I try to run node -v I also get the message /lib/x86_64-linux-gnu/libc.so.6: version 'GLIBC_2.28' not found

[varosengineer]

In my case I have an Asustor AS3302T, and these are the differences between the node in the machine and the one in nextcloud docker container:

Paths

/volume1/Docker/nextcloud/config/www/nextcloud/apps/recognize/bin/node /opt/bin/node

Check version

./node: /lib/libc.so.6: version `GLIBC_2.28' not found (required by ./node) v18.18.2

ldd command

ldd ./node
./node: /lib/libc.so.6: version `GLIBC_2.28' not found (required by ./node)
        linux-vdso.so.1 (0x0000007f7f0d2000)
        libdl.so.2 => /lib/libdl.so.2 (0x0000007f7f093000)
        libstdc++.so.6 => /lib/libstdc++.so.6 (0x0000007f7ef38000)
        libm.so.6 => /lib/libm.so.6 (0x0000007f7ee80000)
        libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x0000007f7ee5e000)
        libpthread.so.0 => /lib/libpthread.so.0 (0x0000007f7ee32000)
        libc.so.6 => /lib/libc.so.6 (0x0000007f7ecde000)
        /lib/ld-linux-aarch64.so.1 (0x0000007f7f0a6000)

ldd /opt/bin/node
        linux-vdso.so.1 (0x0000007f7c72a000)
        libz.so.1 => /opt/lib/libz.so.1 (0x0000007f7c6d8000)
        libuv.so.1 => /opt/lib/libuv.so.1 (0x0000007f7c699000)
        libcares.so.2 => /opt/lib/libcares.so.2 (0x0000007f7c671000)
        libnghttp2.so.14 => /opt/lib/libnghttp2.so.14 (0x0000007f7c631000)
        libcrypto.so.3 => /opt/lib/libcrypto.so.3 (0x0000007f7c1d7000)
        libssl.so.3 => /opt/lib/libssl.so.3 (0x0000007f7c115000)
        libdl.so.2 => /opt/lib/libdl.so.2 (0x0000007f7c101000)
        libstdc++.so.6 => /opt/lib/libstdc++.so.6 (0x0000007f7bf55000)
        libm.so.6 => /opt/lib/libm.so.6 (0x0000007f7be91000)
        libgcc_s.so.1 => /opt/lib/libgcc_s.so.1 (0x0000007f7be6c000)
        libpthread.so.0 => /opt/lib/libpthread.so.0 (0x0000007f7be3e000)
        libc.so.6 => /opt/lib/libc.so.6 (0x0000007f7bcce000)
        /opt/lib/ld-linux-aarch64.so.1 => /lib/ld-linux-aarch64.so.1 (0x0000007f7c6fe000)
        librt.so.1 => /opt/lib/librt.so.1 (0x0000007f7bcb6000)

file command:

file ./node
./node: ELF 64-bit LSB executable, ARM aarch64, version 1 (GNU/Linux), dynamically linked, interpreter /lib/ld-linux-aarch64.so.1, BuildID[sha1]=61f7f37c7b1f413bf8d216abebdfa7ef189f1e9c, for GNU/Linux 3.7.0, with debug_info, not stripped, too many notes (256)

file /opt/bin/node
/opt/bin/node: ELF 64-bit LSB executable, ARM aarch64, version 1 (GNU/Linux), dynamically linked, interpreter /opt/lib/ld-linux-aarch64.so.1, for GNU/Linux 3.7.0, stripped

The file command gives a clue as to why it might be failing, or not, I'm no expert either. When I run file ./node the path to the interpreter is /lib/ld-linux-aarch64.so.1, but that path doesn't exist on my NAS nor does it exist in the container. The path to the node interpreter on my machine does point to an existing /opt/lib/ld-linux-aarch64.so.1. I don't know if this is relevant to determine the bug we have.

[marcelklehr]

It seems the node project updated their minimum required GLIBC version which is why the pre-built binaries fail on older systems that don't have version 'GLIBC_2.28'. You can check which version is on your system by running ldd --version

[varosengineer]

It seems the node project updated their minimum required GLIBC version which is why the pre-built binaries fail on older systems that don't have version 'GLIBC_2.28'. You can check which version is on your system by running ldd --version

ldd --version
ldd (crosstool-NG 1.24.0) 2.27
$Copyright (C) 2018 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
$Written by Roland McGrath and Ulrich Drepper.

Should I update the version of ldd?

[Hopp0]

Should I update the version of ldd?

I'm not sure you'd be able to in a snap - really you'd need to update the GLIBC version. I'm tempted to ditch the snap version of nextcloud and swap to running it in docker - I suspect I'd stand more chance of getting that to work.

[mr-bryn]

It seems the node project updated their minimum required GLIBC version which is why the pre-built binaries fail on older systems that don't have version 'GLIBC_2.28'. You can check which version is on your system by running ldd --version

My system reports GLIBC 2.36

Within the snap environment it reports GLIBC 2.27

What can be done to update GLIBC within the snap environment?

[mr-bryn]

I asked the question over on nextcloud snap. Doesn't sound like it will be resolved for a while.

[whatcheers]

Running into this on Ubuntu 20.04 as well.

[reox]

Similar problem here after an upgrade of the recognize app. It appears that the tarball that contains the node binaries wasn't correctly downloaded as I cannot unpack it manually:

www-data@nextcloud:~/nextcloud/apps/recognize/bin$ tar xvf x64.tar.gz
node-v20.9.0-linux-x64/
node-v20.9.0-linux-x64/share/
node-v20.9.0-linux-x64/share/doc/
node-v20.9.0-linux-x64/share/doc/node/
node-v20.9.0-linux-x64/share/doc/node/lldb_commands.py
node-v20.9.0-linux-x64/share/doc/node/gdbinit
node-v20.9.0-linux-x64/share/man/
node-v20.9.0-linux-x64/share/man/man1/
node-v20.9.0-linux-x64/share/man/man1/node.1
node-v20.9.0-linux-x64/LICENSE
node-v20.9.0-linux-x64/CHANGELOG.md

gzip: stdin: unexpected end of file
tar: Unexpected EOF in archive
tar: Unexpected EOF in archive
tar: Error is not recoverable: exiting now

Error can also be seen in the log:

[recognize] Fehler: Downloading of node binary failed
	GET /settings/apps/update/recognize
	von 1.2.3.4 von user um 30.07.2024, 09:16:05

[Thibb1]

Setting the path to /usr/bin/node in the Recognize admin panel fixed the issue for me

[CluelessTechnologist]

I run the Nextcloud docker container from LSIO which is based on alpine. When I first installed recognize I was confused as to why node didn't work, this is what is said when I tried to run it manually:

$ ./node -v 
bash: ./node: cannot execute: required file not found

After googling a bit, I discovered that alpine doesn't support any of the official builds of node since they use glibc instead of musl that alpine uses. There is a unofficial builds website, that has musl builds for x64 but not arm64 that I use (Raspberry Pi 4).

I was able to build my own node release by doing this:

docker pull alpine
docker run -it alpine /bin/sh
apk update
apk add build-base python3 linux-headers curl gcc g++ make openssl-dev
curl -o node-v20.15.1.tar.gz https://nodejs.org/dist/v20.15.1/node-v20.15.1.tar.gz
tar -xzf node-v20.15.1.tar.gz
cd node-v20.15.1
./configure --prefix=/usr --without-snapshot
make -j$(nproc)

When it's been compiled you should have a node binary that runs:

$./node -v 
v20.15.1

Now open another terminal and copy the binary to a path which the container can access.

$ docker cp c8486e8388d7:/node-v20.15.1/out/Release/node /docker/nextcloud/config/www/nextcloud/apps/recognize/bin/node_musl

At first I put it in /config/www/nextcloud/apps/recognize/bin, but I've noticed that after upgrading recognize it removed my node binary, so now I'm trying /config/www/nextcloud/ instead.

Then you just edit the Node.js path via the webgui to your own binary.

I do believe this would be possible to automate via Github actions or similar.

[marcelklehr]

Closing as the solution is part of the error message.