no JavaxUsb in java.library.path

javax.usb.UsbException: Error while loading shared library libJavaxUsb.so : no JavaxUsb in java.library.path
at com.ibm.jusb.os.linux.JavaxUsb.loadLibrary(JavaxUsb.java:35)
at com.ibm.jusb.os.linux.LinuxUsbServices.<init>(LinuxUsbServices.java:30)
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
at java.lang.reflect.Constructor.newInstance(Constructor.java:513)
at java.lang.Class.newInstance0(Class.java:355)
at java.lang.Class.newInstance(Class.java:308)
at javax.usb.UsbHostManager.createUsbServices(Unknown Source)
at javax.usb.UsbHostManager.getUsbServices(Unknown Source)
at teste.TraverseUSB.main(TraverseUSB.java:18)

O erro que eu mencionei no final do post passado é esse aqui em cima, e o link que me ajudou a desvendar o problema foi esse.

A variável LD_LIBRARY_PATH contém uma lista de diretórios separados
por ";" onde o sistema irá procurar por determinada biblioteca de
carregamento dinâmico. Em Linux, essas bibliotecas são arquivos com
extensão ".so". São os equivalentes aos arquivos ".dll" do ruindows.
Essa variável funciona de forma semelhante ao PATH que serve pra
encontrar arquivos executáveis.
Na verdade, quando um programa precisa, digamos, de uma libGL.so (para
o OpenGL), o sistema procura esse arquivo nos diretórios listados na
LD_LIBRARY_PATH, depois no arquivo /etc/ld.so.cache e por último nos
diretórios /usr/lib e /lib.

Baseado nessas informações e na mensagem de erro, mandei localizar o arquivo libJavaxUsb.so, que foi encontrado dentro de javax-usb-ri-linux/lib. Fiz uma cópia deste arquivo pra dentro da pasta /usr/lib para que o sistema pudesse encontrar a biblioteca, resolvendo o problema.