Softpanorama

May the source be with you, but remember the KISS principle ;-)
Contents Bulletin Scripting in shell and Perl Network troubleshooting History Humor

Linux NFS

News NFS Recommended Links Reference NFS version 3 Design and Operation nfs4
NFS in RHEL Suse NFS service        
Mounting NFS directory owned by root NFS Security NFS performance tuning RHEL NTP configuration Troubleshooting NTP on Red Hat Linux  
Troubleshooting NFS logging RPC History Humor Etc

In an enterprise computing environment, it is common to share files between computers or allow several users to access the same set of files on a central server and have all changes be visible to all users immediately. In a pure UNIX environment, including those consisting solely of Red Hat Enterprise Linux systems, this can be achieved via Network File System (NFS). If sharing files between Red Hat Enterprise Linux and Microsoft Windows systems is desired, Samba can be used to achieve connectivity.

 

NFS does not have its own log file. Instead, the commands used by NFS such as rpc.mountd to mount client requests are logged in the system log file /var/log/messages. Kernel messages from nfsd are also logged to this file.

NFS and SELinux

In Red Hat Enterprise Linux 5, NFS is protected by the default Security-Enhanced Linux (SELinux) policy, known as the targeted policy.  By default, this targeted policy allows NFS connections to the server by setting the nfs_export_all_ro and nfs_export_all_rw SELinux booleans to 1.

If you are sharing home directories over NFS while using SELinux, you must set use_nfs_home_dirs boolean to 1 on each client connecting to the NFS server sharing the home directories. Execute the following command as root:

setsebool -P use_nfs_home_dirs boolean 1

To verify that the setting has been changed, execute the following:

getsebool use_nfs_home_dirs boolean

If enabled, the output should be the following:

use_nfs_home_dirs --> on

You can also change this setting by running the SELinux Management Tool. Start it by selecting Administration, SELinux Management from the System menu on the top panel of the desktop or by executing the system-config-selinux command. Enter the root password when prompted if running as a non-root user. Select Boolean from the list on the left. On the right, click the triangle icon next to NFS. The SELinux booleans affecting NFS appear. Click the check box next to Support NFS home directories. The change takes place immediately.

Tip

The SELinux booleans that affect NFS are described in the nfs_selinux man page viewable with the man nfs_selinux command.

The SELinux implementation in Red Hat Enterprise Linux does not require the files shared with NFS to be labeled with a specific security context. However, if more than one file-sharing protocol is configured to share the same set of files such as FTP and Samba, the security context of the files must be set to public_content_t or public_content_rw_t instead. Additional SELinux booleans must be enabled as well. Refer to the "Security Context for Multiple File-Sharing Protocols" section in Chapter 23 for complete instructions.

Allowing NFS Connections

Before configuring the NFS server, configure your firewall settings to allow the incoming connections. While portmapper and the nfs daemon use static ports, NFS also employs four additional services: statd, mountd, rquotad, and lockd. They are assigned a random port by portmapper, which makes it difficult for firewall configuration. However, it is possible to configure these four daemons to use static ports. Refer to the "Assigning Static NFS Ports" section later in this chapter for details.

The portmapper service uses UDP and TCP port 111, and the nfs daemon uses UDP and TCP port 2049 by default. If custom IPTables rules are being used, refer to Chapter 24, "Configuring a Firewall," for details on how to allow these ports.

If the default security level is enabled instead of custom IPTables rules, use the Security Level Configuration tool to allow NFS connections. Start it by selecting Administration, Security Level and Firewall from the System menu on the top panel of the desktop or by executing the system-config-securitylevel command. Enter the root password when prompted if running as a user. In the Other ports area, click Add to specify each NFS port. Remember, the ports will differ depending on which ones you choose.

Tip

To retrieve a list of clients connected to the NFS server, use the showmount command from a shell prompt. To also show the directories the clients are connected to, use the showmount -a command.

Using a Graphical Tool to Configure the NFS Server

To use a system as an NFS server, the nfs-utils RPM package must be installed. If it is not installed, install it with Red Hat Network as described in Chapter 3, "Operating System Updates." To configure it via the NFS Server Configuration graphical tool, the system-config-nfs RPM package must also be installed. If you prefer to edit the configuration file directly, skip to the later section "Configuring the NFS Server on the Command Line."

To start the tool, select Administration, Server Settings, NFS from the System menu on the top panel of the desktop. Alternatively, execute the command system-config-nfs from a shell prompt.

Root privileges are required to modify the NFS server settings, so you must have root access to use this tool. If you are not root when you start the program, you will be prompted for the root password.

All currently configured shares are shown each time the program is started as shown in Figure 13.1.

Note

This graphical interface interacts with the /etc/exports file directly. Any changes made directly to the configuration file after the graphical tool is used will appear in the graphical tool the next time it is used.

Adding a New NFS Share

To add a new share, click the Add button in the toolbar. The Add dialog window appears .

Note

This graphical interface interacts with the /etc/exports file directly. Any changes made directly to the configuration file after the graphical tool is used will appear in the graphical tool the next time it is used.

On the Basic tab, specify a directory to share, configure the allowed clients, and select whether the clients should be allowed read-only or read-write access.

The IP address range for the allowed clients must be in one of the following formats:

Note

As the NFS server options are discussed, the corresponding option in the /etc/exports configuration file is provided in brackets such as [option].

 NFS Options configurable via GUI interface:

The User Access tab contains the following options:

Click OK to add the share to the list. After clicking OK, the settings are automatically saved to the /etc/exports file and the daemon is automatically reloaded so the new share is available. The old configuration file is written to /etc/exports.bak.

Editing and Deleting NFS Shares

To modify an existing share, select it from the list and click the Properties button in the toolbar. The existing settings for the share are shown and can be modified. After you click OK, the changes take place immediately.

To delete a share, select it from the list and click Delete. The shared directory is removed from the list. Once again, the change takes place immediately.

Configuring the NFS Server on the Command Line

To configure a Red Hat Enterprise Linux system as an NFS server via the command line, make sure the nfs-utils RPM package is installed.

The server configuration file, /etc/exports, uses the following format:

shared_directory allowed_hosts(options)

where shared_directory is the name of the directory to be shared, allowed_hosts is the IP address range of the allowed clients, and options is a list of NFS options for the exported directory. Obviously, the exported directory must exist. Refer to the previous section on graphical configuration for valid IP address range configuration. You must be root to modify this file.

For example, the following /etc/exports line allows all systems with 192.168.1.* IP addresses read-write access to the /shared/ directory:

/shared 192.168.1.0/255.255.255.0(sync,rw)

Caution

Notice that allowed_hosts and (options) do not have a space between them. If a space is included, the options are applied to any and all IP addresses, which can be quite dangerous if write permission is granted.

The sync or async option must be specified as an NFS option. If sync is specified, the server waits until the request is written to disk before responding to the client. The sync option is recommended because it follows the NFS protocol.

To grant read-write access for the exported directory, use the rw option. For additional options, refer to the previous section on graphical configuration. For a full list of NFS server options, refer to the exports man page with the command man exports. Options should be separated by commas.

Starting and Stopping the NFS Server

The root user must execute the commands to start, stop, and reload the NFS server. To start the NFS server, execute the command service nfs start. To stop the server, execute the command service nfs stop. If the server is already started and the /etc/exports configuration file is altered, the NFS server must be informed. Use the command service nfs reload to force the server to reread the configuration file.

To have the service start automatically at boot time, use chkconfig as the root user:

chkconfig nfs on

To verify that the NFS server is running, issue the command service nfs status.

Assigning Static NFS Ports

Refer to /etc/services for a list of ports already reserved for other services on the system and then select ports over 1024 to assign to the statd, mountd, rquotad, and lockd services. In this example, the following ports will be used:

The NFS initialization scripts check for the configuration file /etc/sysconfig/nfs for static port assignments. If the file is not found, random ports are used for statd, mountd, rquotad, and lockd. To assign static ports, create the file /etc/sysconfig/nfs with the lines from Listing 13.1. Replace the port numbers with the ones you decided to use after examining /etc/services.

Listing 13.1. Assigning Static Ports for NFS
STATD_PORT=38001
LOCKD_TCPPORT=38005
LOCKD_UDPPORT=38006
MOUNTD_PORT=38003

 

If you are using disk quota as discussed in Chapter 7, "Managing Storage," you also need to assign a static port to rquotad, the daemon used to determine quotas for a remotely mounted NFS filesystem. In addition to the lines in Listing 13.1, also add the following line to /etc/sysconfig/nfs:

RQUOTAD_PORT=38004

Use the command rpcinfo -p localhost to verify that the port numbers for the portmapper, status, rquotad, nlockmgr, and mountd services are correct. Because lockd is a kernel module, a reboot might be needed for the changes to take effect.

Static ports can also be assigned with the graphical NFS configuration tool. After starting the tool, click the Server Settings button on the toolbar.  Provide the ports you want to use, and click OK.

Connecting to the NFS Shares

There are three ways to mount an NFS export on a client system, assuming the server has given the client permission to do so:

Using mount to Connect to the NFS Share

If you only need to mount the share occasionally (or if you are testing the export), use the mount command. Create a directory to mount the share, then, as root, execute the following command:

mount -o <options> server.example.com:/exporteddir /mountpoint

replacing the server name, exported directory, and the local mount point. By default, the share is mounted in read-write mode, meaning that all file permissions are retained from the server. It is important to know that the file permissions are based on the user ID and group ID numbers, not the user and group names used on the NFS server. If the client is allowed access by the server, the shared directory will then be available from the specified mount point on the client.

Any NFS mount options can also be used in place of <options> including the following:

The rsize value is the number of bytes used when reading from the server. The wsize value is the number of bytes used when writing to the server. The default for both is 1024, but using 8192 greatly improves throughput and is recommended. The timeo value is the amount of time, in tenths of a second, to wait before resending a transmission after an RPC timeout. After the first timeout, the timeout value is doubled for each retry for a maximum of 60 seconds or until a major timeout occurs. If connecting to a slow server or over a busy network, better performance can be achieved by increasing this timeout value. The intr option allows signals to interrupt the file operation if a major timeout occurs for a hard-mounted share. Refer to the NFS man page with the command man nfs for a full list of available options.

Using /etc/fstab to Connect to the NFS Share

After you have verified that the client can mount the share, you can configure the system to mount it at boot time by modifying the /etc/fstab file as follows:

Code View: Scroll / Show All
server:/exported/dir   /mountpoint   nfs    rsize=8192,wsize=8192,timeo=14,intr

					  

Replace the server name, exported directory, and mount point with the appropriate values. The third column indicates that the mount point is of the type nfs.

The last column contains a comma-separated list of NFS options. The options in our example were explained in the previous section, "Using mount to Connect to the NFS Share."

After the entry is added to /etc/fstab, use the command mount /mountpoint as root to mount the share immediately. Unless the noauto option is specified, it is automatically mounted at boot time.

Tip

The user option can also be used to allow a non-root user to mount the share with the mount /mountpoint command. This is useful if the noauto option is used to not mount the share at boot time.

Using autofs to Connect to the NFS Share

The last option is to use autofs. The autofs service works by using the automount daemon to monitor preconfigured NFS mount points. They are only mounted when a user attempts to access the local mount point directory.

There are several advantages to using autofs instead of configuring shares in /etc/fstab. Because shares are only mounted when they are accessed, system boot time is faster. The system doesn't have to wait for each NFS server to respond and the mount to succeed. Secondly, it is more secure. Users on the client systems must know what directory is configured to mount the share before changing into that directory to force the mount. On the other hand, if all shares are mounted on bootup, users can browse the contents of the shared directory if they have permission. If the system is compromised by an unauthorized user, having the shares pre-mounted makes it that much easier for the intruder to find the shared files. Finally, if the clients are configured to use NIS for user authentication, NIS can also be configured to provide the /etc/auto.* files necessary for autofs. So, when a share needs to be added, modified, or removed, the administrator just needs to update the configuration files on the NIS server, and they are populated to all clients after the NIS service is restarted on the clients. The update is almost seamless to the end user.

The master configuration file is /etc/auto.master, Listing 13.2 shows the default auto.master file.

#
# $Id: auto.master,v 1.4 2005/01/04 14:36:54 raven Exp $
#
# Sample auto.master file
# This is an automounter map and it has the following format
# key [ -mount-options-separated-by-comma ] location
# For details of the format look at autofs(5).
#
/misc      /etc/auto.misc
/net       -hosts
#
# Include central master map if it can be found using
# nsswitch sources.
#
# Note that if there are entries for /net or /misc (as
# above) in the included master map any keys that are the
# same will not be seen as the first read key seen takes
# precedence.
#
+auto.master

 

As you can see, the mounts for the /misc/ directory are defined in a different file. One additional configuration file per directory is controlled by autofs. The /misc/ directory in Red Hat Enterprise Linux is reserved for autofs mounts. Because /etc/auto.misc is already created, add NFS mounts to it in the following format:

mountdir  <options>   server.example.com:/exporteddir

Replace mountdir with the name of the /misc/ subdirectory you want the share to be mounted. For example, to use the directory /misc/data/, replace mountdir with data. This subdirectory is dynamically created when the share is mounted. Do not create it on the local filesystem.

Replace <options> with a list of comma-separated NFS options discussed previously in this chapter and found in the NFS man page (accessed with the man nfs command). Replace the server name and exported directory as well.

If a directory is used by autofs as a mount point, the directory should not be written to unless the remote filesystem is mounted in that directory. Consider it a reserved directory for autofs.

To start the automount daemon, use the command service autofs start. To stop it, use the command service autofs stop. If the service is already running when the auto.master file or any of the files it includes such as auto.misc is modified, use the command service autofs reload to force a reread of the configuration files. To configure the system to start it at boot time, execute chkconfig autofs on as the root user.


Top Visited
Switchboard
Latest
Past week
Past month

NEWS CONTENTS

Old News ;-)

[Oct 03, 2010] Setting Up An NFS Server And Client On CentOS 5.5

HowtoForge

server:

On the NFS server we run:

yum install nfs-utils nfs-utils-lib

Then we create the system startup links for the NFS server and start it:

chkconfig --levels 235 nfs on
/etc/init.d/nfs start

client:

On the client we can install NFS as follows (this is actually the same as on the server):

yum install nfs-utils nfs-utils-lib

3 Exporting Directories On The Server

server:

I'd like to make the directories /home and /var/nfs accessible to the client; therefore we must "export" them on the server.

When a client accesses an NFS share, this normally happens as the user nobody. Usually the /home directory isn't owned by nobody (and I don't recommend to change its ownership to nobody!), and because we want to read and write on /home, we tell NFS that accesses should be made as root (if our /home share was read-only, this wouldn't be necessary). The /var/nfs directory doesn't exist, so we can create it and change its ownership; in my tests the user and group nobody both had the ID 99 on both my CentOS test systems (server and client); when I tried to write to /var/nfs from the NFS client, I got a Permission denied error, so I did a chmod 777 /var/nfs so that everyone could write to that directory; writing to /var/nfs from the client worked then, and on the client the files written to /var/nfs appeared to be owned by the user and group nobody, but on the server they were owned by the (nonexistant) user and group with the ID 65534; so I changed ownership of /var/nfs to the user/group 65534 on the server and changed permissions of /var/nfs back to 755, and voilà, the client was allowed to write to /var/nfs:

Recommended Links



Etc

FAIR USE NOTICE This site contains copyrighted material the use of which has not always been specifically authorized by the copyright owner. We are making such material available in our efforts to advance understanding of environmental, political, human rights, economic, democracy, scientific, and social justice issues, etc. We believe this constitutes a 'fair use' of any such copyrighted material as provided for in section 107 of the US Copyright Law. In accordance with Title 17 U.S.C. Section 107, the material on this site is distributed without profit exclusivly for research and educational purposes.   If you wish to use copyrighted material from this site for purposes of your own that go beyond 'fair use', you must obtain permission from the copyright owner. 

ABUSE: IPs or network segments from which we detect a stream of probes might be blocked for no less then 90 days. Multiple types of probes increase this period.  

Society

Groupthink : Two Party System as Polyarchy : Corruption of Regulators : Bureaucracies : Understanding Micromanagers and Control Freaks : Toxic Managers :   Harvard Mafia : Diplomatic Communication : Surviving a Bad Performance Review : Insufficient Retirement Funds as Immanent Problem of Neoliberal Regime : PseudoScience : Who Rules America : Neoliberalism  : The Iron Law of Oligarchy : Libertarian Philosophy

Quotes

War and Peace : Skeptical Finance : John Kenneth Galbraith :Talleyrand : Oscar Wilde : Otto Von Bismarck : Keynes : George Carlin : Skeptics : Propaganda  : SE quotes : Language Design and Programming Quotes : Random IT-related quotesSomerset Maugham : Marcus Aurelius : Kurt Vonnegut : Eric Hoffer : Winston Churchill : Napoleon Bonaparte : Ambrose BierceBernard Shaw : Mark Twain Quotes

Bulletin:

Vol 25, No.12 (December, 2013) Rational Fools vs. Efficient Crooks The efficient markets hypothesis : Political Skeptic Bulletin, 2013 : Unemployment Bulletin, 2010 :  Vol 23, No.10 (October, 2011) An observation about corporate security departments : Slightly Skeptical Euromaydan Chronicles, June 2014 : Greenspan legacy bulletin, 2008 : Vol 25, No.10 (October, 2013) Cryptolocker Trojan (Win32/Crilock.A) : Vol 25, No.08 (August, 2013) Cloud providers as intelligence collection hubs : Financial Humor Bulletin, 2010 : Inequality Bulletin, 2009 : Financial Humor Bulletin, 2008 : Copyleft Problems Bulletin, 2004 : Financial Humor Bulletin, 2011 : Energy Bulletin, 2010 : Malware Protection Bulletin, 2010 : Vol 26, No.1 (January, 2013) Object-Oriented Cult : Political Skeptic Bulletin, 2011 : Vol 23, No.11 (November, 2011) Softpanorama classification of sysadmin horror stories : Vol 25, No.05 (May, 2013) Corporate bullshit as a communication method  : Vol 25, No.06 (June, 2013) A Note on the Relationship of Brooks Law and Conway Law

History:

Fifty glorious years (1950-2000): the triumph of the US computer engineering : Donald Knuth : TAoCP and its Influence of Computer Science : Richard Stallman : Linus Torvalds  : Larry Wall  : John K. Ousterhout : CTSS : Multix OS Unix History : Unix shell history : VI editor : History of pipes concept : Solaris : MS DOSProgramming Languages History : PL/1 : Simula 67 : C : History of GCC developmentScripting Languages : Perl history   : OS History : Mail : DNS : SSH : CPU Instruction Sets : SPARC systems 1987-2006 : Norton Commander : Norton Utilities : Norton Ghost : Frontpage history : Malware Defense History : GNU Screen : OSS early history

Classic books:

The Peter Principle : Parkinson Law : 1984 : The Mythical Man-MonthHow to Solve It by George Polya : The Art of Computer Programming : The Elements of Programming Style : The Unix Hater’s Handbook : The Jargon file : The True Believer : Programming Pearls : The Good Soldier Svejk : The Power Elite

Most popular humor pages:

Manifest of the Softpanorama IT Slacker Society : Ten Commandments of the IT Slackers Society : Computer Humor Collection : BSD Logo Story : The Cuckoo's Egg : IT Slang : C++ Humor : ARE YOU A BBS ADDICT? : The Perl Purity Test : Object oriented programmers of all nations : Financial Humor : Financial Humor Bulletin, 2008 : Financial Humor Bulletin, 2010 : The Most Comprehensive Collection of Editor-related Humor : Programming Language Humor : Goldman Sachs related humor : Greenspan humor : C Humor : Scripting Humor : Real Programmers Humor : Web Humor : GPL-related Humor : OFM Humor : Politically Incorrect Humor : IDS Humor : "Linux Sucks" Humor : Russian Musical Humor : Best Russian Programmer Humor : Microsoft plans to buy Catholic Church : Richard Stallman Related Humor : Admin Humor : Perl-related Humor : Linus Torvalds Related humor : PseudoScience Related Humor : Networking Humor : Shell Humor : Financial Humor Bulletin, 2011 : Financial Humor Bulletin, 2012 : Financial Humor Bulletin, 2013 : Java Humor : Software Engineering Humor : Sun Solaris Related Humor : Education Humor : IBM Humor : Assembler-related Humor : VIM Humor : Computer Viruses Humor : Bright tomorrow is rescheduled to a day after tomorrow : Classic Computer Humor

The Last but not Least


Copyright © 1996-2016 by Dr. Nikolai Bezroukov. www.softpanorama.org was created as a service to the UN Sustainable Development Networking Programme (SDNP) in the author free time. This document is an industrial compilation designed and created exclusively for educational use and is distributed under the Softpanorama Content License.

The site uses AdSense so you need to be aware of Google privacy policy. You you do not want to be tracked by Google please disable Javascript for this site. This site is perfectly usable without Javascript.

Original materials copyright belong to respective owners. Quotes are made for educational purposes only in compliance with the fair use doctrine.

FAIR USE NOTICE This site contains copyrighted material the use of which has not always been specifically authorized by the copyright owner. We are making such material available to advance understanding of computer science, IT technology, economic, scientific, and social issues. We believe this constitutes a 'fair use' of any such copyrighted material as provided by section 107 of the US Copyright Law according to which such material can be distributed without profit exclusively for research and educational purposes.

This is a Spartan WHYFF (We Help You For Free) site written by people for whom English is not a native language. Grammar and spelling errors should be expected. The site contain some broken links as it develops like a living tree...

You can use PayPal to make a contribution, supporting development of this site and speed up access. In case softpanorama.org is down you can use the at softpanorama.info

Disclaimer:

The statements, views and opinions presented on this web page are those of the author (or referenced source) and are not endorsed by, nor do they necessarily reflect, the opinions of the author present and former employers, SDNP or any other organization the author may be associated with. We do not warrant the correctness of the information provided or its fitness for any purpose.

Last modified: October 20, 2014