- 6 minutes to read

FAQ and Troubleshooting the Nodinite File folder Monitoring Agent

This page provides answers and troubleshooting steps for common issues with the Nodinite File folder Monitoring Agent. Learn how to resolve DFS and NFS errors, configure monitoring, and get expert support for seamless integration monitoring.

  • ✅ Step-by-step troubleshooting for DFS and NFS
  • ✅ PowerShell scripts for quick diagnostics and setup
  • ✅ Clear guidance for configuration and access rights
  • ✅ Direct support options for fast resolution

If you have any issues that you cannot solve, contact our Support or send us an email at support@nodinite.com

How do I add File folders to monitor with Nodinite?

Adding any number of File folders to monitor with Nodinite is simple and requires only the proper access rights. Follow the steps detailed in the Configuration user guide.

Info

You must be part of the Administrators Role.

Can I get alerted when no files have arrived (Non-Events)?

The Nodinite File Folder Monitoring Agent works by polling the target folder at a configured interval. Because of this polling-based design, the agent can only report on what it observes at the moment of each poll — it has no reliable way to detect the absence of expected files arriving within a given time window.

Warning

Non-event monitoring (alerting when something expected did not happen) is not supported directly by the File Folder Monitoring Agent due to its polling nature. There is no guarantee that a missed arrival will be detected.

Why polling prevents non-event detection

A polling agent snapshots the current state of a folder at each interval. It can answer:

  • ✅ Are there files older than X minutes?
  • ✅ Are there more than N files present?
  • ❌ Did an expected file not arrive within the last hour?

The last question cannot be answered reliably — the agent has no knowledge of what should have arrived, only what is present when it polls.

The recommended workaround is to instrument the integration process itself — the application that reads from or writes to the SFTP or file folder — so that it logs activity to Nodinite. Once log records are available, you can use the Non-Events Monitor Agent to raise an alert when the expected log entries do not appear within a defined time window.

This approach shifts the detection responsibility from the passive folder observer to the active integration process:

  1. Configure your SFTP reader/writer process to emit log messages to Nodinite on each successful file transfer.
  2. Set up a Non-Events Monitor rule targeting those log entries.
  3. Define the expected frequency (e.g., at least one file transferred every 60 minutes).
  4. Nodinite will raise an alert if no matching log entry is received within the window.

Info

Need help setting up logging from your integration process? See the Custom Logging guide for details on how to send log records to Nodinite from any application or platform.

DFS Troubleshooting

If you encounter 2662 error status, you are likely not specifying the DFS root path in the folder Configuration.

Verify DFS Share

Use the PowerShell script below as a template to test the availability and configuration of your DFS Share:

Get-DfsnRoot
Get-DfsnFolder -Path "\\$env:COMPUTERNAME\PublicDFS\SharedDocs"

Install/Setup DFS Share

Use the PowerShell script below as a template to set up a DFS Share on a Windows Server host.

# 1. Install DFS Namespace feature
Install-WindowsFeature FS-DFS-Namespace -IncludeManagementTools

# 2. Create the namespace root folder
$namespaceRootFolder = "C:\DFSRoots\PublicDFS"
New-Item -Path $namespaceRootFolder -ItemType Directory -Force

# 3. SHARE the namespace root folder as "PublicDFS"
New-SmbShare -Name "PublicDFS" -Path $namespaceRootFolder -FullAccess "Everyone"

# 4. Create the DFS namespace (Standalone)
New-DfsnRoot -Path "\\$env:COMPUTERNAME\PublicDFS" -TargetPath $namespaceRootFolder -Type Standalone

# 5. Create a folder inside the namespace target folder
$dfsFolderPath = "$namespaceRootFolder\SharedDocs"
New-Item -Path $dfsFolderPath -ItemType Directory -Force

# 6. Share that folder as well
New-SmbShare -Name "SharedDocs" -Path $dfsFolderPath -FullAccess "Everyone"

# 7. Add DFS folder to the namespace
New-DfsnFolder -Path "\\$env:COMPUTERNAME\PublicDFS\SharedDocs" -TargetPath "\\$env:COMPUTERNAME\SharedDocs"

Your DFS namespace is now available at: \\<YourServerName>\PublicDFS\SharedDocs
The physical target is \\NODINITE01\SharedDocs

Remove DFS Share

Use the PowerShell script below as a template to remove the DFS Share previously installed:

# Remove DFS Folder
Remove-DfsnFolder -Path "\\$env:COMPUTERNAME\PublicDFS\SharedDocs" -Force -ErrorAction SilentlyContinue

# Remove DFS Namespace
Remove-DfsnRoot -Path "\\$env:COMPUTERNAME\PublicDFS" -Force -ErrorAction SilentlyContinue

# Remove SMB Shares
Remove-SmbShare -Name "SharedDocs" -Force -ErrorAction SilentlyContinue
Remove-SmbShare -Name "PublicDFS" -Force -ErrorAction SilentlyContinue

# Delete all folders
Remove-Item -Path "C:\DFSRoots" -Recurse -Force -ErrorAction SilentlyContinue

NFS Troubleshooting

Note

Usually, this is a problem related to the firewall. Please review the Prerequisites.

For NFS related issues, review Microsoft's modern guidance in NFS Overview and Deploy Network File System.

If you have problems connecting to the NFS area, follow the steps below to troubleshoot the problem.

Common error 

Could not connect to NFS, error: ONC/RPC portmap failure

Quick checks

  • Verify basic connectivity between the Monitoring Agent host and the NFS server.
  • Verify that firewalls allow required NFS/RPC traffic (typically TCP/UDP 111 and 2049).
  • Verify name resolution (DNS) and that the target IP/FQDN matches your Configuration.
  • Verify that the NFS export exists and that the client host is allowed.

If possible, install the NFS Client feature on the Monitoring Agent host:
NFS Client feature
The NFS Client feature must be installed for NFS monitoring.

Install NFS Client feature with PowerShell

Use the following script to install the NFS client on Windows Server or Windows client OS.

# Windows Server
if (Get-Command Get-WindowsFeature -ErrorAction SilentlyContinue) {
	Install-WindowsFeature -Name NFS-Client -IncludeManagementTools
}
else {
	# Windows client OS (for example Windows 10/11)
	Enable-WindowsOptionalFeature -Online -FeatureName ServicesForNFS-ClientOnly -All -NoRestart
}

Verify RPC/NFS reachability

Use the sample RPCINFO command (replace sample IP address as appropriate):

rpcinfo /p 10.0.1.135

If the connection is successful, you should have the nfs entries listed; otherwise, there is probably an error in the output:
RPCINFO
RPCINFO output showing NFS entries if successful.

Optional lab setup: Create a test NFS share on Windows Server

If you need a controlled lab environment, use the script below on a Windows Server host.

# 1. Install Server for NFS
Install-WindowsFeature -Name FS-NFS-Service -IncludeManagementTools

# 2. Create a local folder for the share
$nfsRoot = "C:\NFS\Demo"
New-Item -Path $nfsRoot -ItemType Directory -Force

# 3. Create NFS share
New-NfsShare -Name "DemoNfs" -Path $nfsRoot

# 4. Allow lab client access (replace with specific hosts/subnets for production)
Grant-NfsSharePermission -Name "DemoNfs" -ClientName "*" -ClientType Host -Permission ReadWrite

Warning

Use restrictive permissions in production. Avoid wildcard client access (*) outside of test environments.

Optional lab setup: Docker-based NFS server for quick testing

For quick local testing, you can run a community NFS server image with Docker (Linux container mode, for example Docker Desktop with WSL2).

docker run -d --name nfs-lab --privileged -e SHARED_DIRECTORY=/exports -v nfsdata:/exports erichough/nfs-server

Then run rpcinfo /p <docker-host-ip> from the Monitoring Agent host.

Note

Container-based NFS is useful for lab validation but should not be treated as a production-grade NFS service.

Next Step