Troubleshooting Reload Connectivity/Mounting Issues

Reload backup jobs are failing before they can even mount; or, when creating a new post office profile within Reload, the profile test is failing. Knowing how Reload is attempting to mount to the post office directory is a useful troubleshooting step when the Reload backup jobs are failing at the beginning before they can successfully mount or if the post office profile test can't make a connection to the post office. An administrator can go to the command prompt on the Reload box and try to manually mount to the post office.  If it fails here, the administrator knows there is a problem (with the connection, the user credentials, rights, the OS, etc.). Or, in some situations, the post office was moved from one OS platform to another (like from Netware to Linux).  Reload records the platform selection in the profile-specific conf file (e.g., po1.conf).  When changes are made, the new setup is recorded in the conf file without deleting the old information, so now it shows two different platform types and there is confusion as to which is the active setting Reload is using.  The backups that used to work now fail to complete for this post office.  Looking at the agent.log, the mount is failing.

Below are the exact mount commands that Reload is using depending on the platform selection made during the post office profile setup. This is not a comprehensive list since it doesn't include clusters.  The only variation these examples make from what Reload does is the local mount point being set to a temp directory.  In addition, the test mount won't use any timeout and retry values. Be sure to create the local mount point directory before attempting the mount (i.e., /mnt/temp).

Linux (NFS):  mount -v -t nfs [server IP]:[PO server's export path] [mount point]

EXAMPLE: mount -v -t nfs 192.168.1.100:/groupwise/po1 /mnt/temp

Linux (NSS):  ncpmount -S [server name] -A [server IP] -U [user.container] -P [password] -V [NSS volume name]  -o tcp,nonfs -m [mount point]

EXAMPLE: ncpmount -S GWPO1 -A 192.168.1.100 -U admin.gwava -P Testing123 -V VOL1 -o tcp,nonfs -m /mnt/temp

Linux Cluster (NSS):  ncpmount -S [cluster server IP - not the node IP] -A [server IP] -U [user.container] -P [password] -V [volume name]  -o tcp,nonfs -m [mount point]

EXAMPLE: ncpmount -S 192.168.1.100 -A 192.168.1.100 -U admin.gwava -P Testing123 -V VOL1 -o tcp,nonfs -m /mnt/temp

NetWare (NCP):  ncpmount -S [server name] -A [server IP] -U [user.container] -P [password] -V [volume name]/[path to PO]  -o tcp,nonfs -m [mount point]

EXAMPLE: ncpmount -S NW65_SERVER1 -A 192.168.1.100 -U admin.gwava -P Testing123 -V VOL1/grpwise/postoff1 -o tcp,nonfs -m /mnt/temp

NetWare Cluster (NCP):  ncpmount -S [cluster server IP - not the node IP] -A [server IP] -U [user.container] -P [password] -V [volume name]/[path to PO]  -o tcp,nonfs -m [mount point]

EXAMPLE: ncpmount -S 192.168.1.100 -A 192.168.1.100 -U admin.gwava -P Testing123 -V VOL1/grpwise/postoff1 -o tcp,nonfs -m /mnt/temp

Windows (CIFS): mount -t cifs -o username=[admin user],password=[password] noserverino //[server IP]/[shared folder] /[mount point]

EXAMPLE: mount -t cifs -o username=admin,password=Testing123,noserverino //192.168.1.100/groupwise /mnt/temp

Note that the mount commands and parameters are case sensitive and that some parameters have no space between them (e.g., on the CIFS mount, there are no spaces from "username=" all the way to "noserverino".  The only time the next space occurs is between "noserverino" and "//[server IP]..."

When unmounting, Reload uses a "lazy" unmount parameter:  umount -l /mnt/reload/...  A "lazy" unmount simply allows the mount to be unmounted while the OS works on freeing the resources in the background.  This avoids the "device is busy" error condition when unmounting.  According to the umount man (manual): "Detach the filesystem from the filesystem hierarchy now, and cleanup all references to the filesystem as soon as it is not busy anymore"

There is a way to determine the platform type Reload is currently using for a profile without editing the connectivity settings in the Reload administration console:

1. Change to the directory containing the conf file:  /opt/beginfinite/reload/conf/
2. Type: less <profile name>.conf (e.g., less po1.conf)
3. Hit the forward slash " / " key to put Less into search mode
4. Type: GRE_PO_PLATFORM

You should see a line item that reads as follows:  GRE_PO_PLATFORM = "x"  (where "x" is a number from 0 - 6).

• 0 = Local (the post office is on a local drive to Reload)
• 1 = Linux (NFS)
• 2 = Linux (NFS Cluster)
• 3 = Netware (NCP) NOTE: This type is also used for Linux servers using NSS volumes
• 4 = Netware (NCP Cluster)
• 5 = Windows (CIFS or Samba)
• 6 = Reload (Reload to Reload)

If Reload is set up with the incorrect connection type (e.g., NCP instead of NFS after moving from Netware to Linux), then the incorrect mount command will be used by Reload.  Another typical error is for customers running a post office on Linux but using NSS volumes.  In such cases, the Netware NCP (type 3) connection type should be used.

This article was originally published in the GWAVA knowledgebase as article ID 2119.