NetWorker: NMC lacks details in any tab. Daemon has error Received no results for NSR Storage Node resource query for X on server X

Host file entry had been updated since NetWorker last started with wrong info.

Following NetWorker restart or server reboot, have both these issues:
NMC has no details in any tab AND daemon has error nsrd RAP warning Received no results for NSR Storage Node resource query for <name> on server <name>

nsrwatch shows server appears to be working normally

Both issues are a symptom of a server name change from FQDN to short name or vice versa.

• When EMC support saw the issue, the error: nsrd RAP warning Received no results for NSR Storage Node resource query for <name> on server <name> started following a NetWorker restart.
• <name> was the short name of the server, and the storage node it's complaining about is for the NW server itself.
• On inspection of the storage node resource for the backup server using nsradmin, the node was defined as the FQDN, as in name.domain.com - a node resource cannot have an alias (although a client can).

Generally, host-files should not be necessary if DNS is working correctly.

• In the case EMC support worked on, DNS lookup was correct and returned the FQDN as expected.
• /etc/hosts had an entry for the NW server as: [IP address] > [short name] > [FQDN]
• Removing (or hashing out) the host entry for the NW server (so it only used DNS for name resolution), then re-starting NetWorker resolved issue

Once NW re-started, the error 'nsrd RAP warning Received no results for NSR Storage Node resource query for <name> on server <name>' was no longer present, and once GST had been re-started, NMC worked normally again.

This is because NetWorker was picking up the short name for itself from the host entry, and causing some name resolution issues, seen as the storage node error and NMC issues.

If host file entries are preferred, changing to '[IP address] > [FQDN] > [short name]' would resolve this.

It's possible (in the recent case) that:

• The incorrect host entry (or another factor) was made after NetWorker was originally configured, hence NetWorker was using the FQDN for it's storage node resource and the GST database.
• That an OS config change or patch may have changed the lookup order from DNS first to hostfile first

NetWorker would not have been impacted until re-started.