ACCESS-DENIED
victorclaessen opened this issue · comments
Hi,
I am trying this for the first time on a new server, I installed the latest version 2.8.2 on ESXi 8.0 and configured the UserVars, trying to connect to the nut server running on my homeassistant installation. I am able to connect from other machines to that nut server, but not from ESXi.
ESXI configuration:
UserVars.NutUpsName = homeassistant
UserVars.NutUser = esxi
UserVars.NutPassword = mypassword
but I get this error in ESXi's syslog.log:
[root@esxi02:/opt/nut/etc] grep upsmon /var/log/syslog.log | tail
2024-04-24T21:57:03.005Z In(30) upsmon[3238608]: Startup successful
2024-04-24T21:57:03.005Z In(30) upsmon[3238608]: Warning: running as one big root process by request (upsmon -p)
2024-04-24T21:57:03.015Z Db(31) upsmon[3238608]: upsnotify: failed to notify about state 2: no notification tech defined, will not spam more about it
2024-04-24T21:57:03.019Z Er(27) upsmon[3238608]: Login on UPS [fsp@homeassistant] failed - got [ERR ACCESS-DENIED]
But if I run upsc, I can successfully connect (without supplying credentials???)
[root@esxi02:/opt/nut/etc] /opt/nut/bin/upsc fsp@homeassistant
battery.charge: 100
battery.energysave: no
battery.packs: 1
battery.protection: yes
battery.runtime: 5820
battery.voltage: 82.10
battery.voltage.nominal: 72.0
...etc
Is there any obvious mistake I am making?
I don't understand why upsc can connect (without credentials) and upsmon cannot.
Hi, sorry for the late answer, I was not available last week. This is a credential issue. Check that UserVars.NutUser and UserVars.NutPassword contain exactly what's declared on the NUT server. Did you restarted the nut server since you added the user declaration ? I am not sure that NUT server can dynamically re-read the configuration if it has been changed.
upsc does not use credentials to get the UPS informations but upsmon needs to authenticate to get the UPS events.
This is not an issue. Don't open issues to request support for your configuration.
I think there is an issue as well, I do encounter the same log entries although the nut client seems to be connected and working.
I installed the Client over VIB.
I also cannot run upsc because of root execution permission restrictions in ESXi 8 - so no testing of the connection possible.
So there seems to be an issue with the installion over esxcli causing restricted permissions to the binaries and resulting in even upsnotify not working as expected.
I can't see any problem running upsc from root account on ESXi 8.
Are you using your own build of the provided offline_bundle binary ?
No, I just downloaded the latest offlinebunde, changed the acceptance Level to CommunitySupported and installed the VIB via esxcli.
[root@discovery:/opt/nut/bin] ./upsc ups@192.168.200.151
Error: Access denied
EDIT: Forget it: it was my fault... :)
But anyway... I have two machines. I did the same on both but only one of them is working as it should:
2024-05-16T08:16:38.756Z No(29) upsmon[2315782]: Communications with UPS ups@192.168.200.151 established
the other one shows the same problem as stated above:
2024-05-16T08:22:01.769Z In(30) upsmon[14683198]: Startup successful
2024-05-16T08:22:01.769Z In(30) upsmon[14683198]: Warning: running as one big root process by request (upsmon -p)
2024-05-16T08:22:01.773Z Db(31) upsmon[14683198]: upsnotify: failed to notify about state 2: no notification tech defined, will not spam more about it
OK, glad that you found the issue. I was trying to reproduce your error message without any success on my ESXi8 test lab.
For your information :
The warning about the "one big root process" cannot be avoided. On older upsmon versions (before 2.1.0), process was running as "daemon" but this account has been removed by VMware on ESXi and I had to use root. CommunitySupported VIBs cannot add accounts. You can also ignore the warning about upsnotify state 2.
You can't use custom TCP port for upsmon on ESXi, the port must be the default 3493 port. This is required by the hardcoded firewall rule for upsmon on ESXi.
I just would like to know why one installation works flawless and shows a successful connection, and the other one spits out these warnings and doesn't show if it's successfully connected or not.
The message "Communication with UPS xxx@xxx established" is not a client but a server event. This is written in client syslog each time that the NUT server sends the COMMOK event, usually when it re-establishes the communication with the UPS after a connection loss.
So you must not rely on this message to check your communication with the NUT server. On a working configuration you should never see such a message.
Hi, just to note. I'm having this exact issue, from SSH I can access UPS info, but the daemon cannot. Says Access denied.
Credentials are correctly set in the variables, so something else is causing it :)