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:

Operation

NetWare Clients

NFS Clients

NetWare Side

Attributes

  • DI

  • RI

  • RO

  • The DOS user cannot delete the file/directory.

  • The DOS user cannot rename the file.

  • The DOS user cannot write to the file.

The NFS user cannot delete file/directory.

The NFS user cannot rename the file.

The NFS user can write to the file.

NFS Side

Creation

  • OwnerID - The NetWare user is mapped to the NFS user creating the file.

  • IRM is the default SRWCEMFA.

  • No trustees are created for User/Group/Other.

  • No attributes are set according to UNIX permissions.

  • UID/GID is set to whatever the file was created with.

  • File permission is set based on UNIX Umask.

  • chown

  • chgrp

  • chmod

  • OwnerID does not change.

  • No change in the group trustee.

  • No change in attributes, IRM, or trustee rights.

  • The UID is changed.

  • The GID is changed.

  • File mode is set based on permissions specified in the chmod command.

The following table outlines the mapped and unmapped user behavior of the file created from NetWare or UNIX.

Mapped User Behavior

Unmapped User Behavior

File or directory is created from NetWare

  • The NetWare FileOwner is set as the file creator.

  • The UNIX UID is mapped to the NetWare FileOwner's UNIX UID.

  • The UNIX GID is mapped to the NetWare FileOwner's primary group UNIX GID.

  • File/directory permissions are set according to the umask specified. The default umask value is 022, which means:

    The file's permissions are rw-r--r--

    The directory's permissions are rwxr-xr-x

The UNIX UID and GID are identified and set. If this fails, then the UID is set to 0 and the GID is set to1.

File or directory is created from UNIX

  • The file's permissions are set according to the UNIX umask setting.

  • The NetWare FileOwner is set to the mapped UNIX user.

The UNIX UID and primary GID of UNIX user is set as the UID/GID of the file.

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:

Operations

NetWare Clients

NFS Clients

NFS Side

Creation

  • The Owner ID is mapped to the NetWare user.

  • IRM is set to the default (srwcemfa).

  • No trustees are created.

  • No attributes are set based on FMode.

  • GID is inherited from the parent directory

  • The UID is set to Root. The UNIX user is mapped to Admin.

  • The GID is set to whatever the file was created with.

  • File mode is set.

Modification

  • chown

  • chgrp

  • chmod

  • No owner ID or trustee change.

  • No change in the group trustee.

  • No attribute change.

  • No trustee change.

  • No IRM change.

  • A UID change is not allowed.

  • A GID change is not allowed.

  • An FMode change is effective only for x.

Rights Mapping

The following table outlines the rights mapping for files, directories, and folders.

File / Directory

NetWare Right

Mapped UNIX Permission

File

Read

NFS Read (-r)

File

Write

NFS Write (-w)

Directory

Read and File Scan

NFS Read (-r) and Execute (-x)

Directory

Create and Erase set

NFS Write (-w)

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.

Mapped User Behavior

Unmapped User Behavior

File or directory is created from NetWare

  • When the file or directory created from the NetWare side is accessed for the first time from UNIX, the UNIX UID, UNIX GID, and permissions are determined and set.

  • From the NetWare owner, the UnixUID and UnixGID of that user are picked up. This provides the NetWare group matching the UnixGID.

  • Using the NetWare User, Group, and World objects, the r-w-x permissions for the User, Group, and Others are determined.

  • When the file or directory created from the NetWare side is accessed for the first time from UNIX, the root-mapped user profile is set to the file/directory.

  • The effective rights of the unmapped user along with World object determine the r-w-x permissions for User, Group, and Others.

File or directory is created from UNIX

  • The UnixUID and UnixGID are used to find the matching mapped NetWare User and Group objects.

  • Based on the effective rights of the mapped NetWare owner, mapped NetWare Group and World Group objects on the file or directory, the equivalent UNIX permissions are determined.

  • Using this rights mapping, the read-write-execute (r-w-x) permissions for User, Group, and Others are determined.

  • The effective rights and r-w-x permissions of User, Group and Others are based on the UnixUID and UnixGID of the root mapped User along with the World Group object.Therefore, the owner of the file/directory is set to root.

  • The unmapped user gets permission to create files if World has rights to create a file/directory in that path.

    This removes the need to treat an unmapped user separately, and it is treated just as another user belonging to the Others category.

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.