Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

OpenVPN Permission Denied #54

Open
cowza opened this issue Aug 24, 2021 · 3 comments
Open

OpenVPN Permission Denied #54

cowza opened this issue Aug 24, 2021 · 3 comments

Comments

@cowza
Copy link

cowza commented Aug 24, 2021

Hey there, I get the following error when starting up my container. I've had it working in the past but recently it fails to startup with this permission denied error.

2021-08-24 15:14:12.811822 [INFO] Starting OpenVPN...
openvpn: error while loading shared libraries: libnsl.so.1: cannot open shared object file: Permission denied

Here is my stack that I'm deploying with docker-compose

version: '3.3'

services:
 jackettvpn:
  image: dyonr/jackettvpn:latest
  restart: unless-stopped
  privileged: true
  cap_add:
    - NET_ADMIN
  ports:
    - "9117:9117"
  devices:
    - /dev/net/tun
  volumes:
    - /volume2/docker/jackett-vpn:/config
    - /volume2/downloads/tmp:/blackhole
  environment:
    - VPN_ENABLED=yes
    - VPN_TYPE=openvpn
    - LAN_NETWORK=192.168.0.0/16

    - NAME_SERVERS=209.222.18.222,209.222.18.218

  network_mode: bridge
@cchhat01
Copy link

cchhat01 commented Sep 28, 2021

I'm having the exact same thing occur to me, time and again on my Synology NAS.
In my case, I've re-created the NAS container with the following setup:

	--restart=unless-stopped \
	--cap-add=NET_ADMIN \
    --publish 32785:9117 \
	--volume /volume1/configs/jackettvpn:/config \
	--env VPN_ENABLED=yes \
	--env VPN_TYPE=openvpn \
	--env "VPN_OPTIONS=--inactive 3600 --ping 10 --ping-exit 60" \
	--env "LAN_NETWORK=192.168.1.0/24" \
    --env PUID=1024 \
    --env PGID=100 \
	--env "TZ=America/New_York" \
	--env LEGACY_IPTABLES=1 \
	dyonr/jackettvpn

At startup, every single time, the container throws a tantrum about
openvpn: error while loading shared libraries: libnsl.so.1: cannot open shared object file: Permission denied
The only way around it is to stop the container manually, then Editing its docker settings by:

  1. Disabling "Execute container using high privilege" and "Enable auto-restart" check-boxes
  2. Start/stop repeat until you see a different error in your logs ("unable to create /dev/net/tun", or something to that effect)
  3. Edit the settings again and re-enable "Execute container using high privilege" and "Enable auto-restart" check-boxes
  4. Start the container (this time OpenVPN will execute correctly

Doing so will keep the jackettvpn container running for a day or so and then once the openvpn session terminates, we will have the exact same problem with Permission denied (rinse-and-repeat)

I have no idea why this keeps on happening and JackettVPN just continues to exhibit this issue
I have another contain with OpenVPN built in (haugene/transmission-openvpn) and although it randomly sees the issue as well, it almost never loses the OpenVPN connection... its been up for days now.
I am running DSM 7.0 (not the latest patch).

Any ideas ?

@cchhat01
Copy link

cchhat01 commented Oct 4, 2021

I fixed this by doing recreating the container as follows:

sudo docker run -d --name="jackettvpn" \
	--restart unless-stopped \
	--cap-add=NET_ADMIN \
	--device /dev/net/tun:/dev/net/tun \
	--sysctl net.ipv6.conf.all.disable_ipv6=1 \
	--publish 9117:9117 \
	--volume /path/to/jackettvpn_configs:/config \
	--env VPN_ENABLED=yes \
	--env VPN_TYPE=openvpn \
	--env "VPN_OPTIONS=--inactive 3600 --ping 10 --ping-exit 60" \
	--env "LAN_NETWORK=192.168.1.0/24" \
	--env PUID=1024 \
	--env PGID=100 \
	--env "TZ=America/New_York" \
	--env LEGACY_IPTABLES=1 \
	dyonr/jackettvpn

Turns out running it in elevated privileges was interfering with the setup...

@dem0ngo
Copy link

dem0ngo commented May 14, 2022

Hi, I'm having a very similar issue as you both were. I know its been a few months, but do you remember what exactly it is you did that fixed it? I don't notice a meaningful difference in your setup or understand what you mean by "running it in elevated privileges was interfering with the setup". Thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants