Hello!

I have been using wireguard successfully for a long time with this container, today though when the container restarted I got the following error:

2025-06-27 10:35:26,490 DEBG 'start-script' stderr output:

[#] ip link add dev wg0 type wireguard

2025-06-27 10:35:26,492 DEBG 'start-script' stderr output:

[#] wg setconf wg0 /dev/fd/63

2025-06-27 10:35:26,493 DEBG 'start-script' stderr output:

[#] ip -4 address add 10.2.0.2/32 dev wg0

2025-06-27 10:35:26,499 DEBG 'start-script' stderr output:

[#] ip link set mtu 1420 up dev wg0

2025-06-27 10:35:26,501 DEBG 'start-script' stderr output:

[#] resolvconf -a wg0 -m 0 -x

2025-06-27 10:35:26,508 DEBG 'start-script' stderr output:

could not detect a useable init system

2025-06-27 10:35:26,521 DEBG 'start-script' stderr output:

resolvconf: signature mismatch: /etc/resolv.conf

2025-06-27 10:35:26,522 DEBG 'start-script' stderr output:

resolvconf: run resolvconf -u to update

2025-06-27 10:35:26,529 DEBG 'start-script' stderr output:

[#] ip link delete dev wg0

2025-06-27 10:35:26,623 DEBG 'start-script' stdout output:

[warn] Failed to bring 'up' WireGuard kernel implementation

I am unsure what I should do to fix this, I see issues with resolvconf but since this is on startup am unsure what I should do. For now I switched to OpenVPN which is working successfully.

EDIT:
If I open the console of the container and do cat /etc/resolv.conf I see several different IP addresses listed. I recognize some like 1.1.1.1 as GOogle's DNS

nameserver 84.200.69.80

nameserver 37.235.1.174

nameserver 1.1.1.1

nameserver 37.235.1.177

nameserver 84.200.70.40

nameserver 1.0.0.1

EDIT 2:

I was able to resolve this by removing the DNS portion of my wg0.conf file

Edited June 27, 20251 yr by gustyScanner

Has anyone had the issue where the save button in the options window is not operating? I have tried multiple PC's and browsers. Nothing happens when I click the save button in the options windows... I cannot configure muy QBITTORRNET as a result. It is running, I just cannto save any settings.

11 minutes ago, twidget2011 said:

Has anyone had the issue where the save button in the options window is not operating? I have tried multiple PC's and browsers. Nothing happens when I click the save button in the options windows... I cannot configure muy QBITTORRNET as a result. It is running, I just cannto save any settings.

Scroll back one page. You’ll see the work around.

The latest update (5.1.1-2-01) broke my ProtonVPN WireGuard implmentation. Rolling back to the previous version corrects the error.

1 hour ago, anibis2 said:

The latest update (5.1.1-2-01) broke my ProtonVPN WireGuard implmentation. Rolling back to the previous version corrects the error.

Hi, I have the same problem. How can I rollback to the previous version?

32 minutes ago, -TSE- said:

Hi, I have the same problem. How can I rollback to the previous version?

I rolled back to tag 5.1.1-1-01 which fixed the issue for me. I guess the new update wasn't tested for wireguard connections.

Edit the docker container and change "Repository" from binhex/arch-qbittorrentvpn to binhex/arch-qbittorrentvpn:5.1.1-1-01 and click "Apply".

Broken here as well with a custom Wireguard conf. Rolling back fixes the issue.

17 hours ago, -TSE- said:

Hi, I have the same problem. How can I rollback to the previous version?

You append a colon and tag number to the text already in the repository field.

You can get the tag numbers here.

Hey Is anyone else having the 50% CPU usage spike that doesn't go down until you stop qbittorrent?

On 27/06/2025 at 17:24, gustyScanner said:

Ciao!

Ho usato Wireguard con successo per molto tempo con questo contenitore, ma oggi, quando ho riavviato il contenitore, ho ricevuto il seguente errore:

2025-06-27 10:35:26,490 DEBG 'start-script' stderr output:

[#] ip link add dev wg0 type wireguard

2025-06-27 10:35:26,492 DEBG 'start-script' stderr output:

[#] wg setconf wg0 /dev/fd/63

2025-06-27 10:35:26,493 DEBG 'start-script' stderr output:

[#] ip -4 address add 10.2.0.2/32 dev wg0

2025-06-27 10:35:26,499 DEBG 'start-script' stderr output:

[#] ip link set mtu 1420 up dev wg0

2025-06-27 10:35:26,501 DEBG 'start-script' stderr output:

[#] resolvconf -a wg0 -m 0 -x

2025-06-27 10:35:26,508 DEBG 'start-script' stderr output:

could not detect a useable init system

2025-06-27 10:35:26,521 DEBG 'start-script' stderr output:

resolvconf: signature mismatch: /etc/resolv.conf

2025-06-27 10:35:26,522 DEBG 'start-script' stderr output:

resolvconf: run resolvconf -u to update

2025-06-27 10:35:26,529 DEBG 'start-script' stderr output:

[#] ip link delete dev wg0

2025-06-27 10:35:26,623 DEBG 'start-script' stdout output:

[warn] Failed to bring 'up' WireGuard kernel implementation

Non so cosa fare per risolvere questo problema, noto dei problemi, resolvconfma dato che si verifica all'avvio, non so cosa fare. Per ora sono passato a OpenVPN, che funziona correttamente.

MODIFICA:
Se apro la console del contenitore e cat /etc/resolv.confvedo elencati diversi indirizzi IP, ne riconosco alcuni, come 1.1.1.1, come DNS di Google.

nameserver 84.200.69.80

nameserver 37.235.1.174

nameserver 1.1.1.1

nameserver 37.235.1.177

nameserver 84.200.70.40

nameserver 1.0.0.1

MODIFICA 2:

Sono riuscito a risolvere questo problema rimuovendo la parte DNS del mio file wg0.conf

I'm not expert, maybe this is a stupid question, but does this operation (delete the DNS part) causes any security risks?

Edited June 30, 20251 yr by BadUser

need some help with the incoming port - as it will be reset back to 6881, once the container is restarted

I've tried to screw around with the conf files to no avail

Pulling the files again as new doesn't help either.

Currently running version 5.1.0 - as I am not able to save the options page running on the latest 5.1.1

Anyone can chime in on this? Much appreciated

also having this same wireguard kernel issue, Should i just roll back (binhex/arch-qbittorrentvpn:5.1.1-1-01) or is there a fix to implement?

2025-07-01 00:22:34,901 DEBG 'start-script' stdout output:

[warn] Failed to bring 'up' WireGuard kernel implementation

Edited July 1, 20251 yr by Linguafoeda

Rolling back did not fix, nor did deleting DNS info from wg0.conf. I have the same issue of 'wg tunnel can't go up' or whatever the error is exactly. I have yet to transfer to OpenVPN temporarily.

Edited July 1, 20251 yr by thatsthefrickenlightning

Same here since 1 or 2 days :

2025-07-01 17:48:13,306 DEBG 'start-script' stdout output:

[warn] Failed to bring 'up' WireGuard kernel implementation

Im on ProtonVPN

Edit : Had to rollback to binhex/arch-qbittorrentvpn:5.1.1-1-01

Edited July 1, 20251 yr by Nackophilz

The same issue and the same fix—rolling back to the previous version.

It appears to be an issue with underlying Arch Linux. See https://bbs.archlinux.org/viewtopic.php?id=306639

On 7/1/2025 at 12:51 AM, BadUser said:

I'm not expert, maybe this is a stupid question, but does this operation (delete the DNS part) causes any security risks?

in a word, no.

14 hours ago, andenker said:

The same issue and the same fix—rolling back to the previous version.

It appears to be an issue with underlying Arch Linux. See https://bbs.archlinux.org/viewtopic.php?id=306639

Nice, thanks for finding it.

A rollback worked for me this time too. Turns out my Wireguard credentials also expired on Sunday so it was a double error.

All good for now, I'll revert back to :latest in a few weeks or something and I'm sure the fix will have trickled down.

Thanks to everyone who brainstormed about this.

On 6/29/2025 at 3:12 PM, ulkesh said:

I rolled back to tag 5.1.1-1-01 which fixed the issue for me. I guess the new update wasn't tested for wireguard connections.

Edit the docker container and change "Repository" from binhex/arch-qbittorrentvpn to binhex/arch-qbittorrentvpn:5.1.1-1-01 and click "Apply".

God Bless You! I'm a newbie in the Docker world and I was desperately trying to figure out how to roll back my container. Thank you so much for this simple instruction. My issue is now resolved. :)

1 hour ago, PakledVueAdmin said:

God Bless You! I'm a newbie in the Docker world and I was desperately trying to figure out how to roll back my container. Thank you so much for this simple instruction. My issue is now resolved. :)

For reference, you can find all the tags for this specific container here:

https://hub.docker.com/r/binhex/arch-qbittorrentvpn/tags

I have installed binhex-qbittorrentvpn today as my binhex-delugevpn has been stalling every download and I have been unable to fix it... so thought it might be time for a change.

I set it up with PIA VPN which is working fine, and configured the downloads folders (/data/completed & /data/incompleted) to the same share on my UnRAID as binhex-delugevpn was configured for. As a test I imported a handful of .torrent files from /appdata/binhex-delugevpn/state without starting the torrent. Then I forced a recheck and it showed the torrent as 100%... so when I started it, it showed as seeding 😁

All good so far. So, I imported 50 torrents this way and they were showing as seeding perfectly.

Next I configured Sonarr to use qbittorrent and when I searched for an episode, it correctly sends the data to qbittorrent but the torrent momentarily shows as "checking resume data", then "stalled", then immediately shows as "errored".

I configured UMASK = 000, PUID = 99 & PGID = 100 - which is the same as delugevpn was configured to... also I checked the /data/completed & /data/incomplete permissions and they are showing as Owner: nobody [99] & Group: users [100] with Permissions set to 777.

I did try changing PUID & PGID both to 0, but this didn't fix it, so I switched them back to 99 & 100.

I looked in the log and the last few lines don't seem to show any errors;

2025-07-02 19:31:09,984 DEBG 'watchdog-script' stdout output:

[info] qBittorrent process started

[info] Waiting for qBittorrent process to start listening on port 8080...

2025-07-02 19:31:10,351 DEBG 'watchdog-script' stdout output:

[info] qBittorrent process listening on port 8080

2025-07-02 19:41:09,499 DEBG 'start-script' stdout output:

[info] Successfully assigned and bound incoming port

2025-07-02 19:51:09,665 DEBG 'start-script' stdout output:

[info] Successfully assigned and bound incoming port

2025-07-02 20:01:09,827 DEBG 'start-script' stdout output:

[info] Successfully assigned and bound incoming port

2025-07-02 20:11:09,995 DEBG 'start-script' stdout output:

[info] Successfully assigned and bound incoming port

2025-07-02 20:21:10,161 DEBG 'start-script' stdout output:

[info] Successfully assigned and bound incoming port

When I rebooted the docker, I saw that all the 50 torrents I imported were showing as "checking" and then when they reached 100% they started to seed again. But in all I will be importing nearly 1000 torrents, so cant really afford for them to be checked every time the docker restarts!

[UPDATE] I deleted the 50 torrents I had imported and just imported 5... when I rebooted the docker they all showed as seeding straight away, so maybe the "checking" above was some anomaly! Hopefully if I import them in small batches it wont recheck after every reboot :)

So, can anyone help with trying to start diagnosing the issue?

Any help appreciated

[UPDATE] I read on another qbittorent forum that there is a log in qbittorent, which I didnt realise... when I look in here it says;

File error alert. Torrent: xxxx error: No space left on device

But, /data/incomplete & /data/completed is mapped to a single drive and there is 600Gb of space left on it!

[EDIT3] I remember that when it was first set up with the default download storage settings it worked OK as I ran a test, so I know this problem is due to the location provided for the torrents to download to. To recap:

In the docker settings /data is set to /mnt/user/downloads/ (I did try /mnt/user/downloads too).

My actual storage location on UnRAID is - /mnt/user/downloads/incomplete & /mnt/user/downloads/completed

/mnt/user/downloads/ and subdirectories is set to Owner: nobody [99] & Group: users [100] with Permissions set to 777.

In the qBitTorrent settings...

Can anyone help as I am now successfully seeding 800 torrents, but am unable to download any :(

Thanks

[SOLVED] OK, tonight as I had not had any replies, I looked into this more and found that my downloads share had Minimum free space: set to 585.5 GB - I dont know how or why this had been set so high, so I changed it and all my downloads are now working 😁

I thought I would post this, just in case anyone else has a similar issue.

Edited July 8, 20251 yr by SliMat
SOLVED

I can't access the Web UI.

I keep getting connection timeout on my browser. I have recently been looking at adjusting the ports but didn't end up confirming any changes and just switched the conflicting container's port to another. Sonarr is able to connect to the container and the logs show it is running without error. Is there something I am missing? It has opened without issue in the past. I tried rolling back the version, but nothing changed.

I have searched the support page for this, but it is mostly people who can't log into the UI. Mine isn't loading at all

5 hours ago, L4chy22 said:

I can't access the Web UI.

I keep getting connection timeout on my browser. I have recently been looking at adjusting the ports but didn't end up confirming any changes and just switched the conflicting container's port to another. Sonarr is able to connect to the container and the logs show it is running without error. Is there something I am missing? It has opened without issue in the past. I tried rolling back the version, but nothing changed.

I have searched the support page for this, but it is mostly people who can't log into the UI. Mine isn't loading at all

I had the same problem. It was failing to bring up the wireguard instance.

I downgraded to binhex/arch-qbittorrentvpn:5.0.4-3-01 and its now working for me.

https://bbs.archlinux.org/viewtopic.php?pid=2249137#p2249137

should we implement this fix suggested in the above thread or wait for binhex-qbittorrent to get fixed in a new release?

Can confirm the same issue, the funny thing is that in my case they are complaining just because of the header as in both cases resolv.conf points to 127.0.0.1 but sometimes is generated by Network manager and others by resolvconf depending on which tool run last.

# Generated by NetworkManager
nameserver 127.0.0.1

# Generated by resolvconf
nameserver 127.0.0.1

#Solution
Add this file in conf.d of networkmanager

cat /etc/NetworkManager/conf.d/rc-manager.conf 
[main]
rc-manager=resolvconf

Regenerate the config with resolvconf -u

Reboot the system

16 hours ago, voidthe said:

I had the same problem. It was failing to bring up the wireguard instance.

I downgraded to binhex/arch-qbittorrentvpn:5.0.4-3-01 and its now working for me.

Hi, how do I downgrade?

I updated to latest version today and started having problems.

Thank you

Read a few posts up.