7.4 NFS Server
Network File System (NFS) Server enables UNIX users to access a NetWare file system as if it were a part of local file system on the UNIX workstation. Any client that supports the NFS protocol can access NetWare files using the NFS Server.
NOTE:Hard links and special files such as device files, named pipes, socket files are not supported in this release of NetWare NFS Server.
This section uses the UNIX operating system as the example when referring to the remote NFS client. The following figure shows an example of the NFS Server file sharing process.
Figure 7-1 NFS Server Functionality
NOTE:In this illustration, vol = NSS Volume on NetWare Server and memos = Directory inside vol, the NSS volume.
7.4.1 Making NetWare File System Available to NFS Clients
Before UNIX users can access the NetWare file system, make it available to the UNIX workstations. This process is called exporting the file system. When exporting, you can define who should access the exported paths and how it is accessed by specifying the trusted systems and their level of access.
For example, you can restrict the access to specific UNIX hosts, and export the directory as Read-only.
7.4.2 Accessing the NetWare File System from UNIX NFS Clients
After exporting the NetWare file system from a NetWare server, mount the exported file system on the UNIX workstation for normal access. Mounting a NetWare file system from a UNIX workstation consists of the following:
-
Creating a mount point
A mount point is an empty directory that you create. This directory becomes the access point for the NetWare file system. When you select an existing directory as a mount point, the contents of the existing directory are not accessible until you unmount the remote file system.
-
Mounting the NetWare directory
Most UNIX systems use the mount command to mount a remote file system.
After these steps are complete, UNIX users can access the NetWare file system by accessing the local mount point. Different UNIX systems can use slightly varying options or user interfaces to mount a remote file system.
7.4.3 File Access Modes
The file access modes of Native File Access for UNIX enable you to maintain file and directory access security and help in mapping the trustee rights and attributes of NetWare to the UNIX file permissions.
Native File Access for UNIX provides the following file access modes:
In this section, the term mapped user refers to the eDirectory user with UNIX profile (UNIX UID / GID).
The term unmapped user refers to the eDirectory user without UNIX profile (UNIX UID / GID).
Independent Mode
This mode offers independent access control between NetWare rights and UNIX permissions without any interdependency between the two. No access mapping is required, and no mapping is done between UNIX file permissions and NetWare trustee rights or file attributes. The only mapping done is for the ownership of the file. The NetWare file owner becomes the UNIX file owner, and vice versa.
Independent mode is the default mode in which a path is exported.
Independent Mode Functionality
This mode functions as follows:
-
NetWare trustees are not assigned.
-
No mapping of RWX permissions to NetWare SRWCEMFA rights (Supervisor, Read, Write, Create, Erase, Modify, File scan, Access control) and vice versa is done.
-
No NetWare attribute mapping is done.
-
IRM is set to the default (SRWCEMFA).
-
The NetWare OwnerID is mapped to the UNIX user on the NFS side.
-
UNIX UID, GID, and UNIX permissions do not affect NetWare rights or attributes in any way.
The functions of this mode are outlined in the following table:
The following table outlines the mapped and unmapped user behavior of the file created from NetWare or UNIX.
NetWare Mode
NetWare mode puts NetWare in control of UNIX permissions. Users who want greater control of file permissions on the NetWare side rather than NFS side must select the NetWare mode of access control.
The NetWare mode controls the rights of the files/directories when they are on the NetWare side and determines the user's rights to create or modify files on NetWare in a particular path.
This mode controls access to the exported NFS directory using NetWare access control methods such as NetWare rights and attributes. When using this mode, NFS permissions do not modify the settings of the NetWare rights and attributes.
To get the necessary UNIX permissions, make sure the user has necessary effective rights on the NetWare side.
World Object Behaviour
During the NetWare 6.5 install, the NFAUWorld group object is created by default and is located in the Server context. For NFS paths exported in NetWare mode, the effective rights of this object on the filesystem is used to compute and set the rwx permission for Others on UNIX side.
If the container where this object gets created has RWCEF NetWare rights to the file system, then by virtue of inheritance, NFAUWorld object also has those effective rights. This translates to rwx for Others on the UNIX side. This can be dangerous if not done intentionally because any user on UNIX side can wipe out the sub-directory structure.
If Others on the UNIX side are inheriting too many rights from containers above, use one of the following methods to restrict these:
-
Remove file system rights from the containers above (parent container, grandparent, etc.) to prevent NFAUWorld from inheriting certain rights.
-
Move the NFAUWorld object to another container which does not have those rights. However, when moving to another container, note that for NFS to find the NFAUWorld object, it has to be somewhere under a container listed as a SEARCH_ROOT context in sys:etc\nfs.cfg.
-
Delete the NFAUWorld object, so Others will not get any permissions.
Export Option for NetWare Mode
The -nwmode option indicates if a particular path is exported in NetWare mode or not. If this is not specified, it is treated as an Independent mode export. If -nwmode is specified, the path is treated as being exported in NetWare mode.
For example:
/data -nwmode -rw -root
This exports the /data path in NetWare mode with read/write and root access.
NetWare Mode Functionality
This mode functions as follows:
-
Trustees are not assigned and attributes are not mapped. [r-w-x] is not mapped to [SRWCEMFA].
-
By default, IRM is set to SRWCEMFA.
-
The default permissions for files created by UNIX users are based on the effective rights of the mapped NetWare user account.
-
NetWare ownership of a file is determined by the mappings between eDirectory user object and its UNIX profile. The OwnerID (NetWare files) is mapped to the UNIX owner of the file.
-
Files created from NetWare end by unmapped users have the UID set to 0.
-
Touch command functionality is normal. In addition, it initiates a recomputation of permissions or owner change as required.
-
Executing a chmod command reflects changes on the UNIX side only when the x (execute permission) for file is involved.
The chmod commands allows setUID, setGID, and sticky bits to be set for a file or a directory and to be retained persistently between NetWare owner changes or permission recomputations.
-
The chmod, chown, and chgrp commands have no effect on the NetWare rights and attributes of the file and they fail silently.
The functions of this mode are outlined in the following table:
Rights Mapping
The following table outlines the rights mapping for files, directories, and folders.
HINT:You can set x, the NFS execute permission for a file, using the chmod command from the NFS client because there is no direct mapped attribute or effective right for an execute permission.
-
The write permission is masked when the file/directory is read-only or the NetWare attribute is on.
-
Read-only also sets the Rename Inhibit (RI) and the Delete Inhibit (DI) for the file and DI only for directory.
-
Read-only files cannot be renamed or removed from NFS clients.
-
Read-only folders cannot be deleted from NFS clients.
IMPORTANT:To ensure that Others in UNIX receive sufficient permissions see World Object Behaviour.
Refresh of Permissions
A refresh or recompute of the access permissions is done only in the following scenarios:
-
When the UNIX or NetWare side detects a change of NetWare owner of a file or directory, the new owner's UnixUID is used and updated. The UnixGID and group permissions do not change.
At times, the refresh of permissions because of the change in NetWare owner, trustees, or trustee permissions on the NFS Client might take some time as clients display the cached information. Updated information is available only when the client contacts the server for updated attributes and permissions.
-
To enforce an immediate update of attributes, specify any one of the following commands, as required:
touch *
touch filename|directory_name
touch.
When you execute the touch command, the client receives the updated attributes from the NetWare NFS Server. This recomputes the permissions.
In addition to the touch command, commands such as chown, chgrp, and chmod also initiate a recomputation of permissions even though the command itself might not be successful.
For example, if the World Object has no permissions for a specific directory, you can give the Others Object r and x directory permissions by assigning Read and File Scan rights to the World Object.
The following table outlines the mapped and unmapped user behavior of the file created from NetWare or UNIX.
General Behavior Applicable to NetWare and Independent Modes
The following behavior is applicable to both NetWare and Independent modes:
-
If the RI bit is set, rename fails.
-
If the DI bit is set, remove fails.
-
The execute (x) permission by itself is not enough for execution. The read (r) permission is also required.
-
Symlinks have lrwxrwxrwx permissions. Operations such as chmod / setuid work on the linked file rather than on the symlink itself.
7.4.4 NFS Server File Lock Manager
When users share files, the system must provide a mechanism that prevents different users from making simultaneous changes to the same file. If there is not such a mechanism, two users can open one file at the same time. When this occurs, one user can overwrite the changes another user makes to the file, causing inconsistencies.
Both NetWare and UNIX systems control simultaneous file access using file locking. File locking ensures that a file is updated correctly before another user, application, or process can access it.
NetWare NFS Lock Manager file locking functions by setting advisory locks between NFS clients and is similar to the standard File Locking semantics on UNIX clients.
File locks are provided only when an application contacts the NetWare NFS lock manager. If an NFS user or process attempts to access a file through an application that does not contact the lock manager, no lock is issued. For example, if a UNIX user accesses a NetWare file using the vi editor, which does not contact the lock manager, no file lock is issued. If another UNIX user attempts to simultaneously access the same file, access is permitted and inconsistencies can occur.
However, this advisory nature of file locking is only between the NFS clients. The NetWare NFS Server synchronizes file locking by using both the NetWare and NFS lock managers. For cross-protocol file locking (simultaneous access using CIFS, or AFP), mandatory locking is enforced.
When a UNIX user accesses a NetWare file from an application that contacts the lock manager, the lock manager checks for existing file locks. If the NFS lock manager finds no existing locks on the file, it sets a lock on the file and file access is granted to the UNIX user. When a UNIX user attempts to access a file from an application that does not contact the lock manager, the request is sent directly to the NetWare server. If the NetWare lock manager finds no existing locks on the file, access is granted, but no lock is issued. Therefore, another UNIX user could access the file.
Byte-Range Locking
Two types of byte-range lock are used:
-
Exclusive Lock: The locked byte range is read/write for the holder of the lock and deny-all for all others.
A write lock on a byte range is acquired by an application that intends to write data into that byte range, and does not want other applications to be able to read or write to the byte range while it is accessing that byte range. A write lock on a given byte range is exclusive. It is grantable to only one requester at a time.
A write lock denies other applications the ability to either read or write to the locked byte-range.
-
Shared Lock: Also called an non-exclusive byte-range lock. The locked byte range is read-only for the holder of the lock and deny-write for all others.
A read lock on a byte range is normally acquired by an application that intends to read data from the byte range, and does not want other applications to be able to write to the byte range while it is performing the read operation. A read lock on a given byte range is sharable, which means it is grantable to multiple requesters concurrently. However, it is incompatible with a concurrent write lock on the same byte range. A read lock denies other applications the ability to write to the locked byte range. In environments that implement advisory record locking rather than mandatory record locking, a read lock simply "advises" other applications that they should not write to the locked byte-range, even though they are technically able to do so.