Chapter 17
Setting Up the Network File System
Certification Objectives
*From the Classroom *
Security Considerations for File System Design
*The network file system can store critical data and applications on a server so they can be shared by many users. The careful design of the network file system is one of your most important network administrator tasks. If the network file system is not designed with the needs of the organization in mind, it will cause problems in the future.
In the first section of this chapter, we discuss planning a file system. The second section examines the system-created directories and the third section offers possible directory structures. Finally, in sections four and five, we discuss creating additional volumes and designing directory structure, respectively.
Introduction to Planning
Before you plan a network file system, you must understand how the NetWare file system is organized. A NetWare network file system is made up of volumes, folders (or directories), and files. NetWare uses a hierarchical tree structure, similar to MS-DOS and Windows 95, where a volume is the parent of a folder and a folder is the parent of files. Volumes are comprised of logical partitions of one or many disks. Each volume will have a top-level folder, the root folder, containing all other folders and files. Folders are created within volumes; and files, containing applications and data, are created within folders. Figure 17-1 shows the relationship between volumes, folders, and files. We use the terms directories and folders interchangeably throughout this chapter.
Figure 1: The NetWare network file system showing the relation among volumes, folders, and files
In Figure 17-1, the NetWare NWADMIN program is used to visually depict the relationship between a volume, folders, and files. In this example, the name of the volume is FIVE-NW5_SYS. It contains several directories, Accounting and General Ledger. These directories contain other subdirectories and files. When viewed from NWADMIN, the volume has a file cabinet icon.
A volume exists on a NetWare server; it does not exist on a NetWare client. Actually, if you view a server volume from a Windows 95 client, it will have a folder icon. Think of a volume as one level higher than a normal folder in the Windows 95 tree structure.
Exam Watch: Remember that a volume contains a directory and the directory contains the application and data files.
During installation of a server, a default volume, called SYS:, is created. It contains NetWare system directories that hold NetWare Loadable Modules (files with an extension of *.NLM), Local Area Network (*.LAN) drivers, and other system files. Other volumes may be created at installation and also with the NWCONFIG.NLM once the server is installed.
Now, that we have reviewed the background of a NetWare network file system, let’s look at planning the network file system. The needs of the organization determine how the network file system is organized. In planning your network file system, keep the following points in mind:
In terms of volume location, one approach is to keep the default volume, SYS:, free of application files and data files. Create a separate volume for your application and data files. This will prevent data files, which grow quite large, from causing space problems on the SYS: volume and vice versa. Separating system and user space will also ease security administration. So, locate your application folders and data files on a volume other than the SYS: volume. You may even want to place the application data on another disk entirely.
Concerning volume storage requirements, if you are using Macintosh clients, additional support for storing Mac long filenames will need to be added. Mac filename support (MAC.NAM) takes up additional storage on the volume. UNIX clients also require additional long filename space support. Thus, you will need to account for additional disk overhead when storing Macintosh or UNIX filenames on a given volume.
The configuration of your volume requires careful planning. When discussing volume configuration, we need to explore fault tolerance. Fault tolerance describes the safeguards a system has when it encounters a hardware failure or software problem that prevents proper data access. Many mission-critical applications cannot afford to be down and must be up 99.9% of the time. Their system needs to be highly fault tolerant. There are various ways to implement fault tolerance.
Another important aspect of volume configuration is performance. Volume placement may be determined by disk read and disk write access times. If you place your most important applications on a fast bus, such as a SCSI bus, then reads and writes will improve.
One of the methods NetWare provides for fault tolerance is disk mirroring. Disk mirroring is when two disks, located on the same disk controller and of equal partition sizes, are an exact copy of each other. For example, if you have two disk partitions of 500 megabytes each, they can be mirrored. Your total storage is not 1,000 megabytes (or 1 gigabyte) but merely 500 megabytes. The reason for this reduction is the duplicate copy. NetWare allows the volumes to be mirrored during install time or at a later time.
Exam Watch: When mirroring two disk partitions, they must be of equal size.
Another fault tolerant technique NetWare provides is disk duplexing. This is a slight variation disk mirroring. Disk duplexing uses disk mirroring with two disk controller cards instead of one. Remember, disk mirroring uses one disk controller card and the disk controller card is connected to the bus in a server PC.
If fault tolerance is important to your organization, then place an additional drive in the server and mirror the two disks. Remember, with mirroring, you lose the capacity of one of the disks because it is an exact duplicate of the other. Mirroring also impacts performance with disk writing because the operating system must write twice. However, disk reads may be enhanced because data can be read from multiple disks. Mirroring is called for when your system must be up a high percentage of the time, say 95% or higher. If one of the disks goes bad, then you would break the mirror, install another disk, format and remirror it with the good disk. While this substitution is going on, your users will still be able to operate. If you had not implemented disk mirroring and your disk became bad, then your users would be unable to use the server resources until the corrupted disk was replaced. This could take hours even if a tape backup existed. Mirroring would have alleviated this problem.
If performance is importance to your organization, then you could spread a volume over many disks, thereby increasing the disk read time. Concurrent disk reads will occur, which speeds up access to your server. You will not incur the disk write performance impact that you would with disk mirroring; however, if your system went down, there would be no immediate online recovery. Your users would not be able to operate their applications. This approach—called spanning—is called for if speed is your goal at the risk of losing the redundancy provided by mirroring.
If fault tolerance and performance are equally important to your organization, mirroring is possible but you should implement disk duplexing. By placing an additional disk controller in the server, your network file system will receive the benefit of faster disk accesses with the added benefit of duplicating your application and data. The disk writes would still take a performance hit but not as big a hit as disk mirroring where a single disk controller card is used. Also, the disk reads would experience even better performance than under disk mirroring because there are the two disk controllers. Using the two disk controllers provides for concurrent disk reads.
Finally, with respect to configuration, review the needs of your organization up front. Then, choose your method to implement. Overall, disk duplexing offers the advantages of fault tolerance and performance but the disadvantage is the cost of the additional hardware. Mirroring offers redundancy at a lower cost because there is a single disk controller.
The importance of volume maintenance is an often overlooked, but critical, task. Monitor the available space on your volumes periodically. Actually, if a volume gets low on disk space, the operating system will warn you; however, take a look at it routinely. This could cause critical applications and files to not be written to disk. You can review volume sizes from a client computer. If space becomes critically low on a given volume, the free space on a disk can be used to expand that volume. You can look at volumes with the NWADMIN software program. For a view of volume statistics, see Figure 17-2. Notice that the amount of disk space used for the volume, FIVE-NW5_SYS, is about 84%. You will also need to watch for the number of directory entries becoming too large. You may have space on the disk available, but if the number of your directory entries is too high, you cannot create any new directories. In this case, you will need to increase the SET parameter, Maximum Percent of Volume Used By Directory, at the file server console. You can type in the following command at the server prompt:
FIVE-NW5: SET MAXIMUM PERCENT OF VOLUME USED BY DIRECTORY = 85
This parameter can be set from a low value of 5 to a high value of 85.
Another consideration is the block suballocation parameter. This allows greater use of disk space because files can be stored in smaller unused portions of the disk. Suballocation allocates smaller block sizes than under previous versions of NetWare, which in turn reduces overall fragmentation. There is some slight server memory overhead.
Figure 2: Viewing a volume’s statistics with NWADMIN
In terms of volume maintenance, the amount of space available to a user on a volume can be restricted with the NWADMIN utility. Figure 17-3 illustrates the restriction of user space on a volume. One reason to limit user space is to keep user files from growing so large that they cause critical application data to not be written to disk.
Keep an eye on the size of the error log files created by Transaction Tracking System (TTS) and the volume repair process (VREPAIR.NLM). These files are stored on the SYS: volume and grow over time. Compression is turned on for a volume by default. Compression will store the data more efficiently on disk but your server will incur more processor overhead.
Exam Watch: The error log files created by TTS and VREPAIR are SYS:\TTS$LOG.ERR and VOL$LOG.ERR.
Figure 3:
Restricting user space on a volume with NWADMINAnother technique used for volume maintenance is the VREPAIR program. This is analogous to SCANDISK for DOS and Windows computers. VREPAIR will detect and repair volume problems such as File Allocation Table (FAT) inconsistencies and mirror problems. In order to run VREPAIR, the volume must be dismounted. In order to dismount a volume, APPS, and then run VREPAIR on that volume, issue the following commands at the server prompt:
FIVE-NW5_SYS: DISMOUNT VOLUME-NAME
FIVE-NW5_SYS: LOAD
VREPAIR
When VREPAIR loads, it will prompt you to repair a volume.
Exam Watch: In order to repair a volume with VREPAIR, the volume must be dismounted.
System-Created Directories
Now, that we have investigated planning the network file system, let’s take a look at the system-created directories. Remember, during a NetWare server installation, the SYS: volume is created. On that volume, NetWare will create several default system directories to store its necessary programs and files. The system-created directories of a NetWare 5.0 server are shown in Figure 17-4. In this example, the server, FIVE-NW5 contains the volume, SYS.
Exam Watch: A volume name is typically represented as servername_volumename:. For example, for a server named FIVE-NW5 and a volume of SYS, the volume name is FIVE-NW5_SYS:.
Figure 4: System-created directories seen with a Windows 95 client
Table 17-1 describes the more important system-created directories.
System-Created Directory |
Description |
SYSTEM | Holds administrator NLMs. |
Exists for backwared compatibility with bindery-based services. | |
PUBLIC | Holds user command and NWADMIN. |
LOGIN | Contains login commands. |
ETC | Holds TCP/IP programs and files. |
JAVA and JAVASAVE | Contains Java Console commands. |
QUEUES | Has subdirectories with a *.QDR extension; each representing a NetWare Print Queue object. |
CDROM$$.ROM | Index files for mounted CD-ROM volumes. |
DELETED.SAV | Has deleted files removed from directories. |
LICENSE | Contains license-related files. |
NDPS | Holds Novell Distributed Printing Service subdirectories and files. |
NETBASIC | Contains NetBASIC support files. |
NI | Has NetWare installation files. |
PERL | Holds PERL script files. |
README | Has Readme text files. |
Table 1: System-Created Directories
Exam Watch: An easy way to remember the important system-created directories is with the acronym SiMPLE. This stands for: SYSTEM, MAIL, PUBLIC, LOGIN, and ETC.
The SYS: directory contains NLMs used by the ADMIN user. Various LAN drivers and other NLMs are in this directory. Also, the NDS database is stored here. The MAIL directory holds users’ mail if you are using NetWare MAIL software. The PUBLIC directory contains the NetWare Administrator program, NWADMIN, and other Windows-based administrator tools. Another important tool here is NDS Manager for managing the NDS partition and replicas and NAL (NetWare Application Launcher). NPTWIN95 is an executable program also located in the SYS: directory. NPTWIN95 allows a printer to be attached to a NetWare client. It must be run at the NetWare client that has a shared printer attached to it. The LOGIN directory holds a few commands, such as LOGIN, MAP, and CX, that give the user at a workstation access to basic network tools prior to actually logging in and being authenticated by a NetWare server. The ETC directory contains TCP/IP and DNS related files. For example, this is where the HOSTS file is located.
Now that we have reviewed the system-created directories, let’s take a look at possible directory structures.
Possible Directory Structures
In considering possible directory structures, take a look at you users’ needs.
It is suggested that you consider the following types of directories when organizing a directory structure:
Typically, users need to have home directories so they can store their data files. It is wise to create a home directory off either the SYS: volume or a separate volume. Each user should have a parent directory created under the home directory. This will ease administering network security since you can isolate users to their own home directory.
Users need to have full access to their own home directories so they can add, delete, modify, file scan, and copy their own files. Users typically do not need access to other users’ home directories. For a view of how users’ data could be created, refer to Figure 17-5. In this example, the users have directories created in a home directory and are stored on the SYS: volume.
Security Considerations for File System Design
When designing the file system structure for a NetWare server, don’t forget to include file system security as one of your major considerations. Allowing users to store and access files at a volume’s root directory can lead to exponentially compounding security problems and administrative headaches. A more prudent strategy is to leave the SYS: volume alone and to create another volume for placing additional directories for applications, user home directories, print queues, and other directories for data that quickly fill up the unused disk space. Be careful not to put directories that users will access, directly at the volume’s root, but instead, create placeholder directories that will hold subdirectories. Later, when you grant file system trustee rights, you will have a file system structure that takes advantage of rights inheritance without excessive rights too high in the file system structure and will eliminate the need for most IRFs.
— Dan Cheung, CNI, MCNE, MCT
When the users log in, as long as a home directory is created, the files they create and edit for an application can be stored in their own home directory. You could implement a security scheme where one user could not even change directories to the parent directory, HOME, thus preventing them from even "seeing" another user’s files. You would implement this with the MAP ROOT command. In Figure 17-5, if set up properly, user Jess could not see user Zac’s files nor store data in Zac’s home directory.
Figure 5: Possible directory structures created on the SYS: volume
The following statement shows how a MAP ROOT would be set to create an artificial root ceiling (virtual root) for the user JOE. If the user named JOE logs in and attempts to change to the real root directory, the artificial ceiling will prevent him from doing so. His root directory is \USERS\JOE on SERVER5 and volume SYS: instead of \.
MAP ROOT H:=SERVER5_SYS:\USERS\JOE
Also in this example, you can see how it is possible to separate the APPLICATIONS directory from the HOME directory. In the APPLICATIONS directory, you could place word processing, spreadsheet, and database programs and configuration files. The users could have read and file scan access to these directories. This would enable them to execute the appropriate application in one directory and store the necessary data in their own secured home directory. From a security standpoint, you would not want to give the users write, erase, or modify access to the APPLICATIONS directory. You don’t want your users deleting the applications used by themselves and others; so, read and file scan should suffice.
Let’s say that multiple users need to access a single data file. That data file can be put in a shared directory and the users could be given access to that shared directory. This type of situation could happen, for example, in a payroll application where payroll clerks need to access the same file. Instead of placing this shared file in just one of the users’ home directories, the file should be placed in the DATA SHARED directory, as seen in Figure 17-5. If a file that needs to be shared is placed in a single user’s home directory, other users would need access to that directory. However, the disadvantage is that since other users can now see the shared file, they can also see files that may not relate to the application, which could cause a security breach. So, if a file needs to be shared, place it in a common directory. Assign appropriate rights to that directory and place the users in a group that has access to that directory.
Finally, if the workstations need a particular version of DOS, a directory for each version could be placed in the PUBLIC directory. Then, when the user logs in, a login script would map to this directory to get the correct version of DOS.
Creating Additional Volumes
Volumes, including SYS:, may be created at server installation time, or they may be created later. In order to create additional volumes or add disk space to a current volume segment, you must use the LOAD NWCONFIG module at the file server console. For example at the console prompt for a server called FIVE-NW5:
FIVE-NW5: NWCONFIG
Next, select Standard Disk Options, NetWare Volume Options and you will see the current volumes listed. Table 17-2 shows a list of options and keys used.
Option |
Button Name |
Function |
Save | ESC or F10 | Save changes to a volume. |
Delete | DEL | Delete a volume. |
Mount/Dismount an existing volume | <ENTER> | Mount or dismount a volume. |
Modify Volume Parameters | <ENTER> | Change parameters. |
Help | <F1> | Get help on creating or changing a volume. |
Ins | <F3> | Add volume segments. |
Table 17-2: Commands to Modify Volumes
You can create a new volume or you can increase the size of a volume. For both processes, you must have free space available on the disk. In order to add a volume, you must create a NetWare disk partition on it. In NWCONFIG, choose Standard Disk Options and then Modify disk partitions and Hot Fix. Next, choose the disk device where you want the NetWare partition to be placed. Then, choose Create NetWare disk partition and choose a size of the partition, from Free Space, that you want your partition to be. The default is the entire partition. You will also need to decide on a Hot Fix amount. The default Hot Fix size is probably best and is automatically determined by your NetWare partition size. Hot Fix is a fault tolerance technique where the data is written to a special reserved area of the disk, the Hot Fix, if other sectors go bad. Data will be written to the Hot Fix, or redirection, area only if an area of the disk is corrupt.
Once a NetWare partition has been created, you can get back to the main NWCONFIG menu and then select Standard Disk Options, and NetWare Volume Options. You will see listed the volumes that are currently available. To add a new volume segment, press INSert or F3, and the Volume Disk Segment List will appear. This shows the NetWare partitions that were created earlier. You can add or modify a volume segment only from available free space.
Press Enter on the volume disk segment to choose either to make the segment a new volume or make this segment part of another volume.
If you choose to make the segment a new volume, you must provide a new volume name. The following naming requirements apply to a new volume name:
Once the name has been entered, the volume size must be entered.
The range of valid sizes is from 1 to the partition size. If the partition size is 350 MB, then valid numbers are from 1 to 350 MB. If you don’t choose all of the volume, then the difference is left as free space. You can then use this free space to place another volume. However, you can have up to 32 volume segments for each NetWare partition. After a volume has been created, there will be a column on the Volume Disk Segment List screen that shows a status of "N" indicating a new volume that is still in RAM. You must press F10 to save this to the disk. A summary of the status codes follows:
After pressing F10 to save the volume, you must enter the administrator password to confirm. You must enter the distinguished NDS name for the ADMIN user. For example, if ADMIN is located in the NW5 organization unit, then for the Administrator Name prompt, you must enter: .admin.nw5 followed by the correct password. A message will appear indicating that the volume was installed. Then you need to mount the volume.
A volume must be mounted before it can be used. The SYS: volume automatically gets mounted as the server boots up. Application volumes have to be mounted manually at the file server console in NWCONFIG or they can get mounted by placing an entry in the AUTOEXEC.NCF file for the server. To mount a volume named APPS the entry would be the following:
FIVE-NW5_SYS: MOUNT APPS
You can modify or view volume information, as shown in Table 17-3.
Volume Information |
Contents |
Volume Name | Volume Name (Example: SYS) |
Volume Block Size | Block Size (default of 64 KB Blocks) |
Status | Mounted or Dismounted |
File Compression | ON or OFF |
Block Suballocation | ON or OFF |
Data Migration | ON or OFF |
Table 17-3: Volume Information
Finally, you cannot dismount a volume while it is in use. File compression and block suballocation cannot be changed from here. Data migration is the process of moving data from the server hard disk to a secondary storage device such as tape or an optical disk. This optimizes hard disk utilization and is transparent to the users.
Designing Directory Structures
Before designing directory structure you will need to get an idea of your organization’s needs and then do some careful planning.
Here are some things to consider when designing directory structures:
By placing multiple applications on multiple volumes you are in fact spreading the application across multiple disks. This would enhance overall speed of the applications since concurrent disk reads and writes could occur.
If you place your applications on one volume and your data files on another, you also enhance system performance. Because applications are typically read-intensive and data is typically write-intensive, you will split the reads and writes, which will in turn improve throughput. One volume is for reading only; the other is for writing only.
You also receive the same benefit by placing shared data files on volumes separate from non-shared volumes. You are splitting up the disk writes across multiple disks on multiple volumes. Refer to Figure 17-6 for a possible directory structure design.
Figure 6: Possible directory structure design
In Figure 17-6, you can see that the applications have been placed on different volumes. There is a volume for ENGINEERING, PRODUCTIVITY (which could contain generic office-related software), and APPS (which has organization-specific software).
Certification Summary
As we have mentioned several times in this chapter, it is best to plan your directory structure up front. This may entail performing user needs analysis to fully understand what is needed. Many organizations have problems down the road, when this initial analysis is not done.
Make sure you consider whether your organization has performance or fault tolerance as its objective. In NetWare, you have several fault tolerant techniques: server mirroring, disk duplexing, disk mirroring, and the hot fix redirection process. If fault tolerance is your objective, then mirroring is adequate. However, if performance is your objective, then mirroring is not the best choice. If both are necessary, implement disk duplexing.
Be mindful of the system-created directories. They contain many programs that are used by NetWare. It is best not to place your critical applications on the SYS: volume.
In creating additional volumes, you can create a volume segment only on a NetWare partition. You can either create a new volume or extend a current volume. A partition can have up to 32 volume segments. A volume can be created only from available free space. Use the utility NWCONFIG at the file server console to create additional volume segments.
Two-Minute Drill