[SOLVED] /dev USB permissions getting reset after a reboot

FormBurden

New Member
Jan 6, 2022
7
0
1
32
I'm doing a Home Assistant USB pass-through/port mapping on a USB for a ZigBee USB stick on my HA container.

These are my LXC settings for HA
Code:
unprivileged: 1
lxc.cgroup2.devices.allow: c 189:* rwm
lxc.mount.entry: /dev/bus/usb/001/003 dev/bus/usb/001/003 none bind,optional,create=file
lxc.cgroup2.devices.allow: c 188:* rwm
lxc.mount.entry: /dev/ttyUSB0 dev/ttyUSB0 none bind,optional,create=file
lxc.mount.entry: /dev/ttyUSB1 dev/ttyUSB1 none bind,optional,create=file

And at least from my knowledge (could be a better solution?) I have to chown 100000:100000 to /dev/ttyUSB0 and
/dev/bus/usb/001/003

When I restart Proxmox, the permissions under the root account (not in the container, Proxmox itself) get reset to group: "
dialout" .

How can I get this to stop every reboot? There some kind of setting/config I can alter so it persists reboots?

Thanks~!
 
Proxmox runs on debian bullseye which uses systemd, so it should suffice to put create a file /etc/tmpfiles.d/ttyusb.conf with these lines:

z /dev/ttyUSB0 660 100000 100000 z /dev/bus/usb/001/003 664 100000 100000

That should to the trick.
 
Proxmox runs on debian bullseye which uses systemd, so it should suffice to put create a file /etc/tmpfiles.d/ttyusb.conf with these lines:

z /dev/ttyUSB0 660 100000 100000 z /dev/bus/usb/001/003 664 100000 100000

That should to the trick.
Hi there, sadly, this did not work after a reboot. Not sure if you may need to re-look at the syntax or maybe an outdated method.
 
That is strange, I am using something similar for my ntp reference clock.

Does the command "systemctl status systemd-tmpfiles-setup-dev.service" give you any error messages? That is the systemd service that handles these config files. By the way, the filename really has to end in ".conf", all other files would be ignored.

Also, you don't have to reboot to try this, simply doing "systemctl restart systemd-tmpfiles-setup-dev.service" applies the changes.
 
Hi again,

so there are no error messages on the "status", I tried the "restart" and it does apply the settings correctly. But after a reboot, the permissions goes back to root and group is dialout. The temptfiles service doesn't seem to apply it when a reboot happens, but once I restart it, the permissions get applied. Anything else I could do?
 
Oops, I just looked it up - the tmpfiles-service is run before devices are created, so this method cannot work for you. Sorry. :) Fortunately, there is a simple alternative. Create this file as "usb_owner.service" (or something like that):

[Unit] Name=Set USB ownership [Service] Type=oneshot ExecStart=chown 100000:100000 /dev/ttyUSB0 /dev/bus/usb/001/003 [Install] WantedBy=multi-user.target

Then run "systemctl daemon-reload; systemctl start usb_owner.service" to check if it sets the ownership correctly, and if it does, enable it with "systemctl enable usb_owner.service".
 
I think the more typical way to do this is to use udev rules. Or at least that's what I do for my UPS management container. I created the following file:

Code:
/etc/udev/rules.d/50-apcups.rules
SUBSYSTEMS=="usb", KERNEL=="hiddev*", ATTRS{idVendor}=="051d", ATTRS{idProduct}=="0002", GROUP="100000", MODE="0666"

udev rules have the advantage of applying/running all the time, not just at boot.
 
Last edited:
  • Like
Reactions: Chris
Does this also modify the /dev/bus/usb/xxx/yyy entry? I'm using udev for a similar purpose, with setfacl instead of modes to give full access to my non-root user to a specific USB device, but I never needed to access the bus address directly. That would be useful. I'm definitely no udev guru, so I tend to tread lightly around udev rules.
 
Does this also modify the /dev/bus/usb/xxx/yyy entry? I'm using udev for a similar purpose, with setfacl instead of modes to give full access to my non-root user to a specific USB device, but I never needed to access the bus address directly. That would be useful. I'm definitely no udev guru, so I tend to tread lightly around udev rules.
This would modify permissions only for the endpoint that matches the rule spec (SUBSYSTEMS, KERNEL, PID, VID). The Bus/device IDs can change based on where the device is plugged in (or even after a reboot? Not sure), so I'd avoid depending on them. The way I understand the hierarchy is that the "parent" device lives in /dev/bus/usb/xxx/yyy, but any endpoints land wherever the kernel decides based on endpoint type (tty, hid, etc). My rule above matches the "child", which only applies to /dev/usb/hiddevX.

udev rules require some digging to figure out how to match your device (and not others). Check out the udevadm info -a /dev/path/to/thing command. It will start with a child device and walk up the tree. You can decide which attributes to match against.
 

About

The Proxmox community has been around for many years and offers help and support for Proxmox VE, Proxmox Backup Server, and Proxmox Mail Gateway.
We think our community is one of the best thanks to people like you!

Get your subscription!

The Proxmox team works very hard to make sure you are running the best software and getting stable updates and security enhancements, as well as quick enterprise support. Tens of thousands of happy customers have a Proxmox subscription. Get yours easily in our online shop.

Buy now!