<div dir="ltr"><div>One thing that comes to mind is that a few releases ago the conditions to issue this message were refactored, so it would not be printed for each situation where no USB devices could be opened, but only where it actually relates to lack of permissions (all tried devices had EACCESS).</div><div><br></div><div>Another was a discussed, possibly fixed and merged (not sure OTOH), change of reconnection logic to not blindly retry same data points as were seen before (which become obsolete due to kernel-side re-enumeration) but to re-discover devices more diligently.<br><br></div><div>With 2.8.2 baseline, maybe your NUT deployment is just too old on those counts and one or both troubles could have been already resolved in the years since that release.</div><div><br></div><div>Consider following <a href="https://github.com/networkupstools/nut/wiki/Building-NUT-for-in%E2%80%90place-upgrades-or-non%E2%80%90disruptive-tests">https://github.com/networkupstools/nut/wiki/Building-NUT-for-in%E2%80%90place-upgrades-or-non%E2%80%90disruptive-tests</a> and checking if that is the case, please.</div><div><br></div><div>Other than that, it could be argued that as NUT is in the business of monitoring UPSes to provide timely shutdowns in case of power outage, a prolonged data outage is something important that the sysadmin should address (even if by disabling the driver for a known maintenance). That said, I've recently reviewed many drivers for <a href="https://github.com/networkupstools/nut/pull/3541">https://github.com/networkupstools/nut/pull/3541</a> and many of them already generally throttle reconnection notifications (although each one that does - reinvented their own wheel in this regard... something to address in that PR or later). The message you reported comes from an internal library shared by many USB-capable drivers and might not fall under driver-decided log throttling rules though.</div><div><br></div><div>Hope this helps,</div><div>Jim Klimov</div><div><br></div><div><br></div></div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Thu, Jul 23, 2026 at 5:15 AM Robert Nichols via Nut-upsuser <<a href="mailto:nut-upsuser@alioth-lists.debian.net">nut-upsuser@alioth-lists.debian.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Is there a way to prevent the usbhid-ups driver from flooding the system log when a monitored UPS is disconnected from its UCB port. I see a steady stream of messages:<br>
<br>
  usbhid-ups[3480520]: libusb1: Could not open any HID devices: insufficient permissions on everything<br>
<br>
that are posted every 2 seconds until I comment out that device from ups.conf and restart the nut service.<br>
Version is nut-2.8.2-1.el8.x86_64 in Rocky Linux 8.<br>
<br>
-- <br>
Bob Nichols     "NOSPAM" is really part of my email address.<br>
                 Do NOT delete it.<br>
<br>
<br>
_______________________________________________<br>
Nut-upsuser mailing list<br>
<a href="mailto:Nut-upsuser@alioth-lists.debian.net" target="_blank">Nut-upsuser@alioth-lists.debian.net</a><br>
<a href="https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser" rel="noreferrer" target="_blank">https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser</a><br>
</blockquote></div>