The knfs command enables users to authenticate with AFS when they are working on NFS clients of unsupported system types (those for which AFS binaries are not available). This enables such users to access the AFS file tree to the same extent as any other AFS user. They cannot, however, issue AFS commands, which is possible only on NFS client machines of supported system types.

To authenticate on an unsupported system type, establish a connection to the translator machine (using a facility such as telnet), and issue the klog command to obtain tokens for all the cells you wish to contact during the upcoming NFS session. Then issue the knfs command, which stores the tokens in a credential structure associated with your NFS session. The Cache Manager uses the tokens when performing AFS access requests that originate from your NFS session.

More specifically, the credential structure is identified by a process authentication group (PAG) number associated with a particular local UID on a specific NFS client machine. By default, the NFS UID recorded in the credential structure is the same as your local UID on the translator machine. You can include the -id argument to specify an alternate NFS UID, unless the translator machine's administrator has used the fs exportafs command's -uidcheck argument to enable UID checking. In that case, the value of the -id argument must match your local UID on the translator machine (so there is not point to including the -id argument). Enforcing matching UIDs prevents someone else from placing their tokens in your credential structure, either accidentally or on purpose. However, it means that your cell's administrators must set your local UID on the NFS client to match your local UID on the translator machine. It also makes it impossible to authenticate by issuing the klog command on supported NFS clients, meaning that all NFS users must use the knfs command. See Controlling Optional Translator Features.

After issuing the knfs command, you can begin working on the NFS client with authenticated access to AFS. When you are finished working, it is a good policy to destroy your tokens by issuing the knfs command on the translator machine again, this time with the -unlog flag. This is simpler if you have left the connection to the translator machine open, but you can always establish a new connection if you closed the original one.

If your NFS client machine is a supported system type and you wish to issue AFS commands on it, include the -sysname argument to the knfs command. The remote executor daemon on the translator machine substitutes its value for the @sys variable in pathnames when executing AFS commands that you issue on the NFS client machine. If your PATH environment variable uses the @sys variable in the pathnames for directories that house AFS binaries (as recommended), then setting this argument enables the remote executor daemon to access the AFS binaries appropriate for your NFS client machine even if its system type differs from the translator machine's.

If you do not issue the knfs command (or the klog command on the NFS client machine itself, if it is a supported system type), then you are not authenticated with AFS. For a description of unauthenticated access, see Enabling Unauthenticated or Authenticated AFS Access.