ZBX_NOTSUPPORTED: Cannot obtain directory listing. How to solve this?

[cesarsj]

Zabbix Server: 4.0.17
Zabbix Agent in host monitored: 4.0.2

root@zabbixserver:~# zabbix_get -s <ip_agent> -p 10050 -k vfs.dir.size[/dir,,,disk,]
ZBX_NOTSUPPORTED: Cannot obtain directory listing.

[tim.mooney]

Your zabbix_agent is probably running as a non-privileged user, perhaps as a service user like 'zabbix'. That's recommended practice.

If the user & group that the agent is running as cannot read the directory, zabbix_agent will not be able to perform this operation.

What are the permissions on /dir ?

[cesarsj]

Your zabbix_agent is probably running as a non-privileged user, perhaps as a service user like 'zabbix'. That's recommended practice.

If the user & group that the agent is running as cannot read the directory, zabbix_agent will not be able to perform this operation.

What are the permissions on /dir ?

I'll have access to the machine only on Monday, but if I'm not mistaken, it's the owner of a samba group, maybe I can add zabbix to the samba groups, I'll check with my boss, otherwise, I'll leave a script in crontab that will run as root and send the size of the shared directories to a file that will be read by zabbix using the vfs.file.contents key. I also thought if setfacl in the folder would be an option, but I didn't think it was so viable, it would have to be recursive. The script so far seems to be the best idea.

[tim.mooney]

... if I'm not mistaken, it's the owner of a samba group, maybe I can add zabbix to the samba groups, I'll check with my boss, otherwise, I'll leave a script in crontab that will run as root and send the size of the shared directories to a file that will be read by zabbix using the vfs.file.contents key. I also thought if setfacl in the folder would be an option, but I didn't think it was so viable, it would have to be recursive.

I tend to agree. I thought about file ACLs too, but I agree it doesn't scale very well. Adding the zabbix agent user to the samba group would be the least "invasive", if your boss is OK with it.

I also thought about using the capabilities(7) system. It looks like if you set CAP_DAC_READ_SEARCH for the zabbix agent, it would completely bypass any read restrictions (*anywhere*). That's far more dangerous than adding zabbix agent to the samba group or even the setfacl method, so although capabilities(7) are powerful and somewhat granular, it's really not a very good fit for this situation.

The other way that people often solve problems like this is by not using a built-in agent item key, but instead creating a custom item involving "sudo" with the NOPASSWD setting. That might be something to consider, but keep in mind that the entire command has to run and return data within whatever you have set for the timeout (5 seconds, by default). In contrast, your cron method de-couples the script from the item check, so there's no danger of the script running too long if /dir is huge. The only downside is you're reading a "cached" value that's only as accurate as the last time the cron job ran.

Unless you can add the agent to the samba group, I think your solution is probably the best one to this problem.