|Home||Switchboard||Unix Administration||Red Hat||TCP/IP Networks||Neoliberalism||Toxic Managers|
|May the source be with you, but remember the KISS principle ;-)|
|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|
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.
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.
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.
The SELinux booleans that affect NFS are described in the nfs_selinux man page viewable with the man nfs_selinux command.
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.
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.
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.
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.
To add a new share, click the Add button in the toolbar. The Add dialog window appears .
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:
Specific IP address or hostname: Provide the IP address, the fully qualified domain name (FQDN), or hostname of the allowed client. If the FQDN or hostname is used, the server must be able to resolve it to an IP address.
FQDNs specified by wildcards: Use the * or ? special character to list a set of FQDNs such as *.example.com. Dots are not included in the wildcard. (Note: Wildcards can not be used with IP addresses.)
IP networks: Specify an IP network with its network netmask or the number of bits in the netmask such as 192.168.1.0/255.255.255.0 or 192.168.1.0/24.
Netgroups: Specify an NIS netgroup such as @example_group_name.
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:
Allow connections from port 1024 and higher: By default, the NFS server requires root privileges to start, stop, or modify. If this option is selected, a user other than root can start the server. [insecure]
Allow insecure file locking: Lock requests are not required. [insecure_locks]
Disable subtree checking: By default, NFS performs a subtree check, meaning that if a subdirectory is shared, but the entire filesystem isn't, the server verifies that the requested file is in the exported tree. When subtree checking is enabled, it also makes sure files inside directories with root-only access can only be accessed when exported with the no_root_squash option, which is not a default option. This option disables subtree checking. [no_subtree_check]
Sync write operations on request: Wait until operation is written to disk before responding to client. Enabled by default because it is part of the NFS protocol and a required option. [sync]
Force sync of write operations immediately: By default, write operations are delayed slightly if the server might receive another related write request or if one is already in progress. The writes are performed in one operation, which might improve performance. When this option is enabled, the server does not delay when writing to disk. This option can not be used if the async option is enabled. [no_wdelay]
Hide filesystems beneath: If a subdirectory of a directory already exported is also configured as a mount point, by default, the subdirectory is accessible without having to specifically mount it. If this option is enabled, the subdirectory must be mounted separately from the parent directory. If it is not, the subdirectory will appear empty to NFS clients. [hide if checked, no_hide if unchecked]
Export only if mounted: Export a directory only if it has been successfully mounted on the NFS server. This option prevents an empty directory from being exported should the filesystem being exported fail to mount on the NFS server. [mp]
Optional mount point: If Export Only If Mounted is selected, a mount point can be specified if it differs from the export point. If not specified, it is assumed that the mount point and export point are the same. [mountpoint]
Set explicit Filesystem ID: Override the filesystem identification for the file handle and file attributes with this number. Useful to ensure that the NFS server and its failover use identical NFS file handles. [fsid]
The User Access tab contains the following options:
Treat remote root user as local root: Do not map requests from root to the anonymous user and group ID. [no_root_squash]
Treat all client users as anonymous users: Map all user and group IDs to the anonymous user and group ID. [all_squash]
Local user ID for anonymous users: If Treat All Client Users As Anonymous Users is enabled, use this user ID for the anonymous user. [anonuid]
Local group ID for anonymous users: If Treat All Client Users As Anonymous Users is enabled, use this group ID for the anonymous user. [anongid]
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.
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.
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:
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:
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.
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.
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:
TCP and UDP port 38001 for statd
TCP and UDP port 38002 for statd (outgoing)
TCP and UDP port 38003 for mountd
TCP and UDP port 38004 for rquotad
TCP port 38005 for lockd
UDP port 38006 for lockd
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.
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:
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.
There are three ways to mount an NFS export on a client system, assuming the server has given the client permission to do so:
Use the mount command along with the server name, exported directory, and local mount point.
Add the export to /etc/fstab so it is automatically mounted at boot time or is available to be mounted.
Optionally you can use the autofs service to mount the share when a user attempts to access it from a client.
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.
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.
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.
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.
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
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
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:
LinuxDevCenter/Using NFS for Networked Backups By Glenn Graham Glenn. Graham demonstrates a quick and easy network backup solution using NFS [March 06, 2003]
Linux NFS HOWTO
If the directory (disk space) for a user's home directory is located on another system and AutoFS is not being used to make that space available, follow these steps to NFS-mount the home directory:
oak:/export/home1/ignatz - /home/ignatz nfs - yes rw,intr
NOTE: The home directory does not have the same name on the user's system as it does on the server. For example, /export/home/ignatz on the server is mounted as /home/ignatz on the user's system.
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
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 quotes : Somerset Maugham : Marcus Aurelius : Kurt Vonnegut : Eric Hoffer : Winston Churchill : Napoleon Bonaparte : Ambrose Bierce : Bernard Shaw : Mark Twain Quotes
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
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 DOS : Programming Languages History : PL/1 : Simula 67 : C : History of GCC development : Scripting 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
The Peter Principle : Parkinson Law : 1984 : The Mythical Man-Month : How 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-2018 by Dr. Nikolai Bezroukov. www.softpanorama.org was initially created as a service to the (now defunct) UN Sustainable Development Networking Programme (SDNP) in the author free time and without any remuneration. This document is an industrial compilation designed and created exclusively for educational use and is distributed under the Softpanorama Content License. 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|
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: September 12, 2017