4. My UPS driver program won’t work. I’m starting it as root, and root owns the device, so what’s the problem?

Prev		Next

Answer 1

The drivers drop root privileges long before the serial or USB port is opened. You’ll need to change the permissions on that port so that their new user id can access it. Normally this is nobody, but it may be changed at compile-time by using configure --with-user or in the ups.conf file for driver settings with user=....

Read the error message. If you have a permissions mismatch, then you’ll see something like this:

Network UPS Tools - APC Smart protocol driver 0.60 (1.1.7)
This program is currently running as youruid (UID 1234)
/dev/ttyS2 is owned by user root (UID 0), mode 0600
Change the port name, or fix the permissions or ownership
of /dev/ttyS2 and try again.
Unable to open /dev/ttyS2: Permission denied

Now is a good time to point out that using nobody is a bad idea, since it’s a hack for NFS access. You should create a new role account (perhaps called ups or nut), and use that instead.

Also, scroll down to the "security domains" question to see an even better way of restricting privileged operations. Neither the drivers nor upsd ever need root powers, and that answer tells you how to make it work.

Answer 2

You can also specify a user with user= in the global part of ups.conf(5). Just define it before any of your [sections]:

        user = nut

        [myups]
                driver = mge-shut
                port = /dev/ttyS0

Alternately, you can specify a user= in the driver section.

Note

The driver program runs with the group account(s) associated with that user account in the system, and sets its group ID to the primary group of that account. For serial port access, you may want to add your ups or nut role account to the dialout group on most Linux and Unix systems. The group= setting in ups.conf is for something else: sharing access to socket files used for communications with the upsd data server, which may run as another different user account.

Answer 3

Some other programs that you start may steal the port, so the NUT driver loses a connection (or can never establish one). Revise your device file system node permissions for corresponding USB or serial ports, and group membership for NUT driver daemons and other programs in your system. USB and serial ports might change ownership as the logged-in console user sessions (physically attached virtual terminals) are switched on some OS distributions.

Investigate udev or similar framework to assign access permissions to certain devices on your system, and if you find an offending program that enumerates all ports thus "stealing" them from NUT and other consumers, find a way to configure it with a specific port list that it should use, or to run as a user account that has no access to the ports you want dedicated to NUT.

One user report dealt with WINE emulator used for modem programs, so it was deliberately picking serial port devices and was running as a member of the dialout group. That was an interesting way to shoot oneself in the foot…