Welcome to Linux Knowledge Base and Tutorial
"The place where you learn linux"
Karen Lilly Creations

 Create an AccountHome | Submit News | Your Account  

Tutorial Menu
Linux Tutorial Home
Table of Contents
Up to --> Networking

· The Flow of Things
· When Things Go Wrong
· Automount

Man Pages
Linux Topics
Test Your Knowledge

Site Menu
Site Map
Copyright Info
Terms of Use
Privacy Info
Masthead / Impressum
Your Account

Private Messages

News Archive
Submit News
User Articles
Web Links


The Web

Who's Online
There are currently, 195 guest(s) and 0 member(s) that are online.

You are an Anonymous user. You can register for free by clicking here

Linux Tutorial - Networking - NFS
  DHCP ---- The Flow of Things  


The Network File System (NFS) is an industry standard means of being able to share entire filesystems among machines within a computer network. As with the other aspects of networking, the machines providing the service (in this case the filesystem) are the servers and the machines utilizing the service are the clients. Files residing physically on the server appear as if they are local to the client. This enables file sharing without the hassle of copying the files and worrying about which one is the more current.

One difference that NFS filesystem have over "conventional" filesystem is that it is possible to allow access to a portion of a filesystem, rather than the entire one.

The term exporting is used to describe how NFS makes local directories available to remote systems. These directories are then said to be exported. Therefore, an exported directory is a directory that has been made available for remote access. Sometimes the term importing is referred to the process of remotely mounting filesystems, although mounting is more commonly used.

There are a couple of ways you can mount a remote filesystem. The first is automatically mounting it when the system boots up. This is done by adding an entry into /etc/fstab. You could also add a line in some rc script that does a mount command.

If the remote mount is a one-time deal, the system administrator can also mount it by hand. Potentially, the administrator could create and entry in /etc/fstab that does not mount the filesystem at boot time, but rather is mounted later on. In either event, the system administrator would use the mount command. If necessary, the system administrator can also allow users to mount remote filesystems.

A client machine can also be configured to mount remote filesystem on an "as-needed" basis, rather than whenever the system boots up. This is through the mechanism of the automount program. We'll get into a lot of details about how automount works later on.

The syntax for using the mount command to mount remote file system is basically the same as for local filesystems. The difference being that you specify the remote host along with the exported path. For example, if I want to mount the man-pages from jmohr, I could do it like this:

mount -t nfs [-o options] jmohr:/usr/man /usr/man

Here I told the mount command that I was mounting a filesystem of type NFS and that the filesystem was on the machine jmohr under the name /usr/man. I then told it to mount it onto the local /usr/man directory. There are a couple of things to note here. First, I don't have to mount the filesystem on the same place as it is exported from. I could have just as easily exported it to /usr/doc or /usr/local/man. If I want I can include other options like "normal filesystems" such as read only.

If you are a server, the primary configuration file is /etc/exports, which is a simple ASCII file and additions or changes can be made with any text editor. This is a list of the directories that the server is making available for mounting along with who can mount them and what permissions they have. In addition, the server needs a way to find the clients address, therefore mounting will fail if the name cannot be resolved either by DNS or /etc/hosts. Likewise, the clients depends on name resolution to access the server.

The /etc/exports file has one line for each directory you want to export. The left side is the path of the directory you want to export and the right side is options you want to apply. For example, you can limit access to the directory to just one machine or make the directory read only. On junior, the exports might look like this:

/pub *
/ jmohr(rw)
/usr/jmohr_root jmohr(rw)

The first line says that I am exporting the /pub directory to the entire world. Since there are no options, this means that the filesystem is also writable. I wouldn't normally do this if I were connected to the Internet, even if there wasn't anything sensitive here. It is a matter of practice, that I know exactly what access I am giving to the world.

The next line says that I am exporting the entire root filesystem to the machine jmohr. Since this is a development environment, I have different versions and distributions of Linux on different machines. I often need to have access to the different files to compare and contrast them. Here, the filesystem is also writable as I explicitely said rw (for read-write).

The last line takes a little explaining. When I mount the root filesystem from jmohr, I mount it onto /usr/jmohr_root, which is the name of the directory that I am exporting here. This demonstrate the fact that you can export a filesystem to one machine and then have it re-exported.

Keep in mind, however, that we cannot increase the permission during the re-export. That is, if the filesystem were originally made read-only, we could not make it writable when I re-export it. However, if it were writable, I could export it as read-only.

Image - An example NFS mount (interactive)

A solution that many systems provide is amd, which is an automatic mounting facility for NFS filesystems. Once configured, any command or program that accesses a file or directory on the remote machine within the exported directory forces the mounting to occur. The exported directory remains mounted until it is no longer needed.

If you can access a filesystem under Linux, you can access it under NFS. (including DOS filesystems) This is because the access to the file is a multi-step process. When you first access a file (say opening a text file to edit it). The local system first determines that this is an NFS mounted filesystem. NFS on the local system then goes NFS on the remote system to get the file. On the remote system, NFS tries to read the file that is physically on the disk. It is at this point that it needs to go through the filesystem drivers. Therefore, if the filesystem is supported on the remote system, NFS should have no problem accessing it. Once a filesystem has been exported, the client sees the filesystem as an NFS filesystem and therefore what type it is, is really irrelevant.

There are a couple of limitations with NFS. First, although you might be able to see the device nodes on a remote machine, you cannot access the remote devices. Think back to the discussion on the kernel. The device node is a file that is opened by a device driver to gain access to the physical device. It has a major and minor number that point to and pass flags to the device driver. If you open up a device node on a remote system, the major and minor numbers for that device node point to drivers in the local kernel.

Remotely mounted filesystems present a unique set of problems when dealing with user access rights. Because it can have adverse effects on your system, it is necessary to have both user and group ID unique across the entire network. If you don't, access to files and directories can be limited, or you may end up giving someone access to a file that shouldn't. Although you could create each user on every system, or copy the passwd files, the most effect method is using NIS.

 Previous Page
  Back to Top
Table of Contents
Next Page 
The Flow of Things


Test Your Knowledge

User Comments:

You can only add comments if you are logged in.

Copyright 2002-2009 by James Mohr. Licensed under modified GNU Free Documentation License (Portions of this material originally published by Prentice Hall, Pearson Education, Inc). See here for details. All rights reserved.



Security Code
Security Code
Type Security Code

Don't have an account yet? You can create one. As a registered user you have some advantages like theme manager, comments configuration and post comments with your name.

Help if you can!

Amazon Wish List

Did You Know?
The Linux Tutorial welcomes your suggestions and ideas.


Tell a Friend About Us

Bookmark and Share

Web site powered by PHP-Nuke

Is this information useful? At the very least you can help by spreading the word to your favorite newsgroups, mailing lists and forums.
All logos and trademarks in this site are property of their respective owner. The comments are property of their posters. Articles are the property of their respective owners. Unless otherwise stated in the body of the article, article content (C) 1994-2013 by James Mohr. All rights reserved. The stylized page/paper, as well as the terms "The Linux Tutorial", "The Linux Server Tutorial", "The Linux Knowledge Base and Tutorial" and "The place where you learn Linux" are service marks of James Mohr. All rights reserved.
The Linux Knowledge Base and Tutorial may contain links to sites on the Internet, which are owned and operated by third parties. The Linux Tutorial is not responsible for the content of any such third-party site. By viewing/utilizing this web site, you have agreed to our disclaimer, terms of use and privacy policy. Use of automated download software ("harvesters") such as wget, httrack, etc. causes the site to quickly exceed its bandwidth limitation and are therefore expressly prohibited. For more details on this, take a look here

PHP-Nuke Copyright © 2004 by Francisco Burzi. This is free software, and you may redistribute it under the GPL. PHP-Nuke comes with absolutely no warranty, for details, see the license.
Page Generation: 0.39 Seconds