Exiting due to fatal error

[crypticviper]

Firstly, thanks for this great container. Have been using it for months now without any issues.

However, since I restarted the container today, I have been only getting below error for some reason. Tried different openvpn configurations (i.e. different VPN servers from my VPN providers to no avail). Thanks in advance for any help in this regard. Cheers!

Below are the container logs:

[cont-init.d] executing container initialization scripts... [cont-init.d] 01-environment: executing... 2022-02-25 21:36:39 [INFO] LAN_NETWORK defined as '192.168.50.0/24' 2022-02-25 21:36:39 [INFO] PUID defined as 1000 2022-02-25 21:36:39 [INFO] PGID defined as 100 2022-02-25 21:36:39 [INFO] An user with PUID 1000 already exists in /etc/passwd, nothing to do. 2022-02-25 21:36:39 [INFO] VPN_ENABLED defined as 'yes' 2022-02-25 21:36:39 [INFO] VPN_TYPE defined as 'openvpn' 2022-02-25 21:36:39 [WARNING] NAME_SERVERS not defined (via -e NAME_SERVERS), defaulting to CloudFlare and Google name servers 2022-02-25 21:36:39 [INFO] Adding 1.1.1.1 to resolv.conf 2022-02-25 21:36:39 [INFO] Adding 8.8.8.8 to resolv.conf 2022-02-25 21:36:39 [INFO] Adding 1.0.0.1 to resolv.conf 2022-02-25 21:36:39 [INFO] Adding 8.8.4.4 to resolv.conf [cont-init.d] 01-environment: exited 0. [cont-init.d] 02-vpn: executing... 2022-02-25 21:36:39 [INFO] Choosen VPN config: 'xxx.myvpn.com.ovpn' 2022-02-25 21:36:39 [INFO] Using credentials from env vars dos2unix: converting file /config/openvpn/xxx.myvpn.com.ovpn to Unix format... 2022-02-25 21:36:39 [INFO] VPN remote line defined as 'xx.xx.xx.38 443' 2022-02-25 21:36:39 [INFO] VPN_REMOTE defined as 'xx.xx.xx.38' 2022-02-25 21:36:39 [INFO] VPN_PORT defined as '443' 2022-02-25 21:36:39 [INFO] VPN_PROTOCOL defined as 'tcp' 2022-02-25 21:36:39 [INFO] VPN_DEVICE_TYPE defined as 'tun0'

2022-02-25 21:36:39 [INFO] Starting OpenVPN... 2022-02-25 21:36:39 DEPRECATED OPTION: --cipher set to 'AES-256-CBC' but missing in --data-ciphers (AES-256-GCM:AES-128-GCM). Future OpenVPN version will ignore --cipher for cipher negotiations. Add 'AES-256-CBC' to --data-ciphers or change --cipher 'AES-256-CBC' to --data-ciphers-fallback 'AES-256-CBC' to silence this warning. 2022-02-25 21:36:39 OpenVPN 2.5.2 armv7-alpine-linux-musleabihf [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [MH/PKTINFO] [AEAD] built on May 4 2021 2022-02-25 21:36:39 library versions: OpenSSL 1.1.1l 24 Aug 2021, LZO 2.10 2022-02-25 21:36:39 neither stdin nor stderr are a tty device and you have neither a controlling tty nor systemd - can't ask for 'Enter Auth Username:'. If you used --daemon, you need to use --askpass to make passphrase-protected keys work, and you can not use --auth-nocache. 2022-02-25 21:36:39 Exiting due to fatal error

Below is my docker compose (untouched for months now). I am running this on Portainer which is running on Open Media Vault 6.x.

version: "2" services: qbittorrentvpn: image: trigus42/qbittorrentvpn:latest container_name: qbittorrentvpn privileged: true
environment:

• VPN_ENABLED=yes
• VPN_TYPE=openvpn
• VPN_USERNAME=xxxxxxx
• VPN_PASSWORD=xxxxxxx
• PUID=1000
• PGID=100
• LAN_NETWORK=192.168.xx.0/24
• HEALTH_CHECK_HOST=8.8.8.8
• HEALTH_CHECK_INTERVAL=300 ports:
• 8080:8080 volumes:
• /qbittorrent:/config
• :/downloads
• /etc/localtime:/etc/localtime restart: unless-stopped

[Trigus42]

Did you recently pull a newer version of the image? Maybe a change in one of the last commits created this bug. If not, please try to update the container (docker-compose up -d) and see if this solves the bug.

It seems like OpenVPN gets called without a credentials file. This should only happen if there is no credentials file or it is empty: https://github.com/Trigus42/alpine-qbittorrentvpn/blob/beefcef2f579fd2d8f29c20d472742923e65cddf/rootfs/etc/cont-init.d/02-vpn#L197-L204

The following part should store your credentials in a file ${VPN_CONFIG_NAME}"_credentials.conf, printing [INFO] Using credentials from env vars the first time the container is started and from then on use the credentials stored in ${VPN_CONFIG_NAME}"_credentials.conf, ignoring your VPN credentials in the docker compose file and printing [INFO] Using credentials from /config/openvpn/${VPN_CONFIG_NAME}_credentials.conf to the log: https://github.com/Trigus42/alpine-qbittorrentvpn/blob/beefcef2f579fd2d8f29c20d472742923e65cddf/rootfs/etc/cont-init.d/02-vpn#L48-L70

If this is not the first start after you reset the container and deleted the config files, you shouldn't get [INFO] Using credentials from env vars in your log.

Please check to see if the credentials file which in your case should be stored under /qbittorrent/openvpn/ named xxx.myvpn.com.ovpn_credentials.conf exists and contains the correct credentials.

[crypticviper]

@Trigus42 Yes, I think I did pull the latest image few days back. May be that's the reason.

As for credentials file, If I keep xxx.myvpn.com.ovpn.openvpn file in /qbittorrent/openvpn/ folder, when the conrainer starts it automatically creates a new file called xxx.myvpn.com.ovpn_credentials.conf and fills it with appropriate credentials after reading it from ENV supplied in docker compose file. And it is never empty, it has correct credentials.

I will try pulling some older versions of the image and see if that helps.

[crypticviper]

Ok, now it is really weird. I switched to an older version (trigus42/qbittorrentvpn:qbt4.3.9-20211121) and it started working again.

After that I switched back to latest image and things seem to work just fine! Strange! I will try to reproduce this further and if not will close this issue. Thanks for your time.

[crypticviper]

Ok I was able to sort of reproduce it. I usually have the habit of emptying /qbittorrent/openvpn/ folder and copy a new .openvpn file there (I do this if I have to switch VPN servers) and then restart the container. With latest images, this results in the error I mentioned in my initial post.

I tried below image versions and all of them seem to have this problem (I am not sure if this is an issue or just a weird use case that I have).

trigus42/qbittorrentvpn:latest trigus42/qbittorrentvpn:qbt4.3.9 trigus42/qbittorrentvpn:qbt4.4.0

For the time being I have found an older version which does work for me with my scenario. This version is:

trigus42/qbittorrentvpn:qbt4.3.9-20211121

May be there are images that are newer than this which work but I haven't tried them all.

[Trigus42]

Thanks to your info I was able to identify the problem quickly. Please try the trigus42/qbittorrentvpn:testing image (if you have an x86-64 system) to see if this fixes your problem.

[crypticviper]

@Trigus42 Thanks for your time and the fix. However, I am sorry, I only have a raspberry pi to test it.

[Trigus42]

This would probably be armv7, right? I've rebuild the image. You can try it out now.

[crypticviper]

@Trigus42 it's armv71 as per lscpu I expected armv7 to include this but somehow it doesn't seem so. I tried the image with testing tag but container doesn't start. I get below repeated errors in container logs.

standard_init_linux.go:228: exec user process caused: exec format error

[Trigus42]

It was getting late, but now I've built it for all architectures supported by the normal images and tested it on my RPi4. It should work now.

[crypticviper]

@Trigus42 works fine now. I tested my scenario as well. Everything is working as expected. Thanks a lot for your replies and time. Cheers! Closing this issue.

[Trigus42]

Great! I have created a new stable image with the changes.