Tsoft's NFS Driver for MS-DOS version 0.26 December 5, 1994 for the following protocol stacks: WatTCP (built-in TCP) Trumpet TCP ABI Microsoft (LanMan) / Hewlett-Packard / 3Com Novell LAN WorkPlace (LWP) Programs and Documentation Copyright (C) 1993-94, Tsoft. All Rights Reserved. All trademarks and service marks contained in this document are property of their respective owners. Page i Introduction Introduction Introduction The Network File System (NFS) protocol is in use widely in many Unix and TCP/IP environments. PC's running NFS client software can access file systems in NFS servers across LANs and WANs. When a remote file system is mounted on a PC drive letter, it can be accessed as if it is a local fixed disk drive by nearly all application software. Along with this software, you can setup an NFS file server on a Unix machine, one of the many freeware Unix-like OSes, or a host of other operating systems or dedicated NFS servers, and you have all you need to share files with many PCs at once. You can also redirect printer output to printers and print queues on your file server(s). Several commercial (PC)NFS packages are available; this NFS driver for MS-DOS v3.1+ is an inexpensive, supported shareware alternative. Versions of this software are available with builtin TCP/UDP/IP (WatTCP), and which use several different shareware and commercial resident TCP/IP protocol stacks for the network transport including: Trumpet ABI stacks (such as Trumpet's NTPCDRV), Novell LAN Workplace, and the Microsoft LanMan TCP/IP /HP / 3Com and compatible stacks. Future versions are planned for additional stacks. In addition to this software, you will first need to install a compatible protocol stack or install a "PKTDRVR" and configure WatTCP. If you're using one of the external protocol stack versions of the client, applications like telnet and ftp are probably available or included with your stack. For the WatTCP version, WatTCP applications as well as other pktdrvr applications may be used through the built- in pktdrvr packet multiplexor. Both PKTDRVRs and an alternative external PKTMUX are described below. Minor differences between the different protocol-stack versions of the NFS client are mentioned in the appropriate sections of this document, while some notes and consideration for using each stack are included in appendices. Important Tip: If you are looking to get the best possible speed out of this NFS client with the tradeoff of increased memory usage, be sure to review and apply the rsize/wsize options and the manual section on Performance Tuning; our defaults have been chosen conservatively to provide the least problems in varied environments. We think you'll find this to be one of the fastest DOS NFS clients available when tuned. Page ii Table Of Contents Table Of Contents Table Of Contents Introduction .............................................i Table of Contents ........................................ii Registration, Support, and Warranty ......................1 Sales and Technical Support .........................2 Warranty ............................................3 Driver Configuration Overview ............................6 Network Drivers and Protocol Stacks ......................8 WatTCP, Pktdrvrs, and Packet Multiplexors ................9 Loading the Resident NFS Driver ..........................11 Options to NFSDRVR ..................................11 Table Sizes .........................................14 Time Zone Configuration .............................14 Configuring NFS Drives: the FSTAB file ...................16 Format of an fstab entry ............................16 The /default/ Pseudo-Filesystem .....................25 A Note About Authentication .........................26 Filename Munging and File Attribute Mapping ..............27 Symbolic Link Support ....................................29 User Authentication Daemons: PCNFSD and BWNFSD ...........31 Attaching Remote Drives and Printers: the MOUNT Program ..32 Mounting ............................................32 Unmounting ..........................................33 Logging in as a user ................................34 Other options .......................................35 Exit Codes ..........................................36 Page iii File Sharing and Record Locking ..........................37 Explicitly Removing PC's Shares/Locks ...............38 Remote Printer Support ...................................40 The NFSINFO Program ......................................42 Performance Tuning -- IMPORTANT FOR MAX. SPEED ...........43 Companion Utilities -- Distributed Separately ............45 Appendix A: WatTCP .......................................46 Install a PKTDRVR ...................................46 Configuring WatTCP: the WATTCP.CFG file .............46 Sample Applications and Debugging ...................47 Support of /etc/hosts file ..........................47 Internal Packet Mux: Trumpet Winsock example ........48 Appendix B: Trumpet ABI Protocol Stacks ..................50 Hostname to Address Resolution ......................50 Trumpet TCPDRV and the 'rsize'/'wsize' options ......50 Appendix C: Other External Protocol Stacks ...............51 Hostname to Address Resolution ......................51 MS LanMan TCP/IP / Hewlett-Packard / 3Com ...........51 Novell LAN WorkPlace (LWP) TCP/IP ...................51 Appendix D: Obtaining Software ...........................53 Appendix E: Troubleshooting -- Common Problems ...........55 Page 1 Registration, Support, and Warranty Registration, Support, and Warranty Registration, Support, and Warranty This NFS client package is NOT free software. It's distributed as shareware. You can try this software for 30 days with no obligation, although if you choose to continue using it, you must pay the registration fee. If you continue to use the software after the evaluation period without purchasing a license, you are in violation of international copyright laws. The license you purchase is a non-exclusive right-to- use license. Registration is for a one-year period. You may upgrade to any versions of the software released within a year of your registration date at no charge, and once your registration expires, you may continue to use versions of this software released before your registration expired without registering again; if you want to upgrade to newer versions after that, you'll need to renew your license. Note that it is your responsibility to obtain upgrades when you need them from an ftp site, our BBS, through our floppy- disk service, or by other means and getting the upgrades to you is not included in the license--the right-to-use upgrades you obtain is. When you register the software, you're registering for a computer. On that computer, you can run any TCP/IP transport version of the software you like at any given time. If you have reason to sometimes run the WatTCP version, and at other times the Trumpet TCP stack version on the same computer for example, that is perfectly acceptable under a single license. You do not need to register each TCP version for the same computer. Note that it is YOUR RESPONSIBILITY to properly license any external TCP/IP stacks you make use of. The current registration prices are: Home users and educational users: US$15/computer Business users: US$20/computer ** Subject to change without notice. Site license discounts are available on the following schedule (also subject to change without notice): Quantity Percentage Discount ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 20 - 99 20 % 100 - 499 35 % 500 - 999 45 % Page 2 1000 + 55 % Please write or call to discuss furthur discounts on large licenses. To compute the cost of a site license, multiply the normal unit-price ($15 or $20) by the number of computers to register for, then subtract the percentage discount. A "site" is fairly open; it could be one department of your organization, one building or group of buildings, or your entire organization even if the "site" is spread over a wide geographic area. The main attribute is that there is a primary technical contact to talk with us on technical support issues; other users at your site should request assistance from the contact before the contact talks with us. This is intended to reduce the need for support from us, our support costs, and is the main reason we offer the discounts. Please print and complete the file ORDER.FRM to register, or include all the information in the file with your order. A postal letter of registration is sent by request, otherwise registrations are acknowledged by electronic mail. WARNING: Please do NOT send us credit card information via E-mail. ___________________________ Sales and Technical Support Technical support is available by E-mail and voice telephone. E-mail is the preferred method of support and is answered as promptly as possible. You are encouraged to request technical support if you are evaluating our products and need assistance. We can be reached at: nfs@tsoft.net Voice +1 510 843 8763 (Berkeley, Calif) Fax TBA Tsoft P.O. Box 14897 Berkeley, CA 95712-5897 (USA) Please phone or write for our current street address for package delivery. NOTE: tsoft.net computers are also general public access! Most users on the system do not speak for Tsoft; also Page 3 please do not mail arbitrary users for support as many won't have the foggiest clue we even sell software! We want to continue supporting this product at a low price, and registrations is the only way this can be done. We provide no warranty with respect to support, but will do our best to assist. In general, we give priority to registered users. DISTRIBUTORs: If you're a distributor and would like to sell pre-registered versions of this software with printed hardcopy manuals, please contact Tsoft. BUNDLES: You may NOT bundle or otherwise distribute this software with any other software without our express written permission (i.e., on the same diskettes, as part of a commercial package, compressed along with other software, etc.). BBSes and ONLINE SERVICES: This software may be posted for download on BBSes, including CompuServe and other services, provided no extra surchage (beyond normal download and connect time fees) is charged to download this software. SHAREWARE DISK VENDORS: Please contact Tsoft BEFORE distributing our software for written permission. Permission is generally granted if your practices with respect to reasonable copy charges and ample notice that shareware requires a separate payment to the author. Please contact us before placing this software on CD-ROMs. ____________________ License and Warranty There is absolutely NO WARRANTY, expressed or implied with this software. If you choose to use this software, you assume all risk. SOFTWARE LICENSE AGREEMENT OF TSOFT SOFTWARE LICENSE AGREEMENT OF TSOFT SOFTWARE LICENSE AGREEMENT OF TSOFT TSOFT ("LICENSOR") IS WILLING TO LICENSE THE ENCLOSED SOFTWARE TO YOU ONLY IF YOU ACCEPT ALL OF THE TERMS IN THIS LICENSE AGREEMENT. PLEASE READ THE TERMS CAREFULLY BEFORE YOU USE THIS PACKAGE, BECAUSE BY USING THIS PACKAGE YOU ARE AGREEING TO BE BOUND BY THE TERMS OF THIS AGREEMENT. IF YOU DO NOT AGREE TO THESE TERMS, LICENSOR WILL NOT LICENSE THIS SOFTWARE TO YOU. Ownership of the Software Ownership of the Software Ownership of the Software Page 4 1. The enclosed software program ("Software") and the accompanying written materials are owned by Licensor and are protected by United States copyright laws, by laws of other nations, and by international treaties. 2. This License covers the Software commonly known as "Tsoft's NFS Driver and Companion Utilities for MS-DOS". This license does not cover similiar software subsequently released by Tsoft for other platforms and computer environments, including but not limited to for the Microsoft Windows environment, even when running "on top of" MS-DOS. Grant Of License Grant Of License Grant Of License 3. Licensor grants you the right to evaluate this software free of charge for 30 days, under the terms of this License. 4. UPON PAYMENT OF THE LICENSE/REGISTRATION FEE TO TSOFT, you are granted the right to use the Software indefinately persuant to the terms stated below. 5. (UPON PAYMENT OF THE LICENSE/REGISTRATION FEE TO TSOFT,) Licensor grants to you the right to use a copy of the Software on the number of computers for which a license has been purchased. You may load one copy for each license copy into permanent memory of one computer and may use that copy, or the enclosed diskettes, only on that same computer. You may install the Software on a network server, provided that you have a License from Licensor for each station of the network at which the Software is used. 4. (UPON PAYMENT OF THE LICENSE/REGISTRATION FEE TO TSOFT,) The License purchased grants you the right to use indefinately: the current version of the Software, and any version of the Software released within one (1) year of the License purchase date. Restrictions on Use and Transfer Restrictions on Use and Transfer Restrictions on Use and Transfer 5. You may not reverse engineer, decompile, or disassemble the Software. Limited Warranty Limited Warranty Limited Warranty 6. LICENSOR DISCLAIMS ALL WARRANTIES, EITHER EXPRESSED OR IMPLIED, INCLUDING BUT NOT LIMITED TO IMPLIED WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, AND NON- INFRINGEMENT, WITH RESPECT TO THE SOFTWARE AND THE ACCOMPANYING WRITTEN MATERIALS. This limited warranty gives Page 5 you specific legal rights. You may have others, which vary from state to state. 7. LICENSOR'S ENTIRE LIABILITY AND YOUR EXCLUSIVE REMEDY SHALL BE, AT LICENSOR'S CHOICE, EITHER (A) RETURN OF THE PRICE PAID OR (B) REPLACEMENT OF THE SOFTWARE THAT DOES NOT MEET LICENSOR'S LIMITED WARRANTY AND WHICH IS RETURNED TO LICENSOR WITH A COPY OF YOUR RECEIPT. 8. This Limited Warranty is void if failure of the Software has resulted from modification, accident, abuse, or misapplication. 9. IN NO EVENT WILL LICENSOR BE LIABLE TO YOU FOR DAMAGES, INCLUDING ANY LOSS OF PROFITS, LOST SAVINGS, OR OTHER INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING OUT OF YOUR USE OR INABILITY TO USE THE SOFTWARE. Because some states do not allow the exclusion or limitation of liability for consequential or incidental damages, the above limitation may not apply to you. 10. This Agreement is governed by the laws of the State of California, United States of America. 11. If you have any questions concerning this Agreement or wish to contact Licensor for any reason, please write: Tsoft, P.O. Box 14897, Berkeley, CA 94712-5897 USA or call +1 510 843 8763. 12. U.S. Government Restricted Rights. The Software and documentation are provided with Restricted Rights. Use, duplication, or disclosure by the Government is subject to restrictions set forth in subparagraph (c)(1) of The Rights in Technical Data and Computer Software clause at DFARS 252.227-7013 or subparagraphs (c)(1)(ii) and (2) of Commercial Computer Software - Restricted Rights at 48 CFR 52.227-19, as applicable. Supplier is Tsoft, P.O. Box 14897, Berkeley, CA 94712-5897 USA. Page 6 Driver Configuration Overview Driver Configuration Overview Driver Configuration Overview This section outlines the steps you'll need to take to get the NFS client software up and running. These steps are all described in much more detail in the sections that follow this one. o Obtain and install a driver for your network card and (possibly) the external TCP/IP stack you'll use.. Most external protocol stacks use a small TSR driver to access your networking card; the driver is card specific and provides a single software interface to network applications regardless of the make/model of card. There are currently several popular driver standards: PKTDRVR, NDIS, and ODI. The protocol stack provides the TCP/IP protocol to application software. The WatTCP version of this client has TCP/IP builtin. For all other versions you should install and test the protocol stack. Which network card driver standard you choose depends on your protocol stack. o Load the NFSDRVR program The NFSDRVR is the memory resident portion of this NFS client package. Before attaching remote drives, you load the NFSDRVR once, possibly with options. The driver stays in memory to manage the drives and translate requests from the local machine to the NFS server across the network. o Configure your NFS server and install an auth daemon The NFS server must be configured to allow the PC computer access to the file systems you want to mount. This is often termed "exporting" the file system. You may also want to install a "user authentication daemon", such as "pcnfsd" or "bwnfsd" on the NFS server. The authentication daemon accepts a user name and password from the PC client software, checks the password, and if it matches translates the user name to the UID and GID numbers which NFS file systems use to identify the owner of a file for the NFS client's use. If you choose not to use an authentication daemon, you can still mount the file systems using the "none" authentication option which will use a somewhat standard UID and GID number for all accesses, sacrificing some security in the process. It may be all the security you need however. Page 7 o Edit the FSTAB file The FSTAB file configures options for remote drives. In it, you can configure NFS file server and file system's to be mounted, specify the drive letter the file system should be mounted on, and specify various options to use while communicating with the NFS server for the file system. You can also specify any of several options for authenticating yourself. o Use the MOUNT utility to attach remote drives The MOUNT program attaches remote drives to DOS drive letters. It also can be used to unattach drives. Most often it's run just once when you boot your system or load the NFS software, but it can be used to rearrange NFS drives while you use your computer. The MOUNT program gets much of it's configuration information from the FSTAB file but remote drive information can also be specified on the command line. After you initially configure the NFS software, you'll need to load at least two resident software drivers and run one utility to startup NFS such as in your autoexec.bat file. They are: - a network driver and TCP/IP stack (if not WatTCP) for your network card - nfsdrvr.exe - mount.exe The WatTCP version of the client includes a built-in single channel packet multiplexor which will allow you to run up to one additional TCP/IP stack (or application with builtin stack) that uses the packet driver interface after nfsdrvr is loaded without an external packet multiplexor. If you want to use the WatTCP version of NFS while also using more than one other TCP/IP applications with builtin stacks or other stacks at once, or to use it while also using Novell Netware or other networking software you may need to load other drivers as well, such as the PKTMUX software. Tips and tricks are described in appropriate sections below to help you get it all working together. Page 8 Network Drivers and Protocol Stacks Network Drivers and Protocol Stacks Network Drivers and Protocol Stacks The network driver (whether it be a PKTDRVR, NDIS, or ODI) presents a standard software interface to networking cards (such as your ethernet card) to application software. A driver specific to your particular make and model of card is loaded before running networking software which use it. See the appendix on obtaining software below for where to obtain them for nearly all popular Ethernet cards. External protocol stacks can usually use one or more of a PKTDRVR, NDIS, or ODI driver, or may want to talk with your network card directly. You should consult the stack's documentation when configuring the external TCP/IP stack. It is also possible to use a shim to give, for example, an ODI driver a PKTDRVR interface as well; this can allow you to run TCP/IP along with other networking protocols which may only be available for say ODI and you want to run a PKTDRVR based TCP/IP stack. You should consult the documentation for your external TCP/IP stack to select an appropriate driver and complete the installation of the protocol stack. If you are using the WatTCP version of NFS, it contains builtin TCP/IP and requires a PKTDRVR to interface with your network card. Please consult the appendix on WatTCP for completing the installation of WatTCP applications and its configuration file. Shims are available for both ODI and NDIS to provide a PKTDRVR interface on top, so the WatTCP client can be used with all three driver standards. Page 9 WatTCP, Pktdrvrs, and Packet Multiplexors WatTCP, Pktdrvrs, and Packet Multiplexors WatTCP, Pktdrvrs, and Packet Multiplexors This section describes some special considerations which come into play particularly when using the WatTCP version of NFS. Some of the information here may apply to using external protocol stacks, especially in not-so- standard configurations. The information on "pktdrvr"s is essentially what NDIS and ODI drivers do as well: offering an interface-standard for applications to talk with the network card. The "pktdrvr" standard is a network driver standard for network interfaces developed by FTP Software, Inc. and used by a variety of networking software vendors, mostly TCP/IP on Ethernet. When you load a pktdrvr for your particular make and model ethernet card, a small memory resident program provides a standard software interface to applications which want to access the ethernet card. The applications just need to know how to use the pktdrvr standard and don't need to concern themselves with the details of accessing different vendor's ethernet cards. One version of this NFS client uses Erick Engelke's excellent WATTCP TCP/IP libraries which currently support Ethernet and SLIP class packet drivers. Other network standards such as ArcNet and Token Ring can be used if an Ethernet or SLIP emulating driver is available. If you received a software diskette with your network interface card, it may already have a "pktdrvr" on it. The Crynwr collection of packet drivers can also be obtained from various FTP archives on the Internet; it contains a large collection of pktdrvrs for various manufacturer's cards. Please see the appendix on obtaining software for information on how to obtain the Crynwr collection. When an application uses a pktdrvr, it registers itself with the driver to receive all packets of a particular protocol on the network. These protocols could include Novell's protocols, Internet Protocol (IP), or other protocols. Each protocol has been assigned a specific protocol identification number. Only a single application can register for a particular protocol number; this imposes a problem if you want to use multiple TCP/IP applications at once. (If you're using an external protocol stack version of the NFS software, the protocol stack becomes the single IP-registered application but allows several applications to make use of the stack at once, managing all of the IP connections). The WatTCP NFSDRVR now has a built-in single channel packet multiplexor and will allow one additional stack or Page 10 application to register for TCP/IP after nfsdrvr has been loaded. This means that you do not need to use the external PKTMUX when you just need to run one other application at a time, for example NCSA telnet or the Trumpet Winsock. [Note: There are a couple of general restrictions on applications which go through NFSDRVR's mux which may cause you to need to use the external PKTMUX which is described below. (1) If the second application wants to talk to the same UDP ports as NFSDRVR does on the same server machines (basically NFS port 2049 and ports used by file locking daemons), NFSDRVR doesn't check for local port# collisions which may cause NFSDRVR to steal packets that should really go to the muxed application and (2) NFSDRVR presently assumes that any fragmented IP datagrams are its own and will not pass them through the mux. The second limitation is likely to be fixed shortly. These restrictions should affect very few applications, but if you find any please let us know so we can test with them when we address these problems, or fix bugs if any in the mux as it stands.] The PKTMUX program (the external software) is a solution to this problem which allows more than one other program to register for TCP/IP from the pktdrvr. It is loaded before any TCP/IP applications software included NFSDRVR and registers itself for all Internet Protocol network packets. You then load a virtual-packet driver (included with pktmux) for each TCP/IP application you want to run at once. The PKTMUX examines each incoming packet and through information about connections it maintains, tries to determine which of any TCP/IP applications you have loaded the packet is for, then sends the packet to that application. This process is described in much more detail in the PKTMUX documentation. What you need to understand about the PKTMUX to begin with is that if you want to run more than one other TCP/IP application, say a telnet client in two Desqview sessions, along with the WatTCP version of this NFS software, you will need to obtain the PKTMUX. Please see the appendix on obtaining software for how to get the PKTMUX. Page 11 Loading the Resident NFS Driver Loading the Resident NFS Driver Loading the Resident NFS Driver To load the TSR driver, place NFSDRVR.EXE and NFSINIT.OVL in the same directory. Run nfsdrvr with any options; it uses nfsinit.ovl. ________________________ Options for nfsdrvr are: When the driver is loading: -d maxdrvs Specify maximum number of NFS drives to mount at once. default = 5 -f maxfiles Specify size of the open file table for nfs files. default = 20 min = 10 max = 100 -k maxlocks Specify the total number of file record locks which may be set at one time. If you don't plan to use record locks (NLM or bwnfsd), you can save a small amount of memory by setting this switch to 0. The default is the same value as the -f switch is set to (note that this doesn't mean you may only have a single lock per open file, it's just used as an estimate for total record locks needed for the system). min = 0 max = 255 -h heapsize Specify (approx.) size of dynamic memory pool in bytes. default = 4096 min = 2048 max = 16384 -r maxrsize Specify maximum read size for servers. You may later specify smaller sizes for specific mounts, but this sizes some buffers and determines the maximum read size the resident driver will support. default = 1024...min = 1024 max = 8192 -w maxrsize Similar to -r option, but specifies maximum write block size. default = 1024...min = 1024 max = 8192. -q Quiet mode. Don't print driver configuration on load. -s numservs Page 12 Specify number of server connections. One server connection is used for every { ipaddr, port, protocol, uid } tuple mounted. Note that if UIDs match from two mounts from the same IP address, the GID lists are assumed to match as well. -l [ n ] [ b ] [ p ] Loads printer support code and buffers so that you can mount printers. The 'n' suboption specifies the maximum number of printers to support, between 1 and 9 (note, no space between n or b and the number... "-l n5" for example). It defaults to 3 printers. The 'b' suboption specifies the approximate total buffer space to allocate between the printers. The size value is rounded up to the nearest 64 bytes since NFSDRVR manages its buffers in 64 byte buckets. The minimum buffer size is 512 bytes, the maximum is 8192, and the default is 1280. It's usually not necessary to increase this value unless you are severely intermixing data on more than one redirected printer port; printer data is flushed after a maximum of 1Kbyte is written to a port (regardless of the wsize for the printer 'drive') so there is little value in increasing it for one port. The 'p' suboption causes the file 'HEADER.PS', located in the same directory as NFSDRVR.EXE, to be loaded as the PostScript header, which is prepended to the output stream for any printers which are mounted with the printer=postscript fstab option (see the fstab section below). If 'p' is not specified but printers are later mounted with the postscript flag, no header will be prepended. -lh Load High. NFSDRVR will load into a DOS5+ or XMS Upper Memory Block leaving more low memory free for other applications. At present, NFSDRVR can only load its own data segment into high memory, (the code segment will stay low) though a future release will also be able to move its code segment. If a large enough UMB is not available, the data segment will stay in low memory and nfsdrvr will still load. You can check with the DOS 'mem' command to see if NFSDRVR's data segment has been loaded high. Page 13 -m muxvect (WatTCP only) Specify alternate interrupt for internal mux. By default, the internal pktdrvr multiplexor is installed on top of the "real" pktdrvr interrupt. This option allows you to place the internal mux on a seperate interrupt. It may be useful if another protocol stack, PDIPX for example, is already using the pktdrvr and you don't want it's interrupt calls to pass through the internal mux (which in the case of non-IP or ARP protocols will simply pass most requests straight through); if nothing more, it's slightly more efficient for the other protocol stack. Note that the "real" pktdrvr is always hidden from standard searches for pktdrvr signatures by changing its signature (it's restored on unload). While loading OR after the driver has loaded: The following options can be altered after the driver has been loaded by running NFSDRVR again with the option. -v[-] (WatTCP only) Make the internal packet multiplexor visible [-v- to make it hidden]. This option hides the packet multiplexor from other applications which search for a pktdrvr by scanning interrupt vectors. It's useful for forcing other applications to use channels of an external packet multiplexor for example. Note that if shim, such as WINPKT.COM, has been loaded after NFSDRVR, this switch will not modify the shim's signature, only NFSDRVR's mux's itself. for this reason the multiplexor may remain visible to applications by virtue of the shim still being visible. The "real" pktdrvr is always hidden from searches by NFSDRVR after installing its mux. Nfsdrvr's MOUNT command uses a standard packet driver search and if none are found, searches for a hidden NFSDRVR mux. Thus, MOUNT will take preference to the channel of an external mux over NFSDRVR's mux. Note that MOUNT must have a channel (either external or the internal) available to it when it does network operations. After the driver has been loaded: -p Print current driver configuration. Page 14 The screen is identical to that displayed by default when the driver first loads (if -q is not specified). Driver must already be loaded or this switch is ignored. -u Un-install the driver from memory, if possible. Some reasons the driver won't be uninstalled: One or more NFS drives are still mounted; use "mount -ua" (or -uaf) to unmount them. Another program has hooked Interrupt 2Fh after the NFS driver has been loaded; find which one and if you can load it before NFSDRVR, NFSDRVR will be unloadable. -? Print brief help screen without loading driver. ___________ Table Sizes The various table sizes, heap size, etc. which are configurable can save you RAM, so you should shrink them if you don't need all the space. You can also expand them if you need more, but keep in mind that the driver has a total of 64KBytes of data space available to it to be allocated between the tables and heap, and other data in the driver. This should be plenty for most applications. If you're having trouble allocating large enough tables and such for your needs, please contact Tsoft. _______________________ Time Zone Configuration In order for times to be correct (be converted from GMT), you'll need to set the somewhat standard 'TZ' environment variable. example in your autoexec.bat: set TZ=PST8PDT The format is that of Borland C's tzset() routine which requires any three characters A-Z followed by a number, which is the offset from GMT (optionally preceded by +/-). If any three A-Z characters follow, daylight savings time is used during the appropriate time of year. Page 15 We realize these routines don't work too well for users outside the US and are planning to replace them with something better shortly. Page 16 Configuring NFS Drives: the FSTAB file Configuring NFS Drives: the FSTAB file Configuring NFS Drives: the FSTAB file The 'FSTAB' file is where you configure information and options about remote file systems you may want to attach to your PC's drive letters. The file is located by default in the directory "\etc" on the same drive the mount.exe program is located on. An override via environment variable 'ETCDIR' can be used to specify an alternate directory on any drive. The file consists of a series of entries, each of which specifies an NFS file server, a file system or printer on the server, and any of a number of options to use when mounting and accessing the drives. The format of the entries and available options are described below. Comments are allowed in the fstab file. They start from the character '#' or ';' and continue until the end of the line in the file. The comment characters must be at the beginning of a "word", that is, at the beginning of the line or preceded by whitespace, to be considered a comment so the characters may appear in a password for example. _________________________ Format of an fstab entry: server:/filesystem or server:printer-name lptx: Options for this file system or printer continue until another file system or printer is specified. The options may be specified on the same or different line(s). are any of the following: d: Mount on drive letter 'd'. The default is to mount on the next available drive letter. lptx: or prn: Mount a printer on the specified port. The 'x' in 'lptx:' may be from 1 through 9. Use of this option tells NFSDRVR you are mounting a printer. The pcnfsd/bwnfsd printer name ID should be specified instead of a file system path in the server:/fs pair, for example "server:lp lpt1:" to Page 17 mount printer 'lp' on printer server 'server' on PC port 'lpt1:'. user=name Use 'name' when querying authentication server (ie, pcnfsd). Default is to use the default name set with mount -s or -l, or to prompt for the name if no name is set. password='pwd' Use 'pwd' for password when querying auth server. password=- or password= Use null password for password (no password). If no password is set: If a user= is specified, prompt for password. If no user= is specified, prompt for both user and password. If a password is set: If a user= is NOT specified, default is to assume currently set username. For security reasons, it is not recommended that you place your password in the fstab file or on command lines in batch files, unless you are the only person to use your PC and the PC and all of its data is physically secure. Please also see the 'Note About Authentication' at the end of this section; the password= option may sometimes be ignored if you've already mounted another file system from the NFS server with the same username=. alias=name Define an alias for this drive for optional use in mount d: command. ( "mount name" instead ). auto Mount drive when 'all' drives mounted. noauto Don't mount this drive when 'all' is mounted. Both explicitly and implicitly (ie. explicit mount-all, login, etc.). The default is 'auto'. port Use default NFS UDP port of 2049. port=#### Use explicit NFS port number ####. port=0 Query portmapper for NFS port (default). auth=, If an auth= clause is used, at least one option must be specified and all options for auth must be specified in the same 'auth=' clause. Page 18 : pcnfsd - pcnfsd v2 or v1 (default) (uses v1 iff v2 isn't avail) pcnfsdv2 - pcnfsd version 2 pcnfsdv1 - pcnfsd version 1 bwnfsd - bwnfsd version 1 bwnfsdv1 - " " " none - no auth, use uid=gid=-2 : port is the port for the auth server 0 - get port from portmapper (default) ### - use specific port < 1024 proto is one of udp - use UDP (default) tcp - use TCP "/proto" may be ommited to use UDP but a port number is required (if you use this option at all) so use "0/proto" to alter just the protocol. authhost=
Specify an alternate network address to query the user authentication server on. The default is to assume the authentication server is on the same host as the file system that is being mounted. There's an implicit assumption that the authhost shares the same UID/GID number space as the NFS server; this may not always be the case and you shouldn't use the authhost option in that case. retries= Total number of (re)tries that will be made for calls to the NFS server. 0 specifies use default. Default is 5. timeout= Base timeout in seconds before an NFS server request is retried. For each call to the server, the timeout starts at this value, and is doubled for each retry upto a maximum of 30 seconds. Default is 1 second. example: 3 would work out to 3, 6, 12, 24, and 30. If you have a low speed link or slowly responding server, you may want to increase this value. readwin= The maximum number of outstanding NFS read requests. When trying to satisfy a large block read request (greater than a single NFS read, see rsize), the client will send up to requests to the NFS server before requiring a Page 19 reply to any of the requests, and will try to keep this many requests outstanding until the total read is satisfied. The default is 3, min of 1, and max of 8. This can improve performance on large block reads (like file execs and copies) but can also be a problem if the network is dropping packets or the NFS server is bogged down and requests time out. It has essentially no effect for reads less or equal to the rsize for the file system. See the section on Performance Tuning for more discussion on this option. rsize=### Use ### size (in bytes) for file/dir reads from server. Default is to select maximum the local driver is configured for. It is generally recommended that this value be a power of 2 (ie, 512, 1024, 2048, etc.)... maybe a crazy superstition :) Minimum is 128, maximum is 8192. Notes: See the '-r' option to NFSDRVR.EXE to configure the maximum rsize the driver will support regardless of the fstab rsize specified. If the nfsdrvr configured rsize is exceeded by an fstab entry, the value actually used is displayed at mount time. Directory reads will use 512 to 1024 bytes; the former if rsize is <= 512, the latter if >= 1024, otherwise whatever rsize is set to. See the Appendix on Troubleshooting for more important notes on this option. wsize=### Use ### size (in bytes) for file writes to server. Default is similar to 'rsize' option default. Minimum is 128, maximum is 1024. crmode= (octal value) umask= (octal value) Specify a mode to use when creating files. The crmode option specifies the mode directly. The umask value specifies permissions you do NOT want to be given on created files. The default is to use the umask returned from the authentication server (ie, pcnfsdv2, etc.) if Page 20 available or 0022 if it is not available. (A umask of 0022 translates to file permissions of 0755, ie. everyone can read or execute, but only you can write). Notes: A umask is returned by pcnfsdv2, but not by version 1. In some cases, always specifying this value may be desirable as the Unix default may not be suitable. In order to read a file under DOS, you need read access (and to execute, you need execute access). For directories, you need r and x to access them properly. dircrmode= (octal value) Similar to the 'crmode' and 'umask' options but used when you create a directory. The default is to use a dircrmode of 0700 (aka a dirumask of 0077) which does not give any normal user other than yourself access to the directory. filemap= Suboptions: mutually exclusive if listed together: lower - use lower case (default) upper - use upper case Specify case of filenames server uses. Some servers such as Unix don't care but you'll want to use the case most of your files are in; characters in the opposite case result in file name munging even if they otherwise fit into a DOS name. caseinsensitive This suboption specifies that the file server is case insensitive, but preserves case in filenames. When the NFS client receives filenames with mixed case from the server with this option enabled, it automatically converts the names internally to upper/lower (depending on the above option) preventing unecessary filename munging. The upper/lower suboptions degenerate to being the case files and directory names are created on the server. You should not use this option unless your server is truly case insensitive on filenames or you may not be able to access some files; an example is the OS/2 NFS server on HPFS partitions, although later Page 21 versions of this server may have an option to force all one case on exports. truncnames The 'truncnames' option is intended to handle CD-ROMs exported from a file server when the CD- ROM has long filenames and the file server exports them as such. When these disks are used directly in a PC, MSCDEX truncates the long filenames to 8.3. This option attempts to emulate that truncation. In some cases a file may be munged using the default name munger but we believe that such names won't be found on CD- ROMs as we're describing; if we're wrong, please let us know! Important: If you're exporting a CD-ROM from a file server and it already has 8.3 filenames, you should not enable the 'truncnames' option. When truncnames is enabled, every filename presented for open, change directory, etc. is potentially a munged filename and involves extra work by the client if a "file not found" occurs on the 8.3 name the client first tries. You should really only enable it if necessary, as if there are any filenames which don't differ after being truncated, you can wind up with two in the same directory with the same name (if the disk is intended for DOS use, this shouldn't happen). attribs= noarchive By default, the nfsdrvr always sets the archive bit in DOS file attributes. With this option on a file system, the archive bit is always cleared. The X/Open recommendations call for the default, archive bit set. hidenorx With this option, files and directories for which the user doesn't have at least one of Read or Execute access (through any of the owner, group, or all modes) on the file server are not displayed in directory listings. The X/Open recommendations call for the use of this option. setuidhid Page 22 With this option, files with the SetUID bit set on the file server have the DOS hidden attribute set. Likewise, setting the DOS attributes of a file with the hidden attribute set in the DOS attributes will attempt to set the SetUID mode bit on the file server. By default, the SetUID mode bit is ignored. Note there is a potential security problem in that inadvertent setting of the SetUID bit could open security holes on the file server. The X/Open recommendations call for the use of this option. nodothid By default, filenames which begin with a dot on the file server, such as ".login", have the hidden bit set in the DOS attributes. This option gives no special treatment to the leading dot. The X/Open recommendations call for the default, marking files with the hidden attribute which begin with dot on the file server. nodirro This option causes the read-only bit to never appear to be set on directories even if the directory is read-only on the file server. Setting/clearing the read-only bit on a directory with a DOS setattr() still has the normal affect on the file's permissions on the server, but an 'attrib' or dir on the directory will never show the read-only status. This option is provided primarily as a work around for recursive copying and how it is affected by differences in the semantics of a "read-only directory" between DOS and Unix. Under Unix, a read-only directory means a user cannot create or remove files in the directory, while under DOS it (apparantly) just means the user can't remove the directory itself (but may still create/remove files in it). This presents a problem for recursive copies such as performed by the MS Windows File Manager: When a directory is created during a recursive copy, File Manager immediately sets the attributes of the newly created directory to that of the original directory. When the original directory is read- only, this is a problem since under Unix no new files can be created in the directory so the recursive copy fails when an attempt is made to create files in the directory. This option will allow the recursive copy to succeed by having File Manager essentially ignore the fact that Page 23 the original directory is read-only, and so the recursively-copied directory remains writeable. Of course this option can affect other situations besides recursive copies, but it doesn't affect the read-only bit on regular files. symlink=,... Specify options for symbolic link support. Valid suboptions are: A number between 0 and 255, specifies the maximum number of symlinks NFSDRVR will process while looking up a pathname. The default is 8. NFSDRVR does not per se detect loops, but instead relies on this value to assume a file is not found if the number of links exceeds this value. Setting this value to zero effectively disables symbolic link support on a drive. 'noabs' specifies that NFSDRVR should not try to automount symlinks with absolute pathnames; instead they will appear as zero-byte, readonly files. See the section below on Symbolic Link Support for more details about this option. Example: symlink=3,noabs Specifies that a maximum of 3 links will be processed for a pathname, and absolute links will not be processed. label= This option allows you to set a volume label to be returned for the drive. The default volume label is the first 11 characters of the hostname or IP address used to mount the drive, with any dots changed to underscores. To set no volume label, use "label=" (whitespace immediately following the equal sign). lock= Lock type suboptions (only one allowed per drive): none - Don't use any file locking. (default) fake - Return success for all lock and allow all file opens (shares). nlm - Network Lock Manager (NLM)/ rpc.lockd Page 24 Version 3 of the NLM protocol is required (has extensions for (pc)nfs clients); version 1 and 2 are not used. bwnfsd - Bwnfsd file sharing and locking. Use the file sharing and record locking services provided by the Bwnfsd daemon (which can also provide user authentication and printer services). Presently the NLM/rpc.lockd and bwnfsd ports are always obtained through the portmapper only and the UDP protocol is used to service the connection. signedlocks - File server treats locks as signed. This suboption tells NFSDRVR that the file locking daemon on the server treats NFSDRVR's unsigned lock requests like signed numbers. This option causes the high/sign bit of all offsets and lengths in lock requests to be cleared before sending to the server. This is only necessary for some rpc.lockds; the need usually this shows up as an error message on the server. Bwnfsd servers shouldn't need this but it's allowed anyway. A future version will detect this condition and automatically enable this option. noremlocks - Don't automatically remove all locks. This suboption tells MOUNT not to automatically free all locks and shares for the PC client on a given server when starting the first lock connection to a given server lock daemon (during mount) or when shutting down the last connection to the given server (during unmount). This option should only be needed if you've loaded multiple NFS clients on the same PC, such as on virtual machines of various multitasking software; since the different instances don't know of each other's drives, without this option a client may free all locks even though another client on the same PC still has valid locks and shares from the file server. printer=,... Specify options for a printer. Valid suboptions are: 'to' where is a number between 5 and 3000, specifies the number of seconds of "no new characters" before a spooling Page 25 print job is closed (printed). The default is 30 seconds. 'postscript', indicates that this is a postscript printer. If the '-l p' option was used on nfsdrvr to load a postscript header, the postscript header is prepended to each print job on this printer. (If no header was loaded, nothing is prepended). This option also affects the printer option string sent to pcnfsd daemons. The following options are planned but don't yet do anything or are errors. ro Read only file system. rw Read/write file system (default). _______________________________ The /default/ Pseudo-Filesystem The MOUNT program supports a special file system that you can insert into your "fstab" file instead of a server:filesystem pair to alter the system defaults. For example, /default/ auth=bwnfsd authhost=professor.tsoft.net will cause all file systems listed after this /default/ entry in the fstab file to use the bwnfsd server on host "professor.tsoft.net" for user authentication services instead of the default, pcnfsd on the NFS server you are mounting. The defaults remain altered until the next /default/ entry appears in the file, at which point any entries listed after the new defaults are affected by it instead. To reset the currently overriden defaults to the system defaults as listed above, simply specify a /default/ file system without any overridden option defaults. /default/ # reset to system defaults When using the fstab entry format on the MOUNT command line, the MOUNT program will use whatever /default/ entry is the last one listed in the "fstab" file as its overridden defaults. If MOUNT can't open the fstab file, it will silently use the system defaults; an fstab file is not required for MOUNT if you use the full-form command line. It is important to note that the /default/ entry only alters any implicit defaults lists with the option descriptions above. For example, specifying "port=0" on an Page 26 entry always uses the system default of querying the portmapper, even if a previous /default/ entry overrides the port to "port=102"; instead the new entry should not use a "port=" option at all to use the /default/ entry's defaults. In other words, for an overriden option default to be used in a subsequent entry, that entry must not specify the option at all. ___________________________ A Note About Authentication When a user= is specified in fstab, the password=, if specified, will be ignored if another file system was already mounted using the same username from the same file server. Similiarly, if user= is left out and a username is entered at the 'login:' prompt presented by mount, no password will be asked for if another file system was already mounted using the entered username. Please note that this is different than in past versions of this client. Page 27 Filename Munging and File Attribute Mapping Filename Munging and File Attribute Mapping Filename Munging and File Attribute Mapping ________________ Filename Munging Filenames received from the NFS server which do not fit into the standard DOS file naming conventions are munged to fit into the DOS 8.3 naming convention using the X/Open recommendation for "tilde" name mapping by default. See the 'filemap' fstab option above for some variations on the name mapping described below. When munging, if the file extension is valid in DOS, it is saved. The name stripped of any valid extension is converted into a DOS legal name by taking up to the first five characters, keeping DOS legal characters and replacing illegal characters with tilde's ('~'). If the name is shorter than five characters, the first five of the new name are filled with tilde's. The sixth character is always a tilde. The last two are, in Tsoft's clients, generated by summing and shifting the ascii values of the characters in the original filename (sans any saved extension). Finally, if an extension were saved, it is tacked back on the end. When creating a new file or directory, the mapping will try to find a file with the same base part and preserve any long names in creating files with different extensions. For example, if a file "big_c_prog.c" exists on the file server and has the munged file name "BIG_C~12.C" on the PC, a new file created as 'BIG_C~12.H" in the same directory as big_c_prog.c will preserve the long basename on the server and be created as "big_c_prog.h". Our method differs slightly from the X/Open recommendations in that we do not use a cache of filenames on the PC; we have the benefit of getting consistant results, inconsistancy's being caused by names being flushed from caches, but don't get the benefit of potentially preserving a long or otherwise illegal basename when creating a new file in a different directory from the existing file as desribed above. ______________________ File Attribute Mapping Tsoft's clients can also be configured to follow the X/Open attribute mapping conventions, but the defaults differ slightly due to possible security problems. To configure for the X/Open recommendations, the 'attribs' fstab option should be set as follows: attribs=setuidhid,hidenorx Page 28 Please see the 'attribs' fstab option described in the FSTAB section above for all the suboptions, and specifically what these two suboptions do. Page 29 Symbolic Link Support Symbolic Link Support Symbolic Link Support NFSDRVR supports symbolic links a little differently than Unix(tm) and other NFS clients. Typically other clients read a symbolic link then process it from the local view of the file system. Because NFSDRVR doesn't support mounting multiple file systems on a single DOS drive letter, NFSDRVR tries to interpret the link from the server's view of the file system. This can cause some problems which are mentioned below, but to understand when they will occur, you need to understand your NFS server and the differences which exist between various servers; you may view this section as more of a technical revelation to help you realize why NFSDRVR's admittedly strange way of processing links sometimes works and sometimes doesn't, if you're really that interested. In other words, if you don't understand this section, don't worry about it too much. [Note, if and when NFSDRVR supports multiple file systems on one letter, this behavior may change.] NFSDRVR divides symbolic links into two groups: "absolute link"s, which are all links which begin with a forward-slash (NFSDRVR's symlink support assumes a Unix style naming convention in the links), and "relative link"s which are all links which don't begin with a forward slash. NFSDRVR processes these links in two distinct manners. Relative links are processed by looking up the pathname components individually just as a regular pathname is looked up. Essentially the link path just becomes a part of the current path being looked up (although no MS-DOS munging occurs for the link portion). This means NFSDRVR may not be able to follow a relative symbolic link which crosses a physical file system on your NFS server. For absolute links, NFSDRVR queries 'mountd' (or the equivalent) on the NFS server with a 'mount' request (and immediately unmounts if it's not mounted on any other drive letters). The PC must, therefore, have mount access to the ultimate file or directory pointed to by the link (and it must reside locally on the same NFS server) for the link to resolve successfully. Some points to note about NFS servers, although this is only typical and may not be the case with your server. Most NFS servers tie the export to a physical file system partition. Assuming your server does this, NFSDRVR will probably handle relative links within the physical partition, and absolute links inside or outside of the partition fine, but relative links that try to cross a file system boundary won't work. Some NFS servers export an entire physical file system below the exported path in the Page 30 server's /etc/exports (or similiar); others export only the exact path; NFSDRVR's absolute symlink automounting works with the former, but is very hindered by the latter (only explicit exports can be automounted). There are a couple of suboptions to the 'symlink' fstab option described in the FSTAB section above. The first, a number which specifies the maximum number of links to process in a given pathname, is used for loop detection. The second, 'noabs', disables the auto-mounting of absolute links described above; all absolute links on the drive appear as zero-byte, readonly files. Page 31 User Authentication Daemons: PCNFSD and BWNFSD User Authentication Daemons: PCNFSD and BWNFSD User Authentication Daemons: PCNFSD and BWNFSD You will most likely want to obtain and install a user authentication daemon on your NFS file server(s). The authentication daemon validates a user's password and translates a user name to the numerical User IDs (UIDs) and Group IDs (GIDs) that the NFS protocol and most Unix-like systems use to identify the owners of the files. If you provide an authentication daemon, the MOUNT.EXE program included with this package will communicate with the server across the network to perform this function. Your other option is to mount file systems without using an authentication daemon in which case the "nobody" UID and GID (both -2) will be used without requiring an authentication server (see the "auth=none" option in the section on the "fstab" file). There are two servers available. The first is Sun Microsystems' "pcnfsd". The second is Beame and Whiteside's "bwnfsd" server. Both are freely distributable servers and are available on the Internet and by other means; please see the appendix on obtaining software. For this NFS client's sake, either will work just as well. Which you choose to use may be largely dictated by which compiles on your NFS server easier, which can be obtained easier, or which you may already be using with other (PC)NFS client software. Which to use is configured in the "fstab" file (see the section above) and defaults to "pcnfsd". You can use both servers with different drives and file servers at the same time if you need to. If you plan to redirect printers to remote printers, you will need to configure and use one of the user authentication daemons, which also provide support for networked printers. Page 32 Attaching Remote Drives and Printers: the MOUNT Program Attaching Remote Drives and Printers: the MOUNT Program Attaching Remote Drives and Printers: the MOUNT Program The MOUNT.EXE program is used to attach remote drives to your PC's drive letters, and printers to the printer device names. It uses the FSTAB file described above to get most of its information, although you can also specify fstab options on the mount command line. For a brief help screen, type 'MOUNT' with no options. MOUNT requires the NFSDRVR program to be loaded before it can do anything useful. When using the WatTCP version of this software, mount requires a WATTCP.CFG file, just as the NFSDRVR program does. When using an external protocol stack version, MOUNT simple needs the protocol stack loaded which is of course a prerequisite for NFSDRVR to be loaded anyway. It searches for the FSTAB file on the drive MOUNT.EXE is located on in the directory \ETC by default, or in the drive and directory specified by the 'ETCDIR' environment variable if it is set. For example, set ETCDIR=d:\usr\etc will cause MOUNT to use the file "d:\usr\etc\fstab" for the fstab file, regardless of where mount.exe is located. The different modes MOUNT can be run in are described briefly below. ________ Mounting Mounting attaches remote file systems to drive letters on your PCs, and remote printers to printer ports/device names. The mount process involves authenticating the user (you!), and setting up DOS and internal driver data. Mount may prompt you for a user name and password or just a password for a particular drive as appropriate. You'll have three chances to get the password correct before mount gives up on mounting a drive. See the section on the FSTAB file for how to specify user names and passwords so that you don't have to enter them. -a Mount all drives in FSTAB. This option will attempt to mount all drives listed in your fstab file which are not marked with the "noauto" option. d: lptx: or alias Mount a specific drive letter, printer, or alias listed in FSTAB. Mount can accept any number of drive letters and/or printer ports and/or aliases on the command line and will try to mount them one Page 33 by one. The 'drive' is a drive letter set specifically in an FSTAB entry. The alias refers to the alias= tag of an entry in the FSTAB file. server:/fs server: Mount a drive or printer based on an FSTAB entry specified on the command line. Mount can accept a full-form FSTAB entry on the command line. When mount is executed in this manner, it mounts just the single drive or printer whose fstab entry is specified on the command line. Some fstab options don't really have any meaning when specified on the command line, such as alias= or noauto, but mount will accept and ignore them. Mount uses the system defaults for any options not specified, or if an 'fstab' file is found, uses the defaults in effect at the end of that file (see the 'fstab' file section above). __________ Unmounting Unmounting un-attaches a remote drive or printer which is mounted on your PC's drive letter/printer port. When mount unmounts a drive, it also tries to notify the remote NFS server that you have unmounted its drive (if you don't have the drive mounted on another drive letter still) but if it can't contact the server, it lets you unmount anyway. -u[f] d: [ e: lptx: prn: ... ] Unmount specific drive(s)/printer(s). You can specify one or more specific drive letters or printers to unmount and mount will unmount just those drives/printers, leaving any other mounts intact. If you specify a drive letter for a non- NFS drive, mount displays a brief error message and does nothing to the drive. The 'f' flag forces an unmount, meaning the file system will be unmounted even if there are currently files open on it. Future access to these files will return an error. -ua[f] Unmount all drives. This option will unmount any and all remote NFS drives and printers that are currently mounted on your PC. The 'f' flag forces an unmount as described above. For the -ua option without the 'f' flag, drives Page 34 with no open files will be unmounted while drives with open files will not (and a message indicating this displayed). ____________________ Logging in as a user The mount program can maintain a notion of a "logged in" user. When you are logged in or have "setuser"ed a user name (and possibly a password), then mount will use the user name and password automatically whenever one is not specified in the FSTAB file entries. For the '-l' and '-s' options below, MOUNT will by default accept the username and password input without verifying it against a server. If you would like to have mount verify the username and password against a server and give you the opportunity to correct it, you should specify the server name in one of the following environment variables: PCNFSD, PCNFSDV1, PCNFSDV2, BWNFSD, BWNFSDV1. Mount searches for the variables in the given order, and the first variable found determines the type of authentication used. The variable names coorespond to the authentication types you can specify for the 'auth=' fstab option (see the section on the FSTAB file above). For example, add 'set PCNFSD=ginger.tsoft.net' to your autoexec.bat file and Mount will verify your username and password against the server ginger.tsoft.net using the pcnfsd authentication daemon. At present the verification always employs UDP protocol on a port for the service retrieved from the portmapper. -l user [ password ] Login as a user. This option sets mount's notion of a current user and password and also does a "mount -a" to mount all drives using the given name and password (if not overridden in the fstab). If no user name and/or password is specified, mount prompts for them. -s user [ password ] Set a user name. This option is similar to the -l option, but only the user name (and password if specified) is set and no "mount -a" is performed. -lo Logout. Page 35 This removes the user name (and password) mount currently considers as logged in, and also unmounts all drives ("mount -ua"). _____________ Other options -e { [] } Query the mount daemon on the specified host(s) and list the file systems the server has exported. consist of the following options. The command line is parsed left to right and an option remains in effect until another option alters the value: -t Use TCP protocol. -u Use UDP protocol. (default) -p Select explicit port number. 0 = use portmapper (default) Example: mount -e island -t -p 742 boat sail Queries island's mountd using UDP and gets the port from the portmapper. Both boat's and sail's mountds are queried with TCP on port 742. NFSDRVR need not be loaded to use this option, however your TCP/IP protocol stack must. IMPORTANT: Results are limited to slightly under 2KB of data presently. Note that not all mountds support TCP requests and some mountds that do won't by default unless started with a command line (or other) option. -m { [] } Query the mount daemon on the specified host(s) and list the client and file system pairs the server believes are mountd. Note that this list is not necessarily accurate. The are identical to the mount -e main option above. The example and other comments also apply similiarly. -r Remove all file shares/locks from server(s). Page 36 This option will query the specified file sharing/region locking server (NLM or bwnfsd) on the specified servers to explictly remove all shares and locks owned by this PC. The '-r' option requires suboptions; please see the manual section below on File Sharing and Record Locking for details on the -r option's suboptions. -? Display help screen. This option displays the same help screen you'd get if you ran mount with no options. __________ Exit Codes Mount exists with an exit code which you can test in a batch file with the "if errorlevel" construct or within your own programs which execute mount. The codes mount returns are listed below, and when more than one applies, the exit code consists of the applicable codes added (or "OR"ed) together. 128 = resident NFSDRVR or TCP/IP stack not found 64 = resident NFSDRVR not same version (numeric or TCP/IP) 32 = memory allocation failure (usually during fstab loading) 16 = unknown command line option 8 = password failure mounting a file system or printer 4 = failed [un]mounting one or more file system(s) 2 = failed [un]mounting one or more printer(s) 1 = error parsing fstab file (not necessarily fatal) 0 = everything succeeded Page 37 File Sharing and Record Locking File Sharing and Record Locking File Sharing and Record Locking Tsoft's NFSDRVR supports both Network Lock Manager (NLM/rpc.lockd) and Bwnfsd DOS file sharing and record locking. File sharing and record locking protects the integrity of data when multiple applications on the same or different machines are trying to access data at once; one application can briefly lock all or part of a file so that other applications will not read or write the region while it is being updated. By default, locking is disabled on each mount. See the FSTAB 'lock=' option to enable file sharing and record locking support. Enabling sharing support does result in some overhead as a DOS share/unshare request is made each time a file is opened/closed. If an application makes use of the DOS region locking services, it is usually advisable and may be required by the application that locking support be enabled. Also, see the '-k' switch to 'NFSDRVR' to configure the total number of record locks which may be set at once. When a file is closed, NFSDRVR automatically tries to free any locks the application which placed the locks may have forgotten to remove. NLM/rpc.lockd and bwnfsd locking consumes a server connection for each {ipaddr, port, uid} pair just like NFS drives themselves do. For example, if you mount all of your drives from the same file server, and use the same type of locking for them all, you'll need two server connections (nfsdrvr -s 2 ... note the default is three anyway), one for the NFS connection itself and one for locking. Mount automatically frees locks/shares from file servers when appropriate on mounts and unmounts. See the 'noremlocks' suboption of lock= in fstab to disable this feature on a particular drive. If you're having trouble with locking, note that rpc.lockd on some vendors NFS servers seems to be plagued with bugs. If your rpc.lockd supports a debugging mode (sometimes undocumented), you may want to (or have your local Unix guru) enable debugging and see if the requests received from the client make sense and are being accepted by the server. We strongly encourage performing your own tests to make sure locking is working correctly, and making frequent backups of shared data on your server (in particular, shared and updateable databases). Page 38 _____________________________________ Explicitly Removing PC's Shares/Locks An additional MOUNT main option, -r, for removing all shares and locks on a specified file server, has been added to explicitly free all of the PC's locks on an NFS server. You may want to use this option in your autoexec.bat to be a good neighbor, but note that if you mount file systems at boot then NFSDRVR will be doing this for you on your mounts anyway by default. It frees all shares and locks which may have been left active for your PC in a lock server if an application or your whole machine has crashed. NFSDRVR does NOT need to be loaded to use this option, but your TCP/IP stack does. There are several additional parameters to the -r option. The basic form is... mount -r { [ -t | -u ] [ -p ] [ -b | -n ] [ -v | -q ] } All of the switches after -r set values/settings which remain in effect until changed by another switch. Multiple hostnames / IP addresses can be specified on the command line and will be processed from left to right. If an error is encountered parsing the command line, it stops immediately (this does not include failing to remove locks, or resolve hostnames to IP addresses, just parsing). The -r option switches are... -t connect to lock server with TCP -u connect to lock server with UDP (default) -p connect to port number 0 = use the portmapper (default) -b remove locks/shares from BWNFSD server -n remove locks/shares from NLM/rpc.lockd server (default) -v verbose mode, announce what we're doing (default) -q quiet mode, don't announce but still displays errors the name of the server host or an IP address to remove locks from ________ Examples: mount -r -t -b island Page 39 Removes locks/shares from server island's bwnfsd server using TCP protocol and getting the port from the portmapper. mount -r island -t boat -p 742 sail -b testhost -p 0 -u dock Removes locks/shares from servers as follows: island: rpc.lockd, UDP, port from portmapper boat's: rpc.lockd, TCP, port from portmapper sail's: rpc.lockd, TCP, port 742 testhost's: bwnfsd, TCP, port 742 dock's: bwnfsd, UDP, port from portmapper Note again that options set a state which remains in effect until changed. Page 40 Remote Printer Support Remote Printer Support Remote Printer Support This section discusses the behavior of remote printers mounted on your PC's printer ports/printer device names. You should also review the NFSDRVR '-l' option, and the FSTAB 'printer' options discussed in the sections above. To support remote printing, you will need to install and configure either the PCNFSD or BWNFSD authentication and printer servers on the host which has the printer you are planning to print to. (PC)NFS style printing works by writing the redirected printer output to a file on the printer server via the NFS protocol, then when the print job is ready to be printed, the (PC)NFS client tells PCNFSD or BWNFSD to print the spooled job. Consult the documentation for the PCNFSD/BWNFSD daemons to configure them. NFSDRVR redirects two methods of printing. The third, direct output to the printer I/O port hardware can't be redirected by real-mode software but is rarely used by application software. The first printing method NFSDRVR redirects is output via software Interrupt 17h. The default DOS Int 17h handler supports three printers, 0 through 2, which coorespond to LPT1: through LPT3:. NFSDRVR supports printers numbered 0 through 8 which cooresponds to LPT1: through LPT9:; PRN: is equivalent to LPT1:, and mounting either automatically mounts the other pointing at the same remote printer. The Interrupt 17h interface is very simplistic and does not support the notion of a device "open" or "close"; as such, NFSDRVR has no way to be sure of when a print job has started or (more importantly) stopped and when it should tell the PCNFSD/BWNFSD server to print the remote file. The work around used by NFSDRVR and other (PC)NFS software is to timeout print jobs done via Int17h; the print job is considered to start when the first byte of data is written, and to end after a timeout expires with no byte written to the printer in that amount of time. The default for NFSDRVR printers is 30 seconds, but this value can be changed with the 'printer' fstab option (see the FSTAB section above). This timeout is also applied to jobs printed via the character device driver which are not closed in due time (see below). The second method of redirecting printing is via a character device driver. Fortunately, device drivers have open and close functions, so NFSDRVR can tell when a print job starts and stops. When a print job done via the character device driver is closed, NFSDRVR tells the remote printer server to print it immediately without waiting for a Page 41 timeout. When you 'copy' to a printer ("copy LPT1" for example), the character device driver is used. NFSDRVR supports mounting printers on devices named LPT1: through LPT9: and PRN: (where PRN: and LPT1: are equivalent, and specifying either automatically directs the other at the same remote printer). When mounting a printer, specify the printer name as known by pcnfsd or bwnfsd on your printer server in place of the file system path. See the FSTAB and mount sections of this manual. Mount knows you are mounting a printer when you specify a printer device name instead of a drive letter, or when the printer= fstab option is used. Page 42 The NFSINFO Program The NFSINFO Program The NFSINFO Program The NFSINFO program displays information about the configuration of the loaded NFSDRVR, and currently mounted file systems. The fields in its output correspond to command line options to NFSDRVR, and 'fstab' file system options. Several command line options are available to control its output as follows. Multiple options may be specified to one invokation and are processed from left to right. -? Displays a brief help screen. If this option is specified, all others are ignored. -i Display resident driver information. This option displays general information about the driver's configuration and current state. -a Display information about all mounted devices. This option displays information about all NFS drives, followed by all NFS printers. d: Display information about a specific drive. lptx: Display information about a specific printer. These options display information about the NFS drives and printers specified. If the specified drive or printer is not an NFS device, a brief message to that effect is displayed. -v[-] Enables (disables) verbose device info. This option enables (disables) the longer form of device information. If verbose output is disabled, only a one line summary is displayed for drives and printers instead of also listing the options associated with the device. Verbose output is enabled by default. This option takes effect until altered (from left to right). For example, "nfsinfo -v- d: -v lpt1:" will display the shorter one line of information about drive D:, but display verbose options associated with LPT1:. If NFSINFO is run with no options, it will by default display both general driver information and information about all NFS drives and printers, and is equivalent to running "NFSINFO -i -a". Page 43 Performance Tuning Performance Tuning Performance Tuning The default values that NFSDRVR uses for several of its options are very conservative to help make sure the client will function properly with the widest range of computers and Ethernet cards, as well as keep memory requirements low since increased performance is often at the expenses of extra buffer memory. If you want to achieve the best possible performance from this NFS client, it is essential that you tune these parameters increasing the options described below to the largest values that give you reliable performance. We've found our NFS client, when tuned properly, to possibly be the fastest DOS NFS clients available today in most Ethernet LAN client/server environments (WatTCP and LWP versions; due to some restrictions in the LanMan and Trumpet TCPDRV TCP/IP stacks, it's not always possible to achieve comparatively fast performance with them). If you have trouble tuning the client and getting reliable performance (that is, without excessive timeouts), please contact us for assistance! The 'readwin' and 'rsize' file system options can improve performance of large-block file reads, primarily with DOS file execs and copies which do nearly 64KByte reads, and other applications which may do large reads. But tuning these too high can cause packet loss and degrade performance because of excessive retransmissions. There is also a tradeoff with larger rsize values since more buffer space is required (see the -r option to nfsdrvr.exe). These options are considered experimental at present. We are very interested in feedback on the optimum values for different Ethernet cards and CPU speed combinations. We are also still experimenting with packet input buffer handling in the WatTCP client to see if it may be a bottleneck. Please email your configuration and results to nfs@tsoft.net. To get a measurement of the large-block speed you'll need to use DOS (or a large-block copy) to read files from your NFS server. You'll need to be the judge on which file mix you choose. Keep in mind whether or not the file has been read into your servers' disk cache can affect the speed. [Naturally, large-block reads is only one aspect of performance; you should use them for tuning purposes, then compare performance doing your normal usage patterns to compare overall performance with other clients.] To make it readily apparent when dropped packets are becoming a problem, start by temporarily setting the timeout Page 44 on the file system to 30 seconds. Dropped packets are the main clue that rsize/readwin are too high. Set readwin=1 and then increase the rsize on the file system until packets start dropping (and back off). Then adjust the readwin up slowly until performance levels off; packets may also start to drop. Finally, reduce the rsize to a comfortable level. It's generally best to have readwin just slightly above where it gives best performance. The bottom line is to try various combinations of readwin and rsize to see what works best for you, and please let us know! We've found a 4KB rsize and readwin=3 to give good performance in our environment, with increasing rsize to 8KB giving only marginal benefit and increasing readwin to give none. If you suspect problems, try the settings of least resistance: readwin=1, rsize=1024 (or smaller). If you suspect packet loss, increasing the number of receive buffers in your TCP/IP stack may help alleviate the situation, if the problem is not in the network itself. The wsize option can be adjusted in a similiar fashion. Note that some protocol stacks don't support wsize's that result in packets larger than a single Ethernet packet. There is presently no writewin option but will be eventually. Page 45 Companion Utilities -- Distributed Separately Companion Utilities -- Distributed Separately Companion Utilities -- Distributed Separately A number of companion utilities for Tsoft's NFS Client are distributed separately, currently in a Zipped file called NUTIL*.ZIP (where * = version ID). The companion utilities provide Unix work-a-like's and useful utilities for dealing with files on NFS drives. Many of the programs are also NFS-aware in that they recognize "long", case- sensitive filenames on NFS drives; NFDIR and LS are two companion utilities for listing long names on NFS drives. The utilities also function on DOS local drives and non-NFS drives. The utilities are not tied to the TCP/IP stack version of the NFS client, so the executables in the single distribution file can be used with any of the TCP/IP stack versions. They are however tied to the version of an API provided by the NFS clients, so sometimes (but not always) upgrading the numeric version of NFSDRVR will require you to upgrade the Companion Utilities. If the applications detect an NFSDRVR loaded but the API versions don't match, it will warn you of this and treat NFS drives as if they were non- NFS drives. It is generally recommended that you use the latest versions of both NFSDRVR and the Companion Utilities. The utilities are licensed along with Tsoft's NFSDRVR. Your registration fee includes the right-to-use the Companion Utilities under the same terms; the same 30-day evalutation period applies. If you would like to license the Companion Utilities for use on non-NFS drives without licensing NFSDRVR, please contact Tsoft to negotiate a reduced-cost license. For suggested locations for obtaining the Companion Utilities, see the Appendix on Obtaining Software. Page 46 Appendix A: WatTCP Appendix A: WatTCP Appendix A: WatTCP The WatTCP version (built-in TCP/IP) of this NFS client makes use of Erick Engelke's excellent WATTCP TCP/IP programmers libraries. This appendix provides some notes on using the WatTCP version of this software. _________________ Install a PKTDRVR WatTCP uses a PKTDRVR to interface with your network card. See the section above on PKTDRVRs to install a driver for your card. _________________________________________ Configuring WatTCP: the "WATTCP.CFG" File The WatTCP client uses a standard WATTCP.CFG file to configure your IP number, any name servers, and routes to other internetwork subnets if you are part of a larger network. If you do not provide a WATTCP.CFG file, the software will by default attempt to configure itself by broadcasting a BOOTP protocol request. If you have a BOOTP server on your network which already responds to requests for your PC, you can skip this step; if you're not sure, consult your network administrator. The format of the WATTCP.CFG file consists of any number of lines each consisting of a keyword and value of the form: = The following are some of the important keywords and the types of values expected. Your local network administrator or guru can likely help you with the values, as they vary from site to site. my_ip Your PC's IP number in "dotted quad" notation. ie. my_ip=140.174.87.25 netmask The "netmask" identifying the IP subnetwork your PC is on. ie. netmask=255.255.255.0 hostname The name of your PC. This should be the same name the NFS server knows your PC as. ie. hostname="professor" hostname="professor.tsoft.net" Page 47 gateway The gateway or router to send network packets to which are destined for hosts *not* on the same subnet as your PC. ie. gateway=140.174.87.2 Note that the gateway/router has multiple IP addresses since it is on multiple subnets(which it routes between). The IP number you use for the gateway keyword should be the router's IP number on the same subnet as your PC. An example WATTCP.CFG file might look like this: my_ip=140.174.87.25 netmask=255.255.255.0 hostname="professor.tsoft.net" gateway=140.174.87.2 The WATTCP.CFG file is searched for in a couple places: o The environment variable WATTCP.CFG specifies the location of the file. o The current directory (when you run the above two programs). ___________________________________________________ WatTCP Sample Applications and Debugging Your Setup The WATTCP Sample applications include a much more detailed description of the WATTCP.CFG file. It is highly recommended that you obtain the sample applications for this documentation and also to test out your WATTCP.CFG file before trying it with the NFS client. It will be much easier to debug your WATTCP.CFG file with, for example, the sample 'ping.exe' program than with the NFS driver. Please see the appendix on obtaining software for where to get the WATTCP sample applications. __________________________ Support of /etc/hosts file The NFS driver provides support for an /etc/hosts file in the MOUNT program to specify local name to IP address translations (instead of or in addition to a DNS nameserver). Note that /etc/hosts is NOT consulted when processing the WATTCP.CFG file. The 'ETCDIR' override is available for specifying the location of 'hosts' as well. The format of the file is the same as it is on Unix hosts. Lines which begin with '#' are comment lines. Other lines should have a host IP number (in "dotted quad" Page 48 notation) followed by one or more hostnames which correspond to the host IP address. The following is an example 'hosts' database line specifying two names for one host IP address: 140.174.87.1 gilligan tsoft.net When looking up a hostname, MOUNT first consults the /etc/hosts file. If the name is not found (or there is no hosts file), MOUNT queries the DNS nameservers (configured in WATTCP.CFG above). If you do not use a hosts file and have no DNS nameservers configured, you will have to specify all your IP addresses in dotted quad notation. ________________________________________________________ The Internal Packet Multiplexor: Trumpet Winsock example Under the manual sections above, we mention a single channel internal packet multiplexor. See the '-m' and '-v' options to WatTCP NFSDRVR above for options to configure the mux, although the defaults are usually suitable. This mux will let you run the Trumpet Winsock without an external packet multiplexor saving several Kbytes of memory. We offer as an example the programs you'll need to run and in what order with some comments; you should be sure to review the documentation of each program as well as the manual sections above for details. Note that NFSDRVR will not work over Trumpet Winsock's internal SLIP because it doesn't and can't really provide a pktdrvr interface for NFSDRVR to use. Example: Trumpet Winsock 1) Your pktdrvr. This is the driver for your network card, usually Ethernet. For purposes of the example, let's assume the PKTDRVR API has been installed on interrupt 0x60. 2) nfsdrvr.exe. Load the WatTCP version of NFSDRVR. Assuming the defaults, NFSDRVR will find the pktdrvr at interrupt 0x60 and install it's internal multiplexor on 0x60 hiding the real pktdrvr underneath. 3) mount.exe, with any desired options, to mount NFS drives. 4) winpkt.com. This driver provides essential services for pktdrvr applications, such as Trumpet tcpman, running Page 49 under MS-Windows, including ensuring that the application's packet receiver function receives packets from the packet driver properly. winpkt is included with Trumpet winsock as well as available separately and will usually be run with the single argument of the interrupt your pktdrvr is on, in this case 0x60 for the NFSDRVR pktdrvr mux interrupt. Note that winpkt should be run after NFSDRVR so that it ensures TCPMAN's packet receiver works properly, rather than try to help out NFSDRVR which doesn't need any because it's a DOS application. 5) win, to start MS-Windows 6) TCPMAN to start Trumpet Winsock. You'll need to install and configure it of course, as described in its documentation. 7) Start using your Winsock applications. Summary: pktdrvr on interrup 0x?? nfsdrvr mount winpkt 0x?? win tcpman ... winsock applications ... Page 50 Appendix B: Trumpet ABI Protocol Stacks Appendix B: Trumpet ABI Protocol Stacks Appendix B: Trumpet ABI Protocol Stacks The Trumpet ABI is a standard application software interface proposed and published by Peter Tattam. Peter offers an implementation of the standard as the Trumpet TCP/IP stack. This driver currently requires use of version 3.x of this driver (but will be updated when new versions are available); version 2.x will not do. Note that as of this writing the TCP ABI specification has not been upgraded to reflect version 3.x of his implementation. Please consult the documentation which comes with the Trumpet TCP stack (or other TCP ABI implementation) to install and test the stack, then follow the directions contained in the main portion of this document for loading NFS. ______________________________ Hostname to Address Resolution The NFS client can use an /etc/hosts file as described in the appendix above for WatTCP. It will also query DNS nameservers, up to the four you can configure with the Trumpet TCP stack. ______________________________________________ Trumpet TCPDRV and the 'rsize'/'wsize' options The Trumpet TCP stack doesn't currently support IP defragmentation, so be sure not to set rsize too high or the client will never get replies to read requests and will timeout. The current Trumpet TCP stack also does not appear to support IP fragmentation on UDP sends, thus wsize is limited to a bit over 1KB also. The NFSDRVR and MOUNT will let you configure for rsizes and wsizes up to the 8K maximum to work with future Trumpet ABI stacks if they support IP defragmentation/fragmentation. Page 51 Appendix C: Other External Protocol Stacks Appendix C: Other External Protocol Stacks Appendix C: Other External Protocol Stacks When using any other protocol stack, you should follow the directions included with the stack for installing any drivers necessary and the stack itself. If the stack doesn't come with the driver (PKTDRVR, NDIS, ODI, etc.) appropriate for your particular card, check any diskettes which came with your network card, and the "Obtaining Software" section of this manual. Once you have the protocol stack installed and tested, you can load the NFS driver by starting with the section on NFSDRVR above in this manual. ______________________________ Hostname to Address Resolution Tsoft's NFS client follows the standard practice of the particular protocol stack you use for resolving hostnames to IP addresses. Most stacks provide a local file lookup (ie, /etc/hosts) and either or both of DNS nameserver or NIS (Network Information Service) to translate names. Consult the protocol stack's manual for configuring name to address translation. _________________________________________ MS LanMan TCP/IP / Hewlett-Packard / 3Com Be sure to load the sockets TSR, SOCKETS.EXE in the Microsoft stack. You should also increase the 'maxsendsize' verb in the tcputils.ini file to about 1500 to allow maximum sized ethernet packets to be sent (for MS stack, HP/3Com configuration may vary), or decrease the wsize on all filesystems (there is overhead in each packet beyond wsize). The MS LanMan TCP stack does not presently appear to support IP fragmentation on sends and thus wsize is limited to a bit over 1KB (see the 'maxsendsize' verb also). _________________________________ Novell LAN WorkPlace (LWP) TCP/IP This version of Tsoft's NFS for LWP has been tested with LAN WorkPlace version 4.1x. Page 52 It's advisable to have a 'hosts' file (typically in c:\net\tcp) with your own machine's hostname and IP address listed, or to have the hostname returned by the 'bootp' server. This makes sure NFS can find the actual hostname of your computer and won't use the IP address of your host in (ascii) dotted quad notation. (Whether this would be a problem depends on the NFS server; usually it isn't). The Novell LWP TCP stack appears to support IP fragmentation on sends, but possibly not up to 8KB. (There may be a net.cfg adjustment, but we haven't found it). Try increasing the wsize slowly in say 512 byte increments. Page 53 Appendix D: Obtaining Software Appendix D: Obtaining Software Appendix D: Obtaining Software Updates to this software, as well as useful shareware and freeware utilities and related software can be obtained by several means. This section is intended to point you in the right direction to obtain the software. Novell LAN WorkPlace is commercial software and is available from Novell, Inc. and Novell resellers with a host of TCP/IP applications. The LWP TCP/IP stack itself is also licensed by Novell and you may find it bundled with third- party TCP/IP applications. _______ Methods: ftp -- refers to anonymous ftp on the Internet Ftp to the host, login as 'anonymous' and use your E-mail address as the password. Look for the files and indexes in the specified directory. BBS -- a bulletin board, usually dialup by modem Dial the BBS with a modem and follow the prompts or notes below. Download the software using a file transfer protocol. Some of the software can also be obtained on CD-ROM, although software on ROM may not always be the latest version. A packet-driver CD is available which includes the Crynwr packet driver collection, as well as useful utilities. NFSDRVR and Companion Utilities -- this software ~~~~~~~ ~~~~~~~~~~~~~~~~~~~ ftp: ftp.tsoft.net:/pub/tsoft/nfs Trumpet TCP Stack ~~~~~~~~~~~~~~~~~ ftp: ftp.utas.edu.au:/pc/trumpet ftp: ftp.tsoft.net:/pub/tsoft/trumpet-abi PKTDRVRS - ethernet (and othernet) card drivers ~~~~~~~~ ftp: wuarchive.wustl.edu:/mirrors/msdos/pktdrvrs ftp: oak.oakland.edu:/pub/msdos/pktdrvrs ftp: ftp-ns.rutgers.edu:/pub/msdos/packet-drivers dis_pkt9.zip: Gives a pktdrvr interface when loaded on top of an NDIS driver. Page 54 odipkt: Gives a pktdrvr interface when loaded on top of an ODI driver. Authentication Daemons (pcnfsd and bwnfsd) ~~~~~~~~~~~~~~~~~~~~~~ ftp: ftp.tsoft.net:/pub/tsoft/unix PKTMUX - ~~~~~~ ftp: ftp.tsoft.net:/pub/tsoft/pktdrvrs ftp: ftp-ns.rutgers.edu:/pub/msdos/packet-drivers WATTCP - freeware programmers libraries for TCP/IP ~~~~~~ ftp: ftp-ns.rutgers.edu:/pub/msdos/wattcp MS LanMan TCP/IP Stack ~~~~~~~~~~~~~~~~~~~~~~ ftp: ftp.microsoft.com:/Advsys/MSclient BBS: Microsoft Download Service at ??? Page 55 Appendix E: Troubleshooting -- Common Problems Appendix E: Troubleshooting -- Common Problems Appendix E: Troubleshooting -- Common Problems Q: The Trumpet ABI version seems to always timeout if I specify an rsize larger than about 1200 bytes. A: The current Trumpet NTCPDRV doesn't support fragmented IP packet reassembly and therefore can not receive read replies larger than a single Ethernet packet. You must reduce rsize until the stack is upgraded to support it. Q: The Trumpet ABI version seems to corrupt data I write to files on the NFS drive. A: You may be using version 2.x of the Trumpet TCPDRV stack. Version 2.x seems to have a bug handling write requests larger than approximately 512 bytes and inserts garbage data from memory. You should upgrade to version 3.x of NTCPDRV; a TCP ABI data structure also changed and NFSDRVR assumes a 3.x format structure so you should be using 3.x regardless. Q: I have the Trumpet Winsock; how do I get NFS to run inside windows? A: Trumpet Winsock and Trumpet TCPDRV are two different protocol stacks. The latter is supported by NFSDRVR but the former (and any winsock for that matter) isn't supported (yet, if it's possible). Q: How can I run Trumpet Winsock with NFS? A: The recommended method now is to use the internal packet multiplexor with Trumpet Winsock. See the manual section on the WatTCP version for an example of what you need to run Trumpet Winsock and NFS together. Q: If I specify TCP protocol in an fstab option, for example for the auth= option, MOUNT fails connecting to the service. A: Daemons such as the authentication daemons may by default startup to only support UDP requests. Whether the daemon supports TCP and UDP, or just UDP can depend on how it was compiled or the command line options used to start the daemon on the server. If your server has the 'rpcinfo' program (often in /usr/etc) then 'rpcinfo -p' will give you a list of services started; see if the daemon you're contacting has registered the TCP protocol as well as UDP with the portmapper. Q: I get occasional lockups with the WatTCP version when reading files though I can do directories seemingly without problems. Any ideas? A: If you're running an older version of the Crynwr pktdrvrs, try upgrading to the v11 driver. It seems nfsdrvr v0.25 and later may tickle a problem with at Page 56 least the v10 NE2000 driver, but the problem disappears with the v11 Crynwr driver. Q: I'm trying to use MS Excel (and other applications) but... Q1: ... they tell me I need to load SHARE.EXE, but I have. A1: You must enable one of the NFSDRVR file locking options... lock= in fstab. It's recommended that you use one of the real file locking options, NLM or bwnfsd. SHARE.EXE only provides services for local drives, but Excel displays the same error message when it detects NFSDRVR or other network drive software has locking support disabled. Q2: ... when trying to load a file, they tell me they "Can't Access" (or similiar) the file. A2: ... if you are using NLM file locking, it's quite possible your rpc.lockd doesn't support lock requests with the High-bit set in the offset field; Excel makes these requests, and according to the NLM protocol specification they are valid. On Sun servers, this problem is revealed by "fcntl: Invalid argument" messages on the console of the server. You can work around it by using the lock=nlm,signedlocks option; 'signedlocks' will clear the high bit before making the requests.