Troubleshooting SCO Gateway for NetWare

Guide to Gateways for LAN Servers
Chapter 3, Administering SCO Gateway for NetWare

If SCO Gateway for NetWare starts but does not find any fileservers (detected by no output from nwservers or no directories found in ./NetWare):

Execute:

showsvcs -g 4
to display the NetWare servers available on the network. If showsvcs has no output, then the problem is either hardware or with IPX/SPX. See ``Troubleshooting IPX/SPX'' in the Networking Guide and showsvcs(PADM).
If showsvcs displays NetWare servers, examine the file /etc/ipx.d/NPSConfig and, if necessary, edit it so that the sap_dump_on variable is set to ``active''. See -1 in the Networking Guide.
Then execute:

/etc/nuc stop
/etc/ipx restart
/etc/nuc start
Proceed to step 1.
If the sap_dump_on variable is set to ``active'', check that the file /etc/ipx.d/fsinfo.out has been modified since IPX/SPX started and that it is not empty. To determine when IPX/SPX started execute:

ps -ef | grep sapd
and look at the start time field of the output.
The IPX/SPX daemon sapd writes fileserver names and IPX/SPX address information into this file.
Execute:

/etc/nuc restart

Troubleshooting IPX/SPX and SCO Gateway for NetWare

To determine if SCO Gateway for NetWare and IPX/SPX are running, execute:

/etc/nwmp status
echo $?

The output codes are:

100: IPX/SPX is not running
101: IPX/SPX is running, but SCO Gateway for NetWare is not running
0: IPX/SPX and SCO Gateway for NetWare are both running

Troubleshooting SCO Gateway for NetWare autologin

NOTE: The SCO Gateway for NetWare autologin feature displays all messages to the graphical environment (using the X Window System^(TM)) at the SCO system console, not at remote terminals. Users should enable autologin only if they are working in the graphical environment at their computer's console.

If a user enables autologin, and tries to access NetWare files, directories or printers before logging into the appropriate NetWare server, the autologin feature reacts in one of two ways:

If the Graphical Environment (X Window System) is running on the computer's console, the user's NetWare access hangs and a NetWare login window is displayed on the console of the SCO system. After 1 minute, or after someone at the console clicks on Cancel in the NetWare login window, the user's NetWare access fails with a permission denied error.
If the Graphical Environment (X Window System) is not running on the computer's console, the user's NetWare access fails immediately with a permission denied error.

Users experiencing either of the above two conditions should:

Log into the NetWare server before attempting to access its files, directories or servers. See nwlogin(NWG) and ``Logging into a NetWare server''.
Use the NetWare Control Panel to disable autologin. See ``Controlling your autologin feature'' and ``Autologin''.

The autologin feature displays one NetWare login window for every attempted NetWare access. The execution of a single utility, like ls, can cause multiple attempts to access its destination directory and can cause multiple NetWare login windows.

Troubleshooting the SCO Gateway for NetWare print system

There are three print systems involved when a user submits a SCO Gateway for NetWare print job:

The local UNIX system print system.
The SCO Gateway for NetWare print system.
The NetWare print system.

A SCO Gateway for NetWare print job is first queued on the local UNIX system print system. The SCO Gateway for NetWare print system transfers the print job from the local UNIX system print system to a remote print queue on the NetWare server. The NetWare print system then prints the job.

The user must be logged into the appropriate NetWare file server while the print job is transferred to the remote NetWare queue. Users can execute nwwhoami to confirm their login to the appropriate NetWare file server.

The user submitting the print job should read electronic mail to look for any error messages mailed from the print systems.

Check that the associated NetWare file server, print server and print queue are up using the Printer Selection window of the Printer Manager.

If a user submits a SCO Gateway for NetWare print job but does not receive output, the problem could be in any one of the three print systems.

Ensure that the local print system is running by executing:

lpstat -r
The output
```
   scheduler is running
```
means the UNIX system print system is running.
The SCO Gateway for NetWare printer must be enabled. You can check this by executing:

lpstat -l -p printername
Determine whether the print job is locally or remotely queued by executing:

lpstat -l requestid
If the print job is queued remotely, log into a DOS client and use pconsole to examine the NetWare print queue. If the print job exists on the NetWare print queue, the problem is with the NetWare print system. Consult NetWare documentation to troubleshoot the NetWare print system.

Printing NetWare files on a SCO Gateway for NetWare printer

When the data file is located on a NetWare server, a non-root user cannot submit a SCO Gateway for NetWare print request unless root is logged in to the printer's NetWare server.

There are several workarounds:

Copy the data file to a non-NetWare file system and submit the print request from there
Execute:

cat filename | lp
Log root in to the appropriate NetWare server.

Remote Line Printing (RLP) to a SCO Gateway for NetWare printer

To print to a SCO Gateway for NetWare printer from a RLP client, one of the following two conditions must apply:

If the user has an account on the RLP server, the user must log into the appropriate NetWare server from the RLP server.
If the user does not have an account on the RLP server, then root must log into the appropriate NetWare server from the RLP server.

The login to the NetWare server must remain intact until the print job is remotely queued. All SCO Gateway for NetWare printing error messages are e-mailed to the login on the RLP server.

Troubleshooting SCO Gateway for NetWare display of server error messages

The graphical tools may produce error messages in the Graphical Environment relating to NetWare servers, such as "Unable to connect to server".

Users should report such errors to the system administrator. Until the problem is fixed, users can temporarily remove the problem server from the graphical display. See ``Filtering NetWare server display''.

Once the server is removed from the display list, the related error messages will no longer be displayed.

Troubleshooting SCO Gateway for NetWare licensing problems

If SCO Gateway for NetWare fails to start, one of the reasons could be that the licensing system is not functioning correctly.

If the administrator executes from the command line:

/etc/nuc restart

all error messages are displayed at the command line. Any error messages that mention licensing, Policy Manager, PMD (Policy Manager daemon) or PMAPI (Policy Manager application interface) indicate problems with the licensing system.

Troubleshooting SCO Gateway for NetWare filesystems without NUC and NFS NLMs

The limitations of the SCO Gateway for NetWare filesystems without NUC and NFS NLMs loaded on a NetWare Version 3.11 server are:

All filenames must conform to the DOS file naming convention. That means they must be single case (all filenames are mapped to lower case), and in 8.3 format.
All files appear as if they are owned by the user currently accessing the file. For example ls -l always lists the current user's uid and gid as the owner and group of the file.
The file permission bits for group and others are always 0.
The owner bits reflect the permissions the current user has in relation to the file.
The chmod command can only affect the execution bit for the owner of a file.
The following system calls work except that the initial file mode argument is ignored, files are created mode 600 and directories mode 700 (from the current user's perspective). For other users they appear to be 400, and 500 (remember to other users it appears that they own the files).

creat, mkdir, mknod, open
The following system calls work quite differently.

chmod, fchmod
Only affects the execution bit
fcntl
Mandatory locking is not supported
umask
Has no effect
The following system calls do not work at all (links, symbolic links and owners are not supported).

chown, fchown, link, readlink, symlink

The behavior of the NetWare Version 2.2 server is exactly like that of the NetWare Version 3.11 server except for the limitation of the rename system call: it limits renaming files and directories to the same directory.