this is the docker-compose.yml: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
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-stoppedthe command: readlink /dev/ups0 doesn't show anything, readlink -f /dev/ups0 shows "/dev/ups0"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 useddev0originally, I'm not sure) & then reapply the newpct 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: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 useddev0originally, I'm not sure) & then reapply the newpct 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.
What did you use before?when the usb path changes I modify only the line: - /dev/ups0
inside udev folder there isn't devicesFrom the LXT container what does the following show:
ls /lib/udev/devices -al
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 triggerI have the NUT server installed on host - I have never needed even a UDEV rule.if I install NUT on proxmox host only UDEV rule is needed
pct set <vmid> --dev0 path=/dev/$(readlink /dev/coral -n | sed 's|\.\.|/dev|g')/dev/usb/bus/XXX/XXX device, so upon reboot it fails again./etc/pve/lxc/XXX.conf file, so that it "reads the link" upon starting the LxC, but it fails since you can't pass bash within that YAML config.lxc.cgroup.devices.allow: c 189:* rwm
lxc.mount.entry: /dev/ups dev/bus/usb/001/001 none bind,optional,create=file/dev/ups alias into a /dev/bus/usb/001/001 device inside the LxC container. But the problem persists, since /dev/bus/usb/001/001 is still unrecognized by the LxC as a device (since its a symlink).init.d script that runs every reboot and updates the new /dev/bus/usb/XXX/XXX path with something like:pct set <vmid> -del dev0 && pct set <vmid> --dev0 path=/dev/bus/usb/$(lsusb| grep 051d:0002 | cut -d ':' -f1 | cut -d " " -f2,4 | sed 's| |/|g')Something that may be worth looking into - along your idea - is using a hookscript (can be written in Bash) for that LXC to set that USB dev at the pre-start stage.But not even sure if that script would successfully ran after initializing proxmox (so that pct works properly) but before containers are started.
Any other ideas?
But if I understand correctly, hookscripts are executed within the guest, right?Something that may be worth looking into - along your idea - is using a hookscript (can be written in Bash) for that LXC to set that USB dev at the pre-start stage.
Hookscripts are rather thinly documented by Proxmox docs - so you will have to research this idea.
Wrong. They are run on the host, & you can run what you like.But if I understand correctly, hookscripts are executed within the guest, right?
/usr/share/pve-docs/examples/guest-example-hookscript.plcat /usr/share/pve-docs/examples/guest-example-hookscript.pl
#!/usr/bin/perl
# Exmple hook script for PVE guests (hookscript config option)
# You can set this via pct/qm with
# pct set <vmid> -hookscript <volume-id>
# qm set <vmid> -hookscript <volume-id>
# where <volume-id> has to be an executable file in the snippets folder
# of any storage with directories e.g.:
# qm set 100 -hookscript local:snippets/hookscript.pl
use strict;
use warnings;
print "GUEST HOOK: " . join(' ', @ARGV). "\n";
# First argument is the vmid
my $vmid = shift;
# Second argument is the phase
my $phase = shift;
if ($phase eq 'pre-start') {
# First phase 'pre-start' will be executed before the guest
# is started. Exiting with a code != 0 will abort the start
print "$vmid is starting, doing preparations.\n";
# print "preparations failed, aborting."
# exit(1);
} elsif ($phase eq 'post-start') {
# Second phase 'post-start' will be executed after the guest
# successfully started.
print "$vmid started successfully.\n";
} elsif ($phase eq 'pre-stop') {
# Third phase 'pre-stop' will be executed before stopping the guest
# via the API. Will not be executed if the guest is stopped from
# within e.g., with a 'poweroff'
print "$vmid will be stopped.\n";
} elsif ($phase eq 'post-stop') {
# Last phase 'post-stop' will be executed after the guest stopped.
# This should even be executed in case the guest crashes or stopped
# unexpectedly.
print "$vmid stopped. Doing cleanup.\n";
} else {
die "got unknown phase '$phase'\n";
}
exit(0);Oh nice, then it might indeed be a better approach than "init.d", to ensure Proxmox is up (and pct actions likeWrong. They are run on the host, & you can run what you like.
set can already be invoked), but that they run before trying to start the containers.ttyUSB0 and has a device under /dev/serial/by-id/xxxx but the rest of them do not, and are only accessible via /dev/bus/usb/XXX/XXX. /dev/serial/by-id, I could just passthrough these paths and forget about all this mess.The exact reasoning why I suggested it.then it might indeed be a better approach than "init.d", to ensure Proxmox is up
You'll still have to test - with your own setup - if they are actually usable for your requirements.but that they run before trying to start the containers
Not sure what you expected?Sad that Proxmox does not provide a better alternative.
Different buses/adapters/drivers - the land of Linux!I'm still wondering why one USB (front one) is properly detected asttyUSB0and has a device under/dev/serial/by-id/xxxxbut the rest of them do not, and are only accessible via /dev/bus/usb/XXX/XXX.
It would be ideal that proxmox offered a way to passthrough USB devices byNot sure what you expected?
vendorId/productId/serial, for example.I know.. I think it's guess the main reason is my Beelink SER8 has 2 USB controllers, one for the front port and another one for the back ports.Different buses/adapters/drivers - the land of Linux!
/dev/serial/by-id/xxx and avoid any issues with bus/device id changing.That & the fact that Proxmox is a HV environment where naturally the server is designed to be up 24/7, so hardly ever rebooted - and when it is its done manually by a professional IT system administrator who can deal with any of this (& more!) on the go.I guess its the main reason Proxmox hasn't prioritized or implemented yet the above, since most users will be able to map the/dev/serial/by-id/xxxand avoid any issues with bus/device id changing.
I've worked myself as system administrator, and if you can save time to sysadmins every time they have to do maintenance with a small and simple feature, why shouldn't you implement it.That & the fact that Proxmox is a HV environment where naturally the server is designed to be up 24/7, so hardly ever rebooted - and when it is its done manually by a professional IT system administrator who can deal with any of this (& more!) on the go.
We use essential cookies to make this site work, and optional cookies to enhance your experience.