./x2t: error while loading shared libraries: libgraphics.so: cannot open shared object file: No such file or directory

[plush]

Since the upgrade to Nextcloud 20.0 and Community Document Server 0.1.8, any attempt to access a document results in "ONLYOFFICE cannot be reached. Please contact admin." The log says that this is because the x2t binary cannot find libgraphics.so. The two files actually reside in the same directory, but apparently the library search path was not set, so x2t cannot find the library it needs. Setting LD_LIBRARY_PATH=. allows the binary to run. You can verify this on the command line.

Without setting LD_LIBRARY_PATH: Failure

$ cd apps/documentserver_community/3rdparty/onlyoffice/documentserver/server/FileConverter/bin
$ ./x2t
./x2t: error while loading shared libraries: libgraphics.so: cannot open shared object file: No such file or directory

With LD_LIBRARY_PATH=.: Success

$ cd apps/documentserver_community/3rdparty/onlyoffice/documentserver/server/FileConverter/bin
$ LD_LIBRARY_PATH=. ./x2t
-------------------------------------------------------------------------------
                OOX/binary file converter. Version: 5.6.5.3
-------------------------------------------------------------------------------
[...]

The fix would be to pass the correct LD_LIBRARY_PATH in ConverterBinary.php line 51. I quickly hacked this for myself by setting LD_LIBRARY_PATH to ., but the proper fix may be to derive the value from a path constant somewhere - I will leave it to those experienced with this project to develop a patch. This one-line hack was sufficient to get my Nextcloud working again though.

[speerwerfer]

The fix would be to pass the correct LD_LIBRARY_PATH in ConverterBinary.php line 51. I quickly hacked this for myself by setting LD_LIBRARY_PATH to ., but the proper fix may be to derive the value from a path constant somewhere - I will leave it to those experienced with this project to develop a patch. This one-line hack was sufficient to get my Nextcloud working again though.

can you send this one line of your FIX? I would also like to use that until it is officially fixed

[plush]

I am sorry, I am not allowed to provide a patch directly for reasons. But it's easy to make the change yourself. The last argument to proc_open() is an array of environment variables. It's empty by default. Just replace it with an array that sets 'LD_LIBRARY_PATH' to '.'.

[plush]

The PHP manual explains the array syntax and provides examples. You can define the array inline, making it a true one-line change.

[TueTchen]

Thank you!
Now happy - works fine with the replacement of the empty array at the end of line 51:
replace [ ] with ["LD_LIBRARY_PATH" => "."]

[plush]

Yep, that's all it takes.

[nilskamm]

That´s a really easy fix. Thanks a lot for sharing!!!

[alghanim-lab]

I tried your solution and I changed this line as follows:

Unfortunately your solution doesn't work for me
in my system the variable LD_LIBRARY_PATH is not found with the command echo $LD_LIBRARY_PATH.

I used the find / -name command to search for and found the libgcc_s.so.1 object under /usr/lib/aarch64-linux-gnu/ and exported it but still doesn't work

does anyone have any ideas?

[dugwood]

@alghanim-lab you can change $cmd from:

$cmd = './x2t ' . escapeshellarg($param);

to:

$cmd = 'export LD_LIBRARY_PATH=".";./x2t ' . escapeshellarg($param);

Worked for me (but I have other issues...).

My environment is a PHP-FPM chrooted, hence the same issue (I think).

[eliotmasset]

Hi, all this solutions don't work for me and after a while, this work with :
sudo cp apps/documentserver_community/3rdparty/onlyoffice/documentserver/server/FileConverter/bin/*.so /usr/lib64/
and
sudo cp apps/documentserver_community/3rdparty/onlyoffice/documentserver/server/FileConverter/bin/*.so.58 /usr/lib64/

Hope this can help some people !

[mrbaseman]

hmm... this way you have executable code which is not maintained by the package manager somewhere in the system. The proper solution would be to include those directories into $LD_LIBRARY_PATH - better as an absolute path rather than something like '.' - the latter would be more portable but less secure. So, find out the absolute path to the needed shared libraries, and append it to $LD_LIBRARY_PATH would be the preferred solution.

[github-actions]

This issue has been marked 'stale' due to lack of recent activity. If there is no further activity, the issue will be closed in another 60 days. Thank you for your contribution!

Retaking repo management include inheritance of old, not treated, and probablty obsolete issues, this is why it was decided to mark issues as stale.

[plush]

The issue persists to this date. It's not stale/obsolete.

[chadek]

This issue should now be fix in v0.1.19