The volume(s) must be exported properly.  The export configuration is contained in /etc/exports (with options in parentheses) but can also be viewed / changed in Yast, Network Services, NFS Server.  For NSS volumes, an entry in the exports file should include certain options, and generally will look like this:

 

/media/nss/DATAVOL  *(fsid=n,no_root_squash,sync,rw)

 

Explanations:

 

1.  /media/nss/DATAVOL is the path to be exported.  You can export the entire volume as shown above.  Or you could export just a portion, such as /media/nss/DATAVOL/dir1/subdir1

 

2.  "*" indicates that any/all nfs clients are allowed to mount.  You can be more restrictive by specifying a subnet of allowed clients, a netgroup, or a single host address or name.  You can also list separate clients individually, such as:

/media/nss/DATAVOL   host1(fsid=n,no_root_squash,sync,rw)   host2(fsid=n,no_root_squash,sync,rw)

 

3.  fsid=n:  "n" must be nonzero, 1-255.  And for each different NSS directory path you are exporting, a unique fsid is required.  But the same path exported to multiple hosts would all use the same value. FSIDs are needed because NSS volumes are logical entities and do not have the normal device identifiers that disk drives have.  Without fsid=n, NFS can get confused about which volume to query if multiple volumes are being exported and then mounted by NFS clients.  Or even with only a single volume being exported, if fsid is not set and the volume is part of a cluster, the logical identity of the device may change when it moves from node to node, preventing clients from accessing it after the move.

 

4.  no_root_squash:  Officially, this is mandatory, so care should be taken to limit what hosts can mount the export (as the root user of the NFS client host will be able to act as the root user on the NSS exported path).

 

However, due to potential security concerns with allowing root access, some administrators chose to set this up in another way.  This alternative way is thus far considered experimental, and not thoroughly tested:  It seems that the key requirement here is that the user who is requesting the mount (typically root) have at least Filescan rights to the NSS volume.  If root is "squashed" he is treated like "nobody."   Typically, "nobody" does not have access, neither through its own merits nor by being associated with any LUM-enabled user in eDir.  However, an eDir user can be created and LUM-enabled, given Filescan right to the NSS volume(s), and then the UID assigned to that user can be used as the "anonuid" for that particular export.  So, for example, if the user in question was given UID 1011, then instead of merely "no_root_squash" the combination of "root_squash,anonuid=1011" could be used.

 

In that case, be sure to remember:  Even after mount, the "squashed root user" will be treated as having whatever rights the anonuid user has been given.  Also remember that if you happen to use the "all_squash" export parameter as well, all NFS client users (not just eDir users and not just root) will be treated as the anonuid user, and will be able to access the NSS volume.

 

5.  sync:  Mandatory, needed for data integrity.

 

6.  rw:  It is recommended to make the export rw, then let Novell Trustee rights limit whether or not writing is actually allowed.  However, this author has not yet seen any problem when exporting "ro" instead of "rw", if NFS clients indeed will not need to write.  In fact, if NFS clients do not need to write, then using "ro" gives added protection against remote root users, who otherwise would be able to make changes to the volume, even without trustee rights being granted.  (See point #4 above for alternatives in that regard).

 

See "man exports" for more information on export syntax.

 

Note that Novell supports NFS exporting/mounting an NSS volume through NFSv3, not NFSv4.

 

 

 

Some of the following issues are written from the perspective of comparing NetWare 6.5. NFS functionality to OES Linux functionality.  However, even those without experience on NetWare will find useful insights into NFS / NSS functionality on OES Linux here.

 

The NFS Server on NetWare 6.5 was uniquely designed to handle NetWare NSS volumes, and to allow some special conversion between access methods on NetWare and Linux / Unix.  In contrast, the NFS Server on OES Linux is simply the standard Linux NFS Server, and doesn't have any special knowledge of NSS.  This brings up several important points to consider:

 

 

With NetWare, trustee rights governed the access of NCP users, but the posix permissions in the NFS name space of the volume governed the access of NFS client users.  On OES Linux, an NSS volume's posix permissions are not directly used to determine access.  Access (even for Linux user processes) is governed by trustee rights.  This becomes very important as we consider the next topic, Access Control Modes.

 

 

NetWare NFS Server had 2 access control modes to govern how users on an NFS client would be given access to a NFS share.  They were known as "Independent Mode" and a "NetWare Mode."  Without going into a detailed explanation of these modes, a sufficient summary may be that Independent Mode allowed the posix permissions in the NFS name space to be set completely independently of trustee rights.  Neither the user-owner of the file nor his permissions had to be equivalent to a NetWare object or it's trustee rights.  In NetWare mode, 3 entities (one user, one normal group, and one special group that represented "everyone else") would have their trustee rights translated into posix permissions and written into the NFS name space.  In both modes, the NFS Server would then use those posix permissions to grant or deny access to the files.

 

With OES Linux, NSS access is always governed by Novell Trustee Rights and Attributes (except for access by the root user).  In some ways, this resembles the old "NetWare Mode," but with a large leap forward in terms of flexibility.  Through true Trustee Access, many more NFS users can have unique, granular access assignments to the NSS volume.  The precise appearance of the posix permissions does not determine the access that will be allowed.  Posix permissions can be a "reflection" of some things about access, but they are not "in control" of access.  For some purposes, they can be considered "dummy" or "filler" values.

 

[Side note discussion, for those interested in deeper information on posix permissions on an NSS volume:  There are subtle ways that the posix permissions may vary, depending on special Novell attributes which may be set on files or directories.  For example, the "read only" attribute on a file may cause the posix permissions to show r--r--r--.  Or having both 'read only' and 'hidden' attributes set may cause posix permissions to be completely cleared (---------).  Additionally, certain "chmod" commands may alter the appearance of the posix permissions, and behind the scenes this can cause Novell file attributes to be set or cleared.  For example, changing permissions from r--r--r-- to rw-rw-rw would clear a "read only" attribute.  Thus, posix permissions are not fully without meaning.  However, they will typically be merely a loose reflection of the Novell trustee rights and attributes in place.]

 

If this evolution of the access control model is a concern, administrators could consider using a more standard Linux file system like xfs, ext3, or reiserfs.  Those file systems could be shared both via NFS and via NCP, which would once again separate the concept of Posix permissions from Trustee Rights.  This would approximate the "Independent Mode" that was available in NetWare.

 

 

Because of the way the NetWare NFS Server was designed, especially with Independent Mode, it offered the ability to have many NFS client users access an NSS file system without consuming user licenses for the Novell Tree.  OES Linux does not offer quite the same advantage for NFS access to NSS volumes.  All NFS users (other than root) who wish to access the NSS volume must have a UID that corresponds to a that of a LUM-enabled user in the eDirectory tree, which has effective trustee rights to the NSS volume.  Therefore, in some cases, more user licenses may be needed.

 

However, there are 2 alternatives to this situation:

 

A.  All NFS client users could be treated as one user.  If it is acceptable that *all* users from a certain NFS client host have access to the NFS share, and all their access is the same, then the export could be configured with the combination of "all_squash,anonuid=n" where "n" is the UID of a LUM-enabled eDirectory user with the desired rights to the NSS volume.

 

B.  Administrators may wish to create and share a more standard Linux file system like xfs, ext3, or reiserfs.  Those file systems could be shared both via NFS and via NCP, which would once again separate the concept of Linux user access from eDirectory user access.  While NCP access would still require user licenses, NFS access would not.

 

 

As stated earlier, the NetWare NFS Server was specially designed for NSS volumes.  The Linux NFS Server is not.  NFS on Linux expects file systems to act in the "traditional Linux" manner, so this can cause some unexpected behaviors when NSS volumes are in use.

 

On a tradition Linux file system, everyone who has access to files or subdirectories within a parent directory will have the exact same view of the contents of that parent directory.  For example, if user1 has exclusive access to his own home directory (/home/user1) and user2 has exclusive access to his own home directory (/home/user2), both users must have at least read and execute (r-x) granted to /home, and this allows each of them to see the full contents of a /home directory listing.  Both will see that each other's home directories exist.  Their "view" is universally the same.  That is, 2 users who can access the same directory will alway see the same contents of that directory.  Since that is true, NFS clients are designed to cache the contents of a directory list, and use that cache to answer directory listing queries for any and all users.

 

NSS volumes, on the other hand, can show different directory contents to different users.  Imagine an NSS volume containing the /home structure described above.  This would locally be seen as /media/nss/VOL1/home, but for simplicity we will still refer to this as /home, /home/user1, etc.  With NSS, user1 can have exclusive rights to /home/user1, and user2 can have exclusive rights to /home/user2, but neither of them need to have any rights granted to /home, neither explicitly nor through inheritance.  If no rights are granted to /home, each user will have a "partial" view of what /home contains.  This is accomplished through Novell's concept of "visibility rights".  Each user automatically has the right to "visibility" throughout the path that leads to the location where his actual rights exists.  For example, when residing in /home, user1 will have the right to see that /home/user1 exists, but will not have the right to see that /home/user2 exists.  Hence on NSS, different users can have different views of what "the same" directory list looks like.

 

Imagine putting these 2 concepts together.  NFS Clients assume that one view of a directory is universal, and can be given to all users.  NSS volumes, however, can give different views of a directory to different users.  The result is that users accessing an NFS mount of an NSS NFS export can see the "wrong" directory contents.  For example, to build on the examples above:  If user1 gets a directory listing of /home,  he will see the existence of subdirectory /home/user1.  Then, if that information is still in the NFS client cache, and user2 asks for a directory list of /home, he will see the existence of /home/user1 (which he did not expect to see) and will NOT see the existence of /home/user2 (which he DOES expect to see).

 

This is a very unexpected situation for the users, but is actually relatively cosmetic.  User2 will still not be able to access /home/user1 because he has not been granted trustee rights there.  And he (user2) will still be able to access /home/user2 (if he asks for it by name), even though it did not appear to be in the directory list.  This can definitely frustrate users, but access will still be enforced properly.

 

Automated processes will typically not be bothered by this issue, since automated processes typically don't retrieve / evaluate directory listings.  They usually just know exactly what path names and file names they are looking for.

 

If it is desired to avoid situations where various users get the "wrong" directory lists shown to them, then all the users would need to have the same view of the directory.  There are various ways to accomplish this.

 

One very simple method is to configure the NFS export to treat all users as one particular eDir user.  This could be accomplished by the NFS export settings "all_squash,anonuid=xxx" where "xxxx" is replace with the UID of a LUM-enabled eDir user, who has at least Filescan trustee rights to the volume in question.  (More trustee rights are typically needed for any useful access, but this would be a minimum.)

 

If you don't want to treat all NFS users as one eDir user, then another option is to use careful rights planning to accomplish this.  For example, if you give all users "Filescan" to the /home directory, then they would all see the full directory list contents, and no one would get the "wrong" partial directory list.  However, since Novell trustee rights are inherited down the directory structure, this right would carry down into all subdirectories, which may not be desired.  In that case, inherited rights filters can be created to protect subdirectories.  While this is possible, it requires careful planning and diligence.

 

Another option would be to create an traditional Linux file system like xfs, ext3, or reiserfs, and share it both via NFS and NCP.  This would eliminate this design concern between NFS and NSS, and allow NFS access and NCP access to functional separately, according to their own traditional rules.

  

 

This is believed to only effect OES 2:  Some NFS processes may create a file which initially has no permissions set on it.  Then they attempt to write to the file and set more "appropriate" permissions.  Normal Linux file systems shared through NFS allow this to happen (even in cases where they wouldn't allow it from a typical local shell).  This was also allowed in NetWare.  However, an NSS file system shared through the Linux NFS Server does not allow this.

 

 

Cross Protocol File Locking is not fully supported.  In some cases, files opened or locked by one protocol (NCP, NFS, CIFS, etc) may be correctly blocked for simultaneous usage by other protocol, but it is not always guaranteed.  It is also conceivable that files no longer in use by one protocol may still appear to be in use or locked when accessed through another protocol.  Some file sharing / locking scenarios will have the same results they had with NFS on NetWare, but not necessarily all.