Error Conditions and Solutions

This section provides solutions to several error conditions not necessarily accompanied by error messages.

Authentication Error on Windows NT 4.0 and Windows 98

A TAS authentication error occurs when a user runs Windows NT 4.0 client with Service Pack 3 (SP3) installed, or Windows 98. If the user attempts to browse a TAS server for shared volumes, or to connect to a TAS volume, the following TAS error message is displayed:

Incorrect password or unknown username for \\serverName.

This error occurs even if the user enters a valid UNIX username and password.

By default, Windows NT 4.0 SP3 and Windows 98 clients use secure authentication. The PC and the TAS server engage in a "challenge/response" exchange, which ensures that they agree on the validity of a password, without sending the actual password over the wire.

The client uses the password to encode a nonsense string (supplied by the server). The client then returns the encoded string to the server. The server performs a similar encoding and, if the nonsense strings match, authenticates the client.

To support this authentication scheme, TAS must maintain a private password file, distinct from the UNIX password file. To enable authentication, you must populate the TAS private password file with UNIX user names and passwords.

Complete these steps to enable secure TAS authentication and eliminate this error:

1. Click the TNAS TAS Administration and Configuration sphere icon to display TAS administration and configuration options.

2. Click LM-NT-OS/2 Realm.

3. In the LM-NT-OS/2 Realm panel, click: Manage File Services->

4. Select the file service you want to manage and click Administer.

5. On the resulting screen, click Authentication and Service Mode Options.

6. Enable Local authentication and click Submit.

7. Enable Password encryption and click Submit.

8. Click OK.

9. To establish entries in the TAS private password file, click these links in the TAS frame:

   Passwords->type in the UNIX user name->Create

   A user must have a valid UNIX account for you to enter the name into the TAS password file.

10. In the resulting form, enter and renter the user's password and click Submit. This user will now be authenticated correctly.

11. Repeat steps 7-9 for each UNIX user requiring TAS authentication.

Jobs do not Print on Solaris Printers

Solaris printers appear available to TAS clients. Printers can be mounted and print jobs seem to spool to Solaris printers correctly. However, jobs are never printed.

In order for TAS PC client to print to a Solaris printer, TAS configuration must be modified as follows:

1. In the TNAS Main Menu (Left Frame), click System.

2. In the System Configuration and Administration Menu (Right Frame), click Printers.

3. Select the Solaris printer to update and click Modify.

4. Enter -c in the Spooler Options box, and click Submit.

   Jobs will now print successfully on the Solaris printer.

Application on UNIX server inaccessible

The user cannot execute a program residing on a TAS host, for one of the following reasons:

• The application's file permissions deny access to the user. Log in as the owner of the directory that contains the application, or as root, and correct the file permissions, at realm->Manage File Services ->[select the service]->Administer->Configuration->Umask or with the tnservice command. Remember, DOS programs need to have UNIX read permission.

• The application has a attribute that tells DOS the drive on which it resides, but the redirected drive uses a different letter.

Compilation problems in DOS window

Compiling programs on a network drive in a Windows DOS prompt window can cause data corruption or dropped connections. For Windows for Workgroups and Windows 3.1, add the following line in the section labeled [386Enh]() in the PC's Windows system.ini file:

• InDOSPolling=True

Connection failure

Some network boards have more than one cable connection, and some have transceivers on their boards. Make sure the physical hardware jumpers can use the same connection as the software settings.

Dead sessions not dropped

When a user turns off or reboots a client PC, the network connection breaks. If this happens during a data transfer, TAS notices immediately and terminates the appropriate process. If it happens when no traffic passes between client and server, TAS notices only after a few minutes. This timeout period, dependent on the host system, typically lasts about five minutes. After the timeout period elapses, TAS terminates the appropriate process.

TAS, by default, relies on the host's underlying transport layer keepalives to keep track of dead sessions. If other applications, such as telnet, do not drop dead connections, the transport vendor may not have keepalives implemented. You may have configured TAS to use NetBIOS keepalives instead by changing the keepalive attribute at realm ->Manage File Services->[select the service]->Administer ->Configuration or with the tnservice command.

Disconnected clients still appear connected

When a PC client terminates a session--that is, disconnects a redirected drive--the associated process attempts to close the session in an orderly fashion. This includes removing the file name.number from the directory $TNHOME/TAS/tn/tndb. The name variable represents the machine name of the client PC, and number represents the UNIX ID number of the associated process.

If the client cannot remove this file, it exits without error, but when you check connection status or issue a tnwho or tninfo command, the client appears connected. Verify that totalnet owns the program srm, which does the actual removing of entries from the circuits directory, that srm has a mode of 4511, that totalnet owns the circuits directory, and that the circuits directory has a mode of 755.

DOS commands yield unexpected results

Certain DOS commands may behave unexpectedly, for the following reasons:

• Networked drives where the user does not have write permission in the root directory do not support DOS pipes--commands that include the "|" character. This occurs because a DOS pipe tries to create a temporary file in the root of the current drive.

• Some DOS applications, such as edlin, delete a file and then rewrite it to modify it. If the file links to another UNIX file, the link disappears, and a new, independent file takes its place.

• Some DOS commands report errors that do not seem to relate to their causes. For example, the DOS type command returns Invalid path or filename: when it receives the Access denied message from the server. This can happen when DOS tries to type an inaccessible file. Verify that the device, path, and file names have validity on the server and that the user has access privileges to them.

File locking errors

Files do not properly lock or unlock because the client PC rebooted and file locks did not clear. Run tnck to clear the locks.

Free disk space indicated incorrectly

Client disk space calculation limitations have become too great. DOS has problems with any disk device, whether redirected or local, that reports cluster sizes of 64 kilobytes or larger. Large UNIX systems or machines with, for example, several CD-ROM drives mounted, may represent drives totaling more than four gigabytes. DOS cannot handle numbers of this magnitude.

NetBIOS does not start

When NetBIOS does not start, make sure that the NetBIOS processes completely shut down. Use the ps command to find out whether the NBname or NBdaemon process runs even after you use shut down TAS services. This problem occurs only when a process aborts abnormally. Use the UNIX kill command to terminate the offending process, then follow "4.1.1 Starting TAS Services" or use the tnstart command.

Performance of network slow

Copying files to or from redirected drives, printing jobs over the network, or executing remote commands yields unduly slow responses, for one of the following reasons:

• The network segment has overloaded. Redesign your network to reduce the workload.

• The network generates too many broadcasts. Consider breaking the LAN into smaller segments.

• NFS generates a high amount of network traffic. If you rely heavily on NFS mounts for remote file systems, replace some by installing TAS on the remote hosts. If a client has to connect to a TAS host and file service requests route over an NFS connection to another computer, twice as much network traffic takes place than when the client connects directly to the second computer.

• TCP packet buffers or window sizes require modification. The procedure for modification on clients depends on the brand of TCP/IP installed. Check the documentation for the client's TCP/IP. In TAS, check, and possibly adjust, the values of the recvbuf and sendbuf attributes, using the tntransport command.

"Ping" does not work

This happens for one of the following reasons:

• The software settings in the configuration file do not match the physical hardware settings. Correct either one to match the other.

• The ifconfig command pings to the wrong address. Verify the network mask and the sending and receiving IP addresses.

• The target has an invalid IP address or does not have its TCP stack running. Check the destination computer to make sure it works properly.

• A network card with two network connectors uses a different type of network connector than the software. Adjust the hardware or software to use the proper connector.

• The network lacks one or more terminators. Install terminators at the ends of the network.

Printing problems

These happen for one of the following reasons:

• The network driver has not loaded. Under the Windows Setup program on the client, check the Network option to verify that the correct network driver has loaded.

• For Windows for Workgroups and Windows 3.1, the UNIX spooler misinterprets a PostScript file. When you print a PostScript file, your client sends a "CTRL-D" as the first character. The UNIX spooler, which cannot handle this, stops the print process and deletes the spool file. To correct this, add the following command to the client's Windows win.ini file under the section header [PostScript Printer,LPT1:]():

• CTRL-D=0:

• In some DOS applications, print jobs do not send until the user exits the program, because the PC buffers the print job and does not spool it until the application closes.