Allegro NFS for Windows

“Brought to you by the brittleness of other NFS products.”

. Documentation
. FAQ

Allegro NFS Server documentation

Allegro® NFS Server supports NFS protocols V2 and V3 (NEW for 4.0). It has been tested against a large number of NFS clients, ranging from Linux, Solaris, Mac OS X, FreeBSD, AIX, HP-UX and more.

Configuration overview

Exports

The primary configurable item in Allegro NFS Server is the export. Exports define a directory tree that will be made accessible to NFS clients. Exports have several important parameters:

name	The name of an export is the string that clients use to identify the export. While just about any string is allowed, it is recommended that you use a string that doesn't contain any spaces or other characters that have special meaning in a Unix shell. Also, export names customarily begin with a slash (/), but this is not a requirement.
path	This is the local directory that will be shared by the export. It can also be a UNC share (e.g., \\host\share).
uid	All files will appear to be owned by this user id. NFS Clients accessing with this user id will have read/write permission to all files in the export.
gid	All files will appear to be owned by this group id. In Allegro NFS Server, the group id does not play any part in controlling access permissions.
umask	This alters the file mode bits that are reported to NFS clients. By default, all regular files report mode 0666 (rw-rw-rw-) mode. Files with filename extensions that are usually executable (.exe, .com, .bat, etc) report mode 0777 (rwxrwxrwx). Directories report mode 0777. You can use the umask to turn some of the default mode bits off before reporting them back to the client. Unless you have special needs, it is recommended that you leave the umask setting at 0. See the Notes section below for more information. The parameter is expressed in octal notation.
set mode bits	This parameter is the flipside of the umask. It is expressed in octal notation and specifies which mode bits should be turned on before reporting them back to the client. See the Notes section below for more information.
allow host lists	By default, no remote hosts are allowed to access an export. You can use this parameter to specify lists of remote hosts/networks that should be granted access. See below for more information on host lists.
read/write user lists	Remote users having user id matching the "uid" parameter (above) automatically have read/write access. You can use the read/write user lists parameter to specify lists of other users that should also have read/write access. You can select more than one list. See below for information on user lists.
read-only user lists	Remote users having user id matching the "uid" parameter (above) automatically have read access. You can use the read-only user lists parameter to specify lists of other users that should also have read-only access. You can select more than one list. See below for information on user lists.

User lists

A user list is a named list of numeric user ids. There is a built-in user list called "everyone" that implicitly includes any possible user id. You can make your own user lists by selecting the "User lists" tab and clicking the "New" button. You will be prompted for the name of the new list. This will create an empty list. You can add user ids to the list by filling in the "New user id" edit box and clicking the "Add" button. You can add as many user ids as you want to a list. The same user id can be used in multiple lists. The simplest useful user list would have just one user id.

User list examples:

Let's say you have the following remote users:

name:	  id:
joe	  150
bob	  160
jane	  170
sally	  180

You could make 4 new lists, each named after one of the users... and each of those lists could have one entry; the user id of the named user. Then you could add or remove any of those single-element user lists to any exports to give that user access.

If bob and jane are both software developers, you might make a list called "developers" and add user ids 160 and 170 to it.

Host lists

A host list is a named list of Internet Protocol (IP) host or network addresses. There is a built-in host list called "all" that implicitly includes any possible remote hosts. You can make your own host lists by selecting the "Host lists" tab and clicking the "New" button. You will be prompted for the name of the new list. This will create an empty list. You can add IP addresses to the list by filling in the "New address" edit box and clicking the "Add" button. You can add as many addresses as you want to a list. The same address can be used in multiple lists. The simplest useful host list would have just one address.

How to specify addresses:

IP addresses can be specified in several ways:

IP address This is just the IP address of a host, in dotted (xxx.xxx.xxx.xxx) notation. This is used for specifying single hosts.

CIDR format You can specify a range of addresses this way. The format is xxx.xxx.xxx.xxx/pp, where xxx.xxx.xxx.xxx is the network address and pp specifies the prefix length, that is, the number of bits that form the network part of the address. For example, 1.2.3.0/24 matches any address of the form 1.2.3.xxx.

IP address/netmask format You can specify a range of addresses this way as well. The format is xxx.xxx.xxx.xxx/yyy.yyy.yyy.yyy where xxx.xxx.xxx.xxx is the network address and yyy.yyy.yyy.yyy is the netmask. For example, 3.4.5.0/255.255.255.0 matches any address of the form 3.4.5.xxx.

Global settings

NFS/mountd protocol debugging	You can turn these options on if you want to see what's going on at the protocol level. Debugging output will be generated in the console window. Be careful! Turning on NFS protocol debugging can generate lots of output.
Use system portmapper	Possible values are auto, yes and no, meaning auto-detect and use another running portmapper, always use the system portmapper and always use the Allegro portmapper, respectively.
Mount protocol port number	If you want the mountd subprocess to always use a specific port number, you can supply that port number here. If you have a firewall, we recommend that you read this FAQ entry for more information on this topic.

Misc

Exports should always grant at least read access to user id 0 (root) so that the root user on remote systems can successfully mount the export.

Umask/set-mode-bits: It may seem that the default file mode bits (typically rw-rw-rw-) that are reported by the NFS server are too loose. There is a reason for this, however. Most NFS clients will check the permission bits before sending requests to the NFS server. If the permission bits indicate that the operation would not succeed, the client does not send the nfs request to the server at all. This could be a problem when you are using complex user lists. Here is an example that will explain what can go wrong:

user list:
  testers: 400, 401, 402

export: 
  name: /testing
  path: c:\temp
  uid: 100
  gid: 100
  rw-user lists: testers
  umask: 0 (default)

With this setup, user ids 100, 400, 401, and 402 will have read/write access to export. The NFS client will see loose file permissions and will send all write requests over to the server. The NFS server will then do its own security checks and grant write access only to user ids 100, 400, 401, and 402. However, if the umask were set to 022 then the NFS client would conclude that the files could only be written to by user 100.. and attempts by user ids 400, 401, and 402 would not even be passed on to the NFS server.... defeating the utility of user lists.