Exporting a directory hierarchy makes the directory hierarchy available for mounting by designated systems via a network. "Exported" does not mean "mounted": When a directory hierarchy is exported, it is placed in the list of directory hierarchies that can be mounted by other systems. An exported directory hierarchy may be mounted (or not) at any given time.
Exporting symbolic links and device files tip When you export a directory hierarchy that contains a symbolic link, make sure the object of the link is available on the client (remote) system. If the object of the link does not exist on a client system, you must export and mount it along with the exported link. Otherwise, the link will not point to the same file it points to on the server.
A device file refers to a Linux kernel interface. When you export a device file, you export that interface. If the client system does not have the same type of device available, the exported device will not work. To improve security on a client, you can use mount's nodev option (page 803) to prevent device files on mounted directory hierarchies from being used as devices.
A mounted directory hierarchy whose mount point is within an exported partition is not exported with the exported partition. You need to explicitly export each directory hierarchy you want exported, even if it resides within an already exported directory hierarchy. For example, assume two directory hierarchies, /opt/apps and /opt/apps/oracle, reside on two partitions. You must export each directory hierarchy explicitly, even though oracle is a subdirectory of apps. Most other subdirectories and files are exported automatically.
/etc/exports: Holds a List of Exported Directory Hierarchies
The /etc/exports file is the access control list for exported directory hierarchies that NFS clients can mount; it is the only file you need to edit to set up an NFS server. The exportfs utility (page 817) reads this file when it updates the files in /var/lib/nfs (page 815), which the kernel uses to keep its mount table current. The exports file controls the following NFS characteristics:
• Which clients can access the server (see also "Security" on page 802)
• Which directory hierarchies on the server each client can access
• How each client can access each directory hierarchy
• How client usernames are mapped to server usernames
• Various NFS parameters
Each line in the exports file has the following format:
export-point client1 (option-list) [client2(option-list)... ]
where export-point is the absolute pathname of the root directory of the directory hierarchy to be exported. The client1-n are the names or IP addresses of one or more clients, separated by SPACEs, that are allowed to mount the export-point. The option-list, described in the next section, is a comma-separated list of options that applies to the preceding client; it must not contain any SPACEs. There must not be any SPACE between each client name and the open parenthesis that starts the option-list.
You can either use shares-admin (page 809) to make changes to exports or edit this file manually. The following exports file gives grape read and write access to /home, and jam and the system at 192.168.0.12 read and write access to /pl6:
$ cat /etc/exports
/p16 192.168.0.12(rw,no_subtree_check) jam(rw,no_subtree_check)
The specified directories are on the local server. In each case, access is implicitly granted for the directory hierarchy rooted at the exported directory. You can specify IP addresses or hostnames and you can specify more than one client system on a line. By default, directory hierarchies are exported in readonly mode. The current version of exportfs complains when you do not specify either subtree_check or no_subtree_check (page 813).
The left column of this section lists default options, followed by nondefault options enclosed in parentheses. Refer to the exports man page for more information.
auth_nlm (no_auth_nlm) or secure_locks (insecure_locks)
Causes the server to require authentication of lock requests (using the NLM [NFS Lock Manager] protocol). Use no_auth_nlm for older clients when you find that only files that anyone can read can be locked.
Allows a directory to be exported only if it has been mounted. This option prevents a mount point that does not have a directory hierarchy mounted on it from being exported and prevents the underlying mount point from being exported. Also mp.
nohide (hide) When a server exports two directory hierarchies, one of which is mounted on the other, a client has to mount both directory hierarchies explicitly to access both. When the second (child) directory hierarchy is not explicitly mounted, its mount point appears as an empty directory and the directory hierarchy is hidden. The nohide option causes the underlying second directory hierarchy to appear when it is not explicitly mounted, but this option does not work in all cases.
ro (rw) (readonly) Permits only read requests on an NFS directory hierarchy. Use rw to permit read and write requests.
secure (insecure) Requires NFS requests to originate on a privileged port (page 1054) so a program running without root privileges cannot mount a directory hierarchy. This option does not guarantee a secure connection.
Checks subtrees for valid files. Assume you have an exported directory hierarchy that has its root below the root of the filesystem that holds it (that is, an exported subdirectory of a filesystem). When the NFS server receives a request for a file in that directory hierarchy, it performs a subtree check to confirm the file is in the exported directory hierarchy.
Subtree checking can cause problems with files that are renamed while opened and, when no_root_squash is used, files that only a process running with root privileges can access. The no_subtree_check option disables subtree checking and can improve reliability in some cases.
For example, you may need to disable subtree checking for home directories. Home directories are frequently subtrees (of /home), are written to often, and can have files within them frequently renamed. You would probably not need to disable subtree checking for directory hierarchies that contain files that are mostly read, such as /usr.
Because the default has changed (it is now no_subtree_check), exportfs displays a warning when you do not specify either subtree_check or no_subtree_check.
sync (async) (synchronize) Specifies that the server should reply to requests only after disk changes made by the request are written to disk. The async option specifies that the server does not have to wait for information to be written to disk and can improve performance, albeit at the cost of possible data corruption if the server crashes or the connection is interrupted.
wdelay (write delay) Causes the server to delay committing write requests when it antici-(no_wdelay) pates that another, related request will follow, thereby improving performance by committing multiple write requests within a single operation. The no_wdelay option does not delay committing write requests and can improve performance when the server receives multiple, small, unrelated requests.
Each user has a UID number and a primary GID number on the local system. The local /etc/passwd and /etc/group files may map these numbers to names. When a user makes a request of an NFS server, the server uses these numbers to identify the user on the remote system, raising several issues:
• The user may not have the same ID numbers on both systems. As a consequence, the user may have owner access to files of another user and not have owner access to his own files (see "NIS and NFS" for a solution).
• You may not want a user with root privileges on the client system to have owner access to root-owned files on the server.
• You may not want a remote user to have owner access to some important system files that are not owned by root (such as those owned by bin).
Critical files in NFS-mounted directories should be owned by root security Despite the mapping done by the root-squash option, a user with root privileges on a client system can use sudo or su to assume the identity of any user on the system and then access that user's files on the server. Thus, without resorting to all-squash, you can protect only files owned by root on an NFS server. Make sure that root—and not bin or another user—owns and is the only user who can modify or delete critical files within any NFS-mounted directory hierarchy.
Taking this precaution does not completely protect the system against an attacker with root privileges, but it can help thwart an attack from a less experienced malicious user.
Owner access to a file means that the remote user can execute or—worse—modify the file. NFS gives you two ways to deal with these cases:
• You can use the root_squash option to map the ID number of the root account on a client to UID 65534 on the server.
• You can use the all-squash option to map all NFS users on the client to UID 65534 on the server.
Use the anonuid and anongid options to override these values.
NIS and NFS When you use NIS (page 781) for user authorization, users automatically have the same UIDs on both systems. If you are using NFS on a large network, it is a good idea to use a directory service such as LDAP (page 1044) or NIS for authorization. Without such a service, you must synchronize the passwd files on all the systems manually.
Maps requests from root on a remote system so they appear to come from the UID 65534, an unprivileged user on the local system, or as specified by anonuid. This option does not affect other sensitive UIDs such as bin. The no_root_squash option turns off this mapping so that requests from root appear to come from root.
no_all_squash Does not change the mapping of users making requests of the NFS server. The (all_squash) all_squash option maps requests from all users—not just root—on remote systems to appear to come from the UID 65534, an unprivileged user on the local system, or as specified by anonuid. This option is useful for controlling access to exported public FTP, news, and other directories.
anonuid=«n and Set the UID or the GID of the anonymous account to un or gn, respectively. NFS anongid=gn uses these accounts when it does not recognize an incoming UID or GID and when it is instructed to do so by root_squash or all_squash.
Was this article helpful?