Sharing Files Between NT and UNIX Systems

Learn how NT NTFS products translate file and directory permissions between NTFS and UNIX's NFS

Windows NT systems are moving into environments where UNIX platforms havetraditionally reigned. Companies that add NT networks to their legacy UNIXinstallations usually need to share files between the two platforms. Because NTand UNIX use different file systems--NTFS for NT and NFS for UNIX--file sharingbetween NT and UNIX systems usually requires running a product on the NT systemthat converts NTFS-format files to NFS. In this article, I explain NFS and NTFSfile and directory access permissions and how NFS file sharing works via NT NFSproducts. (The sidebar, "File Name Mapping," page 68, warns about theeffect of naming conventions.)

NFS Permissions
NFS, which Sun Microsystems originally developed, provides a file-sharingstandard that lets users on UNIX workstations access centralized files on a UNIXserver or share files with other UNIX workstations. All major UNIX operatingsystems have built-in NFS file-sharing capabilities.

For file and directory permissions, NFS uses a simple scheme that'ssomewhat limiting compared to NTFS permissions. For example, in NTFS, each fileand directory has at least one access control list (ACL) entry that defines auser's or group's access to the file or directory. With liberal use of ACLentries, you can tailor access to one file for your entire user community, asScreen 1 shows. UNIX administrators don't have this level of control. Ratherthan offer a full set of ACLs that let you individually specify user and grouppermissions, UNIX's NFS provides three broad categories of access permissions:user, group, and other (or world) accesspermissions (this approach is different from NTFS, in which files have only oneowner). UNIX systems also store an owner and group identifier (i.e., an entry)for each file or directory in the file system. These identifiers work with thethree access permissions to determine a user's level of access.

User permissions, in the form of a numeric owner identifiers (or userIDs--UIDs), define access for a file's owner. When a user saves a file in NFS,the UNIX system automatically saves the UID in the file's directory entry,similar to a directory entry for a file under the NTFS or FAT file system.Later, if another user with the same UID attempts to access the file, that userreceives the owner's access permissions for the file.

Group permissions, also in the form of a numeric group identifier, defineaccess for all users who belong to a group. As with the owner identifier, when auser saves a file, UNIX automatically saves the user's current group ID (GID) asthe group identifier in the file's directory entry. When another user with thesame group identifier attempts to access the file, the user receives the group'spermissions.

Note that group permissions are subordinate to owner permissions. Forexample, if you are both a file's owner and a member of the group the filebelongs to, the owner permissions take precedence.

The third category of access permissions is other, or world, permissions.They define access for everyone who isn't either a file owner or a member of agroup with access to a file.

Read, Write, and Execute
Each permissions type has three access flags, read (r), write(w), and execute (x). You can set or unset a flag to control access tofiles.

The read flag lets you view the contents of any file or directory in a UNIXfile system. The write flag lets you update files. Update operations includeediting, deleting, or renaming a file. UNIX does not differentiate among thesefunctions--the write access flag grants all update privileges.

Ordinarily, anyone with write access to a file also has read access.However, it's possible to grant a user write access but not read access. Thiscapability lets a user delete and rename a file and removes a user's ability toedit a file. Why? Because if you don't have read access, you can't read the fileinto an editor to edit it.

The final access flag, execute, determines whether you can execute a file.Usually, this flag is set on executable programs only; it lets administratorscontrol who can and cannot execute programs.

Listing 1 contains a sample UNIX directory listing showing how filepermissions are set. In this example, the first column represents the filepermissions, the third column holds the owner's name (most people know theirlogon name rather than their UID), the fourth column represents the group name(again, rather than the numeric value), and the remaining three columns show thefile size, creation date and time, and file name.

The first column, file permissions, contains one directory indicator (thefirst indicator) and slots for nine different permission flags. When you createa subdirectory, UNIX places a "d" in the first slot. This letter letsyou know the entry is for a subdirectory. The remaining nine slots represent theread, write, and execute flags for the owner, group, and other (world)permissions, respectively.

In Listing 1, file deg.doc contains read and write permissions in thesecond and third slots. These flags grant read and write permissions for thefile's owner, which is the user with logon ID mpd. File msg.txt containssimilar owner file permissions and also includes read permissions for both thegroup (staff) and the rest of the world. Finally, the file glsystem is anexecutable program that the owner, group, and other (world) can execute, asindicated by the execute permission.

UNIX also has the equivalent of NTFS's No Access and Full Controlpermissions. You simulate No Access by merely not granting any permissions tothe owner, group, or other (world) category. (Of course, systems administratorswith super user--SU--access can still access any file, regardless of the file'spermissions.) The absence of permissions for certain users means that thoseusers have no access to the file or directory that has no permissions defined.You can simulate NTFS's Full Control by granting all three permissions--read,write, and execute. However, unlike with NTFS's Full Control, if you grant fullcontrol to nonowners (group and other) under UNIX, they do not have the abilityto modify permissions--only a systems administrator or owner can modify a file'saccess permissions.

Permission Mapping
Although NT and UNIX file permissions are relatively simple, the process bywhich NFS software maps file and directory access permissions between NTFS andNFS can be more complex than choreographing a Broadway musical. Fortunately,this process is transparent to users. The three NT NFS products I'veused--Hummingbird Communications's NFS Maestro, NetManage's ChameleonNFS/X, andXLink Technologies's Omni-NFS For Windows NT--handle permission mapping the sameway.

An NT system can play one of two roles in an NFS environment. The NT systemcan act as an NFS client, accessing remote NFSs (UNIX) as if they were localNTFSs. Or, an NT system can act as an NFS server, letting UNIX systems accessNTFSs. Usually, the permission mappings are the same regardless of the accessdirection, especially if you use one vendor's product to perform both client andserver functions (which is how NFS products are generally sold).

When you access a file, either from a UNIX machine to an NFS server runningon NT or from an NT NFS client to a UNIX machine, the NFS software must performthe permission-mapping process. In the first part of this process, authentication,the NFS software attempts to determine the user's identity. When a user accessesa remote UNIX file system from NT, the NFS subsystem determines the UID and GIDon the UNIX system with the user's NT username and primary group identifier.When a user accesses an NTFS from a UNIX system (through an NFS server on an NTsystem), the NFS server maps the user's UNIX UID and GID to an NT logon name andgroup name.

When an NT user accesses a UNIX file system via NFS, the authenticationprocess may use a special daemon (PCNFSD) on the UNIX host that attempts totranslate the NT logon ID to a UNIX counterpart. If the daemon can't translatethe logon ID, the NFS product uses a UID/GID translation table instead toautomatically perform the translation (most NT NFS products maintain such atable; you usually have to set it up before using the NFS product). When a UNIXuser accesses a file on an NT system, the NFS server product uses the UID/GIDtable, if the server product has one, to handle the translation. In either case,if no translation is available, the NFS software either assigns an ID or endsthe connection attempt. Screen 2 shows how permissions are mapped to a UNIXsystem via NFS.

Determining the proper UID and GID or NT username and group combination isan important part of file permission mapping. Because UNIX does not maintainextensive ACLs for each file, proper mapping of the UID and GID to their NTcounterparts is critical to ensure that users can access the files they need.For example, if your GID is not set correctly, NFS might assign you differentaccess permissions from the group access permissions you require.

When a UNIX user creates a file on an NTFS via an NFS server, the NFSproduct often uses NTFS's Special Access permission flags rather than thestandard NTFS file permissions to determine individual access levels. Theseflags more readily map to their UNIX counterparts because they include read,write, and execute flags (and some others), thus allowing a one-to-onetranslation. For example, if the read flag is set for a file on the UNIX system,the NT NFS software usually sets the NTFS Special Access read flag. When a newfile is created on the NT system, the NFS software usually creates an ACL forthe file that uses Special Access flags to set the file's permission for theowner, group, or other (world). NFS can affect two other Special Access flags,depending on the NFS product you use. Because UNIX's write permission impliesthat you have delete permission, the presence of this flag in a UNIX file canset the Delete Special Access flag. Also, because a file's owner can changeaccess permissions, some NFS products set the Change Permissions Special Accessflag for the owner.

User and Group Mapping
The three types of UNIX access permissions (user, group, and other) directlymap to three ACL entries for the file on the NTFS. An ACL entry for the ownercontains the user permissions, an entry for the group NFS determines the filebelongs to contains the group permissions, and finally the group Everyonereceives other permissions. The read, write, and execute special file permissionflags are set appropriately for each ACL.

Mapping users and groups is especially tricky when you access files in anNTFS from a UNIX system via an NFS server. The complexity arises from NTFS'sability to maintain many ACL entries for individual users and groups. In somecases, there may be several individual user ACL entries and no group ACLentries. In other cases, a file owner may not have an individual ACL entry. Or,there may be several group entries but no individual or owner entry. Generally,in such cases the NFS server product relies heavily on the UID/GID translationtable to properly determine the correct access permissions for a file.

How these access permissions take effect for UNIX users depends on the NFSserver product. For example, take a situation often found in a user's homedirectory on an NTFS. The user creates a new directory for FrontPage 97. Theuser, who is the file's owner, may use File Manager to modify NTFS securitypermissions for the directory and the files in it. As part of the ACLs the userspecifies, the user may grant high access to several other users or to severalgroups.

Mapping these permissions for a UNIX user who wants to access the directoryrequires the NT server to perform a large amount of logic. The server attemptsto translate the UNIX user's UID/GID combination into an NT counterpart and thendetermines the individual's access by examining the ACL entries for the filesand directories the user is trying to access. Once the NFS software finds thecorrect ACL entry to use, the NFS server grants the appropriate access. If nomatch is found, the user cannot access the directory and files.

Establishing file permissions between NTFS and UNIX over NFS is hardly anexact science. Various vendors implement their client and server translationschemes differently. When choosing an NT NFS product, you need to understand howthe product performs permission mapping. Two important issues are the product'suse of special file and directory permissions in place of NTFS's defaultpermissions and the methods the NFS product uses to perform UID and GID mappingbetween NT users and groups and their UNIX counterparts. When you fullyunderstand these issues, sharing files with NFS becomes second nature.

Corrections to this Article: