rm -f tun device breaks startup

[polaris940]

Is there a pinned issue for this?

• I have read the pinned issues and could not find my issue

Is there an existing or similar issue/discussion for this?

• I have searched the existing issues
• I have searched the existing discussions

Is there any comment in the documentation for this?

• I have read the documentation, especially the FAQ and Troubleshooting parts

Is this related to a provider?

• I have checked the provider repo for issues
• My issue is NOT related to a provider

Are you using the latest release?

• I am using the latest release

Have you tried using the dev branch latest?

• I have tried using dev branch

Docker run config used

# docker compose
version: "3.3"
services:
  transmission:
    image: haugene/transmission-openvpn
    cap_add:
      - NET_ADMIN
    devices:
      - "/dev/net/tun:/dev/net/tun"

pinning it to 4.1 works without any additional changes

Current Behavior

container fails to start when trying to remove /dev/net/tun

Expected Behavior

Failing gracefully and/or using the existing tun device that is passed through

How have you tried to solve the problem?

• Reverting to 4.1 allows it to startup fine again
• Have also tried mucking with the permissions at the host level. No joy

Log output

v4.2

Starting container with revision: f9cb4dea2da1a3aa63bd3945e0162c9b8a9789a4
Creating TUN device /dev/net/tun
rm: cannot remove '/dev/net/tun': Device or resource busy
# forces container restart loop

v4.1

<TIMESTAMP> Starting container with revision: 84941a9ea4663d8b2e1af3db1d50fe4f7fa8736e
<TIMESTAMP> Creating TUN device /dev/net/tun
<TIMESTAMP> mknod: /dev/net/tun: File exists
<TIMESTAMP> chmod: changing permissions of '/dev/net/tun': Operation not permitted
...
<TIMESTAMP> STARTING TRANSMISSION
<TIMESTAMP> Transmission startup script complete.
<TIMESTAMP> Initialization Sequence Completed

HW/SW Environment

- OS: Proxmox VE
- Docker: 20.10.12, build e91ed57

- LXC host with Docker container running transmission-openvpn
- permissions for /dev/net/tun are set on the host and then passed through to the container

Anything else?

Appears to be related to #2296.

Seems like trying to force the removal of the device in this instance doesn't work since permissions are set at the host level and passed all the way through. Likely just needs to be able to fail gracefully.

[ianhundere]

same behavior here as well

[polaris940]

Resolved this with an environment config. CREATE_TUN_DEVICE=false can be set to disable removing/creating the tun device and allows the container to start.

# docker compose
version: "3.3"
services:
  transmission:
    image: haugene/transmission-openvpn:4.2
    cap_add:
      - NET_ADMIN
    devices:
      - "/dev/net/tun:/dev/net/tun"
    environment:
      - CREATE_TUN_DEVICE=false

[ianhundere]

@polaris940 isn't CREATE_TUN_DEVICE=true necessary for the vpn to work?

[polaris940]

@polaris940 isn't CREATE_TUN_DEVICE=true necessary for the vpn to work?

I don’t think so for my setup. If yours is different it may be worth opening a new ticket.

I created it on the Proxmox host and then passed that through the LXC container to the Docker container.

I haven’t totally gotten 4.2 working but disabling the creation seems to allow the container to start again. Seeing another issue with settings migrations but haven’t been able to dig into that one yet so still rocking 4.1 for the moment.

[haugene]

There has been a change in the recommended way to run the container over the years. All the "getting started" examples used to mount the device like you do here @polaris940 but we then moved to creating a tun device in the container instead. This fixed issues on some NAS devices IIRC.

So you should be able to remove the devices mount and let CREATE_TUN_DEVICE just default to true and it should also work?

[polaris940]

So you should be able to remove the devices mount and let CREATE_TUN_DEVICE just default to true and it should also work?

Nope that didn't work. I think it has to do with it being in an LXC container as well; it's a bit of an inception scenario of a container in a container. Probably works fine on bare metal setups where Docker is running directly on the OS.

Starting container with revision: f9cb4dea2da1a3aa63bd3945e0162c9b8a9789a4
Creating TUN device /dev/net/tun
mknod: /dev/net/tun: Operation not permitted

[haugene]

That makes sense. Passing permissions through two layers of "virtualization" could cause difficulties, so just mounting it from the host and doing CREATE_TUN_DEVICE=false is probably the best option then 👍

[ianhundere]

So you should be able to remove the devices mount and let CREATE_TUN_DEVICE just default to true and it should also work?

ah, this was it...removed the /dev/net/tun mount and set CREATE_TUN_DEVICE back to true (default value)