/usr/bin/qbittorrent-nox: error while loading shared libraries: libQt5Core.so.5: cannot open shared object file: No such file or directory

[fexofenadine]

---

Expected Behavior

Start container, access UI

Current Behavior

UI never loads, error /usr/bin/qbittorrent-nox: error while loading shared libraries: libQt5Core.so.5: cannot open shared object file: No such file or directory appears repeatedly in log.

Steps to Reproduce

1. Upgrade to latest/version-14.3.3.99202101191832-7248-da0b276d5ubuntu20.04.1 image
2. Start container
3. Check log

Environment

OS: GNU/Linux synology_avoton_1515+ 3.10.108
CPU architecture: x86_64
How docker service was installed: Synology docker package

Workaround

Downgrade back to version-14.3.3.99202101191832-7248-da0b276d5ubuntu18.04.1

[github-actions]

Thanks for opening your first issue here! Be sure to follow the bug or feature issue templates!

[fexofenadine]

appears similar to this issue

[nhsqr]

Meanwhile a workaround:

1. Attach to docker container
2. apt update
3. apt install binutils
4. strip --remove-section=.note.ABI-tag /usr/lib/x86_64-linux-gnu/libQt5Core.so.5

Found this solution here: binhex/arch-qbittorrentvpn#5

[R8s6]

Meanwhile a workaround:

1. Attach to docker container

2. apt update

3. apt install binutils

4. strip --remove-section=.note.ABI-tag /usr/lib/x86_64-linux-gnu/libQt5Core.so.5

Found this solution here: binhex/arch-qbittorrentvpn#5

This worked, thank you!

Update: as some reported it could be due to kernel 3.1x, my nas Synology DS1815 happens to be on kernel 3.10.105 as well.

[j0nnymoe]

We've been unable to replicate this issue within the team and it's not failing our smoke tests here: https://ci-tests.linuxserver.io/linuxserver/qbittorrent/latest/index.html

[nhsqr]

We've been unable to replicate this issue within the team and it's not failing our smoke tests here: https://ci-tests.linuxserver.io/linuxserver/qbittorrent/latest/index.html

Your tests are on an image of ubuntu18.04 and we are talking about an image of ubuntu20.04.
We know that image of ubuntu18.04 works as is stated in the first post.

[j0nnymoe]

Our container is on 20.04 and those test results are of the latest image.

Wait I see the confusion, one moment

[j0nnymoe]

correct results: https://ci-tests.linuxserver.io/linuxserver/qbittorrent/14.3.3.99202101191832-7248-da0b276d5ubuntu20.04.1-ls116/index.html

[nhsqr]

I see the results are all OK.
I can't figure out the problem but I am guessing it is something to do with Synology.
It might be the kernel for some reason. Although I use the latest DSM 6.2.3-25426 Update 3, the kernel in this DSM is only 3.10.105 and since docker shares some functions between container and host it might not be compatible and we can't do anything about that probably.
Of course, this is only a guess and if someone has more knowledge about that please share.

[flammable]

I'm encountering the same issue, also with a fully up to date Synology DS1817+ (running DSM 6.2.3-25426 Update 3).

# docker version
Client:
 Version:           18.09.8
 API version:       1.39
 Go version:        go1.11
 Git commit:        bfed4f5
 Built:             Fri Mar 13 06:46:11 2020
 OS/Arch:           linux/amd64
 Experimental:      false

Server:
 Engine:
  Version:          18.09.8
  API version:      1.39 (minimum version 1.12)
  Go version:       go1.11
  Git commit:       3a371f3
  Built:            Fri Mar 13 06:44:35 2020
  OS/Arch:          linux/amd64
  Experimental:     false

The workaround @nhsqr posted is working for me, too. My workaround for now might be to incorporate those into a startup script for the container. I really appreciate your looking into this, @j0nnymoe, as well for the image itself! I'm not a container expert by any means, but please let me know if I can help test or provide more information.

[j0nnymoe]

I'll try on my Syno (and qnap for good measure) when I get a free moment (if not it'll be the weekend) and see if I can replicate. 👍

[Furbodo]

Getting same issue on Centos7.
Following fixes it.

Meanwhile a workaround:

1. Attach to docker container
2. apt update
3. apt install binutils
4. strip --remove-section=.note.ABI-tag /usr/lib/x86_64-linux-gnu/libQt5Core.so.5

Found this solution here: binhex/arch-qbittorrentvpn#5

[wmassingham]

I'm also seeing the same when running the container on CentOS 7.9.2009, kernel 3.10.0-1160.15.2.el7.x86_64 (Docker version 20.10.3, build 48d30b5). The strip allowed qbittorrent to start for me as well.

[fexofenadine]

binhex/arch-qbittorrentvpn#3 (comment)

Issue appears to be that the OS kernel is lower than 3.15, and Qt 5.10 uses the renameat2 system call which is only available since kernel 3.15

I'm on kernel 3.10.108 incidentally

[R8s6]

binhex/arch-qbittorrentvpn#3 (comment)

Issue appears to be that the OS kernel is lower than 3.15, and Qt 5.10 uses the renameat2 system call which is only available since kernel 3.15

I'm on kernel 3.10.108 incidentally

If this is the case, because Synology DS1815+ probably won't receive any more kernel updates, I might have to move this docker from DSM's built-in docker to one in a VM that has a v4+ kernel.