[Error] V-58000-500-0003: Unable to open network share. An internal error occurred. Restarting the appliance may solve this issue.

There will be times when you need to transfer files in and out of NetBackup Appliance server, for instance, to install hotfixes, transfer log files for troubleshooting, copy script files and so on.

NetBackup Appliance CLISH has a convenient way to open network share so you can transfer files from and to your Windows PC (or Linux/UNIX if that’s what you have). The steps are mentioned in these technotes:
https://www.veritas.com/support/en_US/article.100023444
https://www.veritas.com/support/en_US/article.100010965

Recently I encountered an issue where opening Logs share returned the following error:

[Error] V-58000-500-0003: Unable to open network share. An internal error occurred. Restarting the appliance may solve this issue.

At that time, I narrowed down the issue to invalid entries in /etc/exports file.

nbu-appliance:/etc # cat exports

#default exports establish by NetBackup
#/inst/client *(ro,async,no_subtree_check)
#default export for logs
#/log *(ro,async,no_subtree_check)
#default export for incoming_patches
#/inst/patch/incoming *(all_squash,rw,sync,no_subtree_check)
#default export for incoming_plugins
#/inst/plugin/incoming *(all_squash,rw,sync,no_subtree_check)
#default export for LiveUp
#/inst/patch/client *(ro,async,no_subtree_check)
/log *(ro,async,no_subtree_check)
/inst/patch/incoming *(all_squash,rw,sync,no_subtree_check)
#default export for logforwarding
#/inst/logforwarding *(all_squash,rw,sync,no_subtree_check)

Notice the duplicate entries in bold red. After removing them and running exportfs -ra (so the /etc/exports is re-read), I was able to open the Logs share.

Using ProcMon to troubleshoot NFS connection issue

I recently stumbled upon an issue where Active Directory granular backup failed with unable to initialize nbfsd error.

NBFSD or NetBackup File System Daemon is a custom written NFS server that lives in NetBackup media server. Refer to this article for more detail.

One common reason for a failed NBFSD connection is firewall blocking TCP port 111 and 7394 between NetBackup media server and the client. The client in my case was a Windows Domain Controller. We confirmed that there was no firewall blocking these ports, which means the problem was most likely on the endpoints (media server or client). It could not be the media server, though, because other clients were backing up fine, so problem was most likely on the client.

Client for NFS module was configured correctly on the client using this procedure.

We ran a quick nbfsd connection test , which should theoretically reveal 2 connections being established between the media server and the client:
1. Client’s random port <=> Media Server’s nbfsd port (7394)
2. Client’s random port <=> Media Server’s SUNRPC port (111)

The easiest way to see these connections is by using Mark Russinovich’s ProcMon. What you need to do is click Filter > Filter… and add the following 2 conditions (make sure colon is added before 7394):
Path contains sunrpc
Path contains :7394

After clicking OK, you should see something like this:

In customer’s case, the highlighted connection never occurred. That means there was problem with the Client For NFS module. After removing and re-adding the Client for NFS module, granular backup started working.