FIM events fro NFS not reporting

[Veera]

Hi Team,

We have enabled Syscheck/FIM monitoring for NFS filesystems with realtime=no and have been monitoring for the past 3 days, but no FIM events have been reported so far.

Apart from frequent “Permission denied” warnings for certain NFS paths (such as artifacts and snapshots), there are no clear logs indicating why the Syscheck scan is completing without generating events.

The Syscheck schedule is configured to run every 12 hours, however no events have been generated to date.

  What are the best commands or methods to validate the scan progress?
Is there a way to confirm whether FIM events will eventually be generated, or if the scan has failed to complete/collect data and will never report events?
Additionally, is there a way to identify which NFS files/directories are currently being scanned and whether the scan population is still dynamically growing?  

[juan.c...@wazuh.com]

Hi Veera. You can find out most of what you're looking for in the syscheck logs. You can acces them inside `/var/ossec/logs/ossec.log` . You should be able to grep for syscheck only messages: `cat /var/ossec/logs/ossec.log | grep syscheckd`.

At agent startup time, the logs will show you which files and directories are being scanned. You'll see messages like these ones: `2026/01/13 12:30:19 wazuh-syscheckd: INFO: (6003): Monitoring path: '/home/juan/fim_tests', with options 'size | permissions | owner | group | mtime | inode | device | hash_md5 | hash_sha1 | hash_sha256 | scheduled'.
And: `2026/01/13 12:30:19 wazuh-syscheckd: INFO: (6206): Ignore 'file' entry '/etc/mtab'`

If the agent startup has happened days ago, these logs have probably been rotated and you'd not be able to see them in that file. You can restart the agent: `systemctl restart wazuh-agent` and you should see the syscheckd logs that show which files are being monitored. Or look for the rotated logs inside `/var/ossec/logs/`.

If you look for `wazuh-syscheckd: INFO: (6008): File integrity monitoring scan started.` messages. You should be able to see if there are any errors reported during the scan.

It's you're not sure if any of the NFS paths contain files that might have changed, you can force a change by creating a new file there and restarting the agent. As soon as it restarts, it will trigger a fim scan and you should be able to see the events reported in your dashboard.

If after doing that you don't see anything you might have some problem in your configuration or a permission issue where the Wazuh agent might not be able to access your NFS directories. But if that is the case you should see errors in `ossec.log` related to syscheckd. Also feel free to share the syscheckd portion of your `ossec.conf` to see if there are any invalid configurations in your settings or NFS paths.

[Veera]

Hi,

Thanks for the inputs and analysis

Yes , whenever the agent is restarted or config changes , the  (6003) and 6008  messages , printed successfully.

However ,  6009 was never printed (was happened for a small volume once in the same server) .

It's you're not sure if any of the NFS paths contain files that might have changed, you can force a change by creating a new file there and restarting the agent. As soon as it restarts, it will trigger a fim scan and you should be able to see the events reported in your dashboard.

Yes . unsure about the  files that might have changed, however  creating test files and restarting agents don't helped in generating events.

I have attached here the syscheck settings and  logs for your view. 

[juan.c...@wazuh.com]

Hi, I see  from your config that you're monitoring every  single file from all of your NFS filesystems:
`<directories check_all="yes" realtime="no" recursion_level="320">/mnt</directories>`

The fact that you're not seeing the FIM scan ended messages (6009) suggests that the scan never manages to complete. This is likely because of the huge amount of files you're likely tracking over a network connection. I see you've opened up this other thread where you discuss this file systems having +25TB of data. I would suggest continuing the conversation in this other thread to better understand your requirements for monitoring these NFS file systems, as monitoring this amount of files over NFS might be too slow for your needs.