Permission error in docker

[rt400]

Hi, i work with your README and i get error

        ERROR: '/etc/nut/ups.conf' mode is too permissive.
        
            recommended permissions: 0440
        
            recommended owner:uid=100(nut) gid=101(nut) groups=101(nut),14(uucp),101(nut)
        
        
        
        current permissions:
        
          File: /etc/nut/upsd.users
        
          Size: 118       	Blocks: 8          IO Block: 4096   regular file
        
        Device: 10302h/66306d	Inode: 10889818    Links: 1
        
        Access: (0440/-r--r-----)  Uid: ( 1000/ UNKNOWN)   Gid: ( 1000/ UNKNOWN)
        
        Access: 2021-11-18 14:55:24.000000000
        
        Modify: 2021-11-18 14:43:18.000000000

any idea how to fix it ?

[gpdm]

Hi,

Did you create your own set of config files and mount them to the Docker container, i.e. by passing the

  -v /path/to/nut-config:/etc/nut

argument to Docker?

If yes, then easiest fix to do on your host, i.e. the /path/to/nut-configfile location, do something like:

cd /path/to/nut-config
chmod 0440 ups.conf upsd.conf upsd.users
chown 100:101 ups.conf upsd.conf upsd.users

Replace /path/to/nut-config by the actual path location, where you stored your config files.

Let me now if this helps.

-GP

[gpdm]

README updates, fixed in

• fb4ad933d6aa9c87130a42a66b4b9d0599ad9d85
• fcdd0123c8d53ab9cec3174e042fe99f9a6c3a50

[rt400]

thanks for your reply. i did that but still same error. why you have to check it ? can your remove this checking ? also do you have a docker-compose version ?

[rt400]

if i run with 100:100 its work but the driver failed to load

[gpdm]

why you have to check it ? can your remove this checking ?

Well, that's a security thing, permisions should never be too permissive as a general rule.

And AFAIK, the NUT upsd daemon will fail to start if permissions are incorrect.

So the pre-check is there as a safety net for both situation, making sure the permissions are right, and preventing obsure startup errors.

also do you have a docker-compose version ?

Not currently, but it would propably look something like this:

version: "3.7"

services:
  upsd:
    image: gpdm/nut-upsd:latest
    # privileged: true
    volumes:
      - vol.nut-upsd.upsd.nut:/etc/nut
    ports:
      - "3493:3493"
    networks:
      - default

volumes:
  vol.nut-upsd.upsd.nut:

That's missing the entire privileged and cgroup stuff though, I would need to investigate this first.

if i run with 100:100 its work but the driver failed to load

That's possibly because of missing access to the device tree. As noted, either run in priviliged mode (lesser secure), or do the device mapping route (better security).

The container must have access to /dev/bus/usb/ in one way or the other to load the driver and gain exclusive control for the UPS.

[rt400]

i set like this:

    image: gpdm/nut-upsd:latest
    container_name: Nut-Ups
    restart: always
    ports:
      - 3493:3493
    devices:
      - /dev/bus/usb/001/005
    restart: always
    volumes:
      - ./config/:/etc/nut/
      - /dev/bus/usb:/dev/bus/usb
      - /etc/localtime:/etc/localtime
    # privileged: true
    network_mode: bridge

but still get error :

*** NUT upsd startup ***

Starting up the UPS drivers ...

Network UPS Tools - UPS driver controller 3.8.0-3220-g866b921892

Network UPS Tools - Megatec/Q1 protocol USB driver 0.12 (3.8.0-3220-g866b921892)

No supported devices found. Please check your device availability with 'lsusb'

and make sure you have an up-to-date version of NUT. If this does not help,

try running the driver with at least 'subdriver', 'vendorid' and 'productid'

options specified. Please refer to the man page for details about these options

(man 8 blazer_usb).


Driver failed to start (exit status=1)

ERROR on driver startup.

[jimklimov]

Cheers, I wonder if the problem is with permissions for the USB device (normally the OS would have a handler to grab everything-USB, and then udev/devfs/upower/... rule sets to assign the device node owner and permissions so the NUT driver run-time account may use that - 100:101 in this case if the host-container IDs are mapped the same way). "Traditional" NUT packages include the rule files for several frameworks, maybe you'd have to apply those on the host.

Also wondering if you can start the driver with more debugging in the container (pass several -D options to its binary like blazer_usb in this case) to learn what it reports as seen or forbidden to see. For "Qx" protocol devices, try also nutdrv_qx (especially if trying NUT builds from source) as the newer effort which combines older related drivers into sub-drivers under a common framework. And specifying subdriver may be needed if guesswork does not work, as well as vendorid, productid, bus, maybe even string vendor/product values, can help the driver identify the device it has to handle (more so for systems with several USB UPSes, but may also be needed to help pick the subdriver right).

Finally, the version there looks weird - NUT is not up to "3.8.0" yet ;) Wondering if it is possible to twist this project into building containers along with builds of NUT from source, to test the latest abilities...

[gpdm]

@jimklimov

Finally, the version there looks weird - NUT is not up to "3.8.0" yet ;) Wondering if it is possible to twist this project into building containers along with builds of NUT from source, to test the latest abilities...

The second version referenced is the OS build release, originating from Alpine linux, which serves as the basis to build this container.

I.e. on a a current 3.15 Alpine container build, you'd get to see something like this, i.e. 3.15.0_alpha...

*** NUT upsd startup ***
Starting up the UPS drivers ...
Network UPS Tools - UPS driver controller 3.15.0_alpha20210804-3402-gced1683082
Network UPS Tools - Generic HID driver 0.41 (3.15.0_alpha20210804-3402-gced1683082)

This has nothing to do with the upstream release of NUT, which is currently 2.7.4.

[gpdm]

@jimklimov

Also wondering if you can start the driver with more debugging in the container (pass several -D options to its binary like blazer_usb in this case) to learn what it reports as seen or forbidden to see. For "Qx" protocol devices, try also nutdrv_qx (especially if trying NUT builds from source) as the newer effort which combines older related drivers into sub-drivers under a common framework. And specifying subdriver may be needed if guesswork does not work, as well as vendorid, productid, bus, maybe even string vendor/product values, can help the driver identify the device it has to handle (more so for systems with several USB UPSes, but may also be needed to help pick the subdriver right).

I didn't build that functionality in to support dynamic startup options. The startup script https://github.com/gpdm/nut/blob/master/nut-upsd/files/startup.sh though has already a -D in there by default:

#65 exec /usr/sbin/upsd -D || { printf "ERROR on daemon startup.\n"; exit; }

I believe this could be easily enhanced to accept dynamic arguments as well.

[gpdm]

@jimklimov

as per 11b240a

implement dynamic arguments passed to upsd, to allow increasing verbosity, i.e. by executing something like

docker run -it --rm -v `pwd`/files/etc/nut:/etc/nut nutupsd -D -D -D

[jimklimov]

Nice! Also note that in current NUT master branch there is now support for debug_min config file settings for daemons (drivers, upsd, upsmon) to bolt and change debugging that way instead of hacking start-up method scripts.

But that is not part of a release yet, so not packaged...

[gpdm]

It's so very old, closing the issue.

New release 0.8.2 includes some fixes and changes discussed in this issue: https://github.com/gpdm/nut/compare/0.8.1...0.8.2

Current Docker rebuild on Alpine has NUT 2.8.2 now included from upstream.

https://hub.docker.com/repository/docker/gpdm/nut-upsd/general

[builder555]

I'm running into the same issue:

nut-upsd  | *** NUT upsd startup ***
nut-upsd  | ERROR: '/etc/nut/ups.conf' mode is too permissive.
nut-upsd  | 	recommended permissions: 0440
nut-upsd  | 	recommended owner:uid=100(nut) gid=101(nut) groups=101(nut),101(nut)
nut-upsd  |
nut-upsd  |
nut-upsd  | current permissions:
nut-upsd  |   File: /etc/nut/upsd.users
nut-upsd  |   Size: 2319      	Blocks: 9          IO Block: 2560   regular file
nut-upsd  | Device: 2ah/42d	Inode: 438307      Links: 1
nut-upsd  | Access: (0400/-r--------)  Uid: (  100/     nut)   Gid: (  101/     nut)
nut-upsd  | Access: 2025-02-09 02:05:40.463364823 +0000
nut-upsd  | Modify: 2025-02-09 02:05:40.463364823 +0000
nut-upsd  | Change: 2025-02-09 02:06:24.373277364 +0000

my docker-compose.yml:

version: '3.8'

services:
  nut-upsd:
    image: gpdm/nut-upsd:latest
    restart: unless-stopped
    container_name: nut-upsd
    ports:
      - "3493:3493"
    volumes:
      - ./config/:/etc/nut/
    devices:
      - /dev/bus/usb/001/002

and the config files:

# ls -aln ./config/

total 19
drwxr-xr-x 2   0   0    5 Feb  8 21:05 .
drwxr-xr-x 4   0   0    5 Feb  8 21:27 ..
-r-------- 1 100 101 9047 Feb  8 21:05 ups.conf
-r-------- 1 100 101 7363 Feb  8 21:05 upsd.conf
-r-------- 1 100 101 2319 Feb  8 21:05 upsd.users