USB passthrough to LXC problem

[enry86cami]

Assuming you restarted (reconfigured?) the NUT container correctly it appears that the NUT container cannot access the original file only the symlink, as your output would indicate:


I googled a bit on the subject & it would appear others have had similar issues with containers (though in docker) only being able to access the symlink & not the original file.

Lets try & see if a workaround helps.

What does the following show (on the PVE host):

readlink /dev/ups0

this is the docker-compose.yml:

version: '2.2'
services:
  nut-upsd:
    container_name: nut-upsd
    image: upshift/nut-upsd
    devices:
    - /dev/ups0
    environment:
    - UPS_NAME=APC
    - UPS_DRIVER=usbhid-ups
    - API_USER=master
    - API_PASSWORD=mypasswd
    network_mode: host
    restart: unless-stopped

when the usb path changes I modify only the line: - /dev/ups0

 

[enry86cami]

Replying to my own query - I found the command in the docs! Its with the --delete <string> parameter. So in your case that would be:
pct set VMID --delete dev0 (if you used dev0 originally, I'm not sure) & then reapply the new pct set .... command. Although I believe all this is not necessary - since as long as you used the same device (dev0 ?) both times, & then restarted the LXC, it will simply have been replaced.

In any case please provide, as already requested, the output for (from host):
readlink /dev/ups0

readlink -f /dev/ups0

Good luck.

the command: readlink /dev/ups0 doesn't show anything, readlink -f /dev/ups0 shows "/dev/ups0"

 

[enry86cami]

Replying to my own query - I found the command in the docs! Its with the --delete <string> parameter. So in your case that would be:
pct set VMID --delete dev0 (if you used dev0 originally, I'm not sure) & then reapply the new pct set .... command. Although I believe all this is not necessary - since as long as you used the same device (dev0 ?) both times, & then restarted the LXC, it will simply have been replaced.

In any case please provide, as already requested, the output for (from host):
readlink /dev/ups0

readlink -f /dev/ups0

Good luck.

Originally I used:
pct set 105 --dev0 path=/dev/bus/usb/001/012
and after:
pct set 105 --dev0 path=/dev/ups0

 

[gfngfn256]

when the usb path changes I modify only the line: - /dev/ups0

What did you use before?

 

[gfngfn256]

From the LXT container what does the following show:
ls /lib/udev/devices -al

 

[enry86cami]

What did you use before?

/dev/bus/usb/001/012

 

[enry86cami]

From the LXT container what does the following show:
ls /lib/udev/devices -al

inside udev folder there isn't devices

 

[gfngfn256]

OK you have a rather complicated setup. You are running a docker inside an LXC.

(I must be honest, I also run a NUT server, but I have it inside the Proxmox host. Yes I know its not ideal to tamper too much with the host, but I find that with something that is totally dependent on a specific USB device, I'm not going to go down the rabbit hole of USB passthrough etc.)

But back to your problem, let's try changing the Udev rule & see if it helps. So lets try this:

nano /etc/udev/rules.d/50-apcups.rules

SUBSYSTEM=="usb", ATTRS{idVendor}=="051d", ATTRS{idProduct}=="0002", SYMLINK+="ups0", GROUP="100000", MODE="0666"

#save & exit

udevadm control --reload

udevadm trigger

Then start up LXC & see what happens.

 

[enry86cami]

now, when the USB path changes, the LXC container doesn't start, this is the error:
"TASK ERROR: Device /dev/bus/usb/001/012 does not exist"
The LXC container starts again if I type: pct set 105 --delete dev0

Maybe I have to find an easier solution, if I install NUT on proxmox host only UDEV rule is needed?

 

[gfngfn256]

if I install NUT on proxmox host only UDEV rule is needed

I have the NUT server installed on host - I have never needed even a UDEV rule.