With this command, you can attach a named file system, either local or remote, to a specified mount point. For more information, see the mount(1M) man page. Used without arguments, mount displays a list of file systems that are currently mounted on your computer.
Many types of file systems are included in the standard Solaris installation. Each file-system type has a specific man page that lists the options to mount that are appropriate for that file-system type. The man page for NFS file systems is mount_nfs(1M). For UFS file systems, see mount_ufs(1M).
The Solaris 7 release includes the ability to select a path name to mount from an NFS server by using an NFS URL instead of the standard server:/pathname syntax. See How to Mount an NFS File System Using an NFS URL for further information.
The version of the mount command that is included in any Solaris release from 2.6 to the current release does not warn about invalid options. The command silently ignores any options that cannot be interpreted. Ensure that you verify all of the options that were used so that you can prevent unexpected behavior.
The subsequent text lists some of the options that can follow the -o flag when you are mounting an NFS file system. For a complete list of options, refer to the mount_nfs(1M) man page.
These options can be used to select the retry behavior if a mount fails. The bg option causes the mount attempts to be run in the background. The fg option causes the mount attempt to be run in the foreground. The default is fg, which is the best selection for file systems that must be available. This option prevents further processing until the mount is complete. bg is a good selection for noncritical file systems because the client can do other processing while waiting for the mount request to be completed.
This option improves performance of large sequential data transfers. Data is copied directly to a user buffer. No caching is performed in the kernel on the client. This option is off by default.
Previously, all write requests were serialized by both the NFS client and the NFS server. The NFS client has been modified to permit an application to issue concurrent writes, as well as concurrent reads and writes, to a single file. You can enable this functionality on the client by using the forcedirectio mount option. When you use this option, you are enabling this functionality for all files within the mounted file system. You could also enable this functionality on a single file on the client by using the directio() interface. Unless this functionality has been enabled, writes to files are serialized. Also, if concurrent writes or concurrent reads and writes are occurring, then POSIX semantics are no longer being supported for that file.
For an example of how to use this option, refer to Using the mount Command.
With this option, you can access files that are larger than 2 Gbytes on a server that is running the Solaris 2.6 release. Whether a large file can be accessed can only be controlled on the server, so this option is silently ignored on NFS version 3 mounts. Starting with release 2.6, by default, all UFS file systems are mounted with largefiles. For mounts that use the NFS version 2 protocol, the largefiles option causes the mount to fail with an error.
This option for UFS mounts guarantees that no large files can exist on the file system. See the mount_ufs(1M) man page. Because the existence of large files can only be controlled on the NFS server, no option for nolargefiles exists when using NFS mounts. Attempts to NFS-mount a file system by using this option are rejected with an error.
Starting in the Solaris 10 release, the nosuid option is the equivalent of specifying the nodevices option with the nosetuid option. When the nodevices option is specified, the opening of device-special files on the mounted file system is disallowed. When the nosetuid option is specified, the setuid bit and setgid bit in binary files that are located in the file system are ignored. The processes run with the privileges of the user who executes the binary file.
The suid option is the equivalent of specifying the devices option with the setuid option. When the devices option is specified, the opening of device-special files on the mounted file system is allowed. When the setuid option is specified, the setuid bit and the setgid bit in binary files that are located in the file system are honored by the kernel.
If neither option is specified, the default option is suid, which provides the default behavior of specifying the devices option with the setuid option.
The following table describes the effect of combining nosuid or suid with devices or nodevices, and setuid or nosetuid. Note that in each combination of options, the most restrictive option determines the behavior.
Behavior From the Combined Options |
Option |
Option |
Option |
---|---|---|---|
The equivalent of nosetuid with nodevices |
nosuid |
nosetuid |
nodevices |
The equivalent of nosetuid with nodevices |
nosuid |
nosetuid |
devices |
The equivalent of nosetuid with nodevices |
nosuid |
setuid |
nodevices |
The equivalent of nosetuid with nodevices |
nosuid |
setuid |
devices |
The equivalent of nosetuid with nodevices |
suid |
nosetuid |
nodevices |
The equivalent of nosetuid with devices |
suid |
nosetuid |
devices |
The equivalent of setuid with nodevices |
suid |
setuid |
nodevices |
The equivalent of setuid with devices |
suid |
setuid |
devices |
The nosuid option provides additional security for NFS clients that access potentially untrusted servers. The mounting of remote file systems with this option reduces the chance of privilege escalation through importing untrusted devices or importing untrusted setuid binary files. All these options are available in all Solaris file systems.
This option forces the use of the public file handle when contacting the NFS server. If the public file handle is supported by the server, the mounting operation is faster because the MOUNT protocol is not used. Also, because the MOUNT protocol is not used, the public option allows mounting to occur through a firewall.
The -rw and -ro options indicate whether a file system is to be mounted read-write or read-only. The default is read-write, which is the appropriate option for remote home directories, mail-spooling directories, or other file systems that need to be changed by users. The read-only option is appropriate for directories that should not be changed by users. For example, shared copies of the man pages should not be writable by users.
You can use this option to specify the authentication mechanism to be used during the mount transaction. The value for mode can be one of the following.
Use krb5 for Kerberos version 5 authentication service.
Use krb5i for Kerberos version 5 with integrity.
Use krb5p for Kerberos version 5 with privacy.
Use none for no authentication.
Use dh for Diffie-Hellman (DH) authentication.
Use sys for standard UNIX authentication.
The modes are also defined in /etc/nfssec.conf.
An NFS file system that is mounted with the soft option returns an error if the server does not respond. The hard option causes the mount to continue to retry until the server responds. The default is hard, which should be used for most file systems. Applications frequently do not check return values from soft-mounted file systems, which can make the application fail or can lead to corrupted files. If the application does check the return values, routing problems and other conditions can still confuse the application or lead to file corruption if the soft option is used. In most situations, the soft option should not be used. If a file system is mounted by using the hard option and becomes unavailable, an application that uses this file system hangs until the file system becomes available.
Refer to the following examples.
In NFS version 2 or version 3, both of these commands mount an NFS file system from the server bee read-only.
# mount -F nfs -r bee:/export/share/man /usr/man |
# mount -F nfs -o ro bee:/export/share/man /usr/man |
In NFS version 4, the following command line would accomplish the same mount.
# mount -F nfs -o vers=4 -r bee:/export/share/man /usr/man |
In NFS version 2 or version 3, this command uses the -O option to force the man pages from the server bee to be mounted on the local system even if /usr/man has already been mounted. See the following.
# mount -F nfs -O bee:/export/share/man /usr/man |
In NFS version 4, the following command line would accomplish the same mount.
# mount -F nfs -o vers=4 -O bee:/export/share/man /usr/man |
In NFS version 2 or version 3, this command uses client failover.
# mount -F nfs -r bee,wasp:/export/share/man /usr/man |
In NFS version 4, the following command line uses client failover.
# mount -F nfs -o vers=4 -r bee,wasp:/export/share/man /usr/man |
When used from the command line, the listed servers must support the same version of the NFS protocol. Do not use both version 2 and version 3 servers when running mount from the command line. You can use both servers with autofs. Autofs automatically selects the best subset of version 2 or version 3 servers.
Here is an example of using an NFS URL with the mount command in NFS version 2 or version 3.
# mount -F nfs nfs://bee//export/share/man /usr/man |
Here is an example of using an NFS URL with the mount command in NFS version 4.
# mount -F nfs -o vers=4 nfs://bee//export/share/man /usr/man |
Use the forcedirectio mount option to enable the client to permit concurrent writes, as well as concurrent reads and writes, to a file. Here is an example.
# mount -F nfs -o forcedirectio bee:/home/somebody /mnt |
In this example, the command mounts an NFS file system from the server bee and enables concurrent reads and writes for each file in the directory /mnt. When support for concurrent reads and writes is enabled, the following occurs.
The client permits applications to write to a file in parallel.
Caching is disabled on the client. Consequently, data from reads and writes is kept on the server. More explicitly, because the client does not cache the data that is read or written, any data that the application does not already have cached for itself is read from the server. The client's operating system does not have a copy of this data. Normally, the NFS client caches data in the kernel for applications to use.
Because caching is disabled on the client, the read-ahead and write-behind processes are disabled. A read-ahead process occurs when the kernel anticipates the data that an application might request next. The kernel then starts the process of gathering that data in advance. The kernel's goal is to have the data ready before the application makes a request for the data.
The client uses the write-behind process to increase write throughput. Instead of immediately starting an I/O operation every time an application writes data to a file, the data is cached in memory. Later, the data is written to the disk.
Potentially, the write-behind process permits the data to be written in larger chunks or to be written asynchronously from the application. Typically, the result of using larger chunks is increased throughput. Asynchronous writes permit overlap between application processing and I/O processing. Also, asynchronous writes permit the storage subsystem to optimize the I/O by providing a better sequencing of the I/O. Synchronous writes force a sequence of I/O on the storage subsystem that might not be optimal.
Significant performance degradation can occur if the application is not prepared to handle the semantics of data that is not being cached. Multithreaded applications avoid this problem.
If support for concurrent writes is not enabled, all write requests are serialized. When requests are serialized, the following occurs. When a write request is in progress, a second write request has to wait for the first write request to be completed before proceeding.
Use the mount command with no arguments to display file systems that are mounted on a client. See the following.
% mount / on /dev/dsk/c0t3d0s0 read/write/setuid on Wed Apr 7 13:20:47 2004 /usr on /dev/dsk/c0t3d0s6 read/write/setuid on Wed Apr 7 13:20:47 20041995 /proc on /proc read/write/setuid on Wed Apr 7 13:20:47 2004 /dev/fd on fd read/write/setuid on Wed Apr 7 13:20:47 2004 /tmp on swap read/write on Wed Apr 7 13:20:51 2004 /opt on /dev/dsk/c0t3d0s5 setuid/read/write on Wed Apr 7 13:20:51 20041995 /home/kathys on bee:/export/home/bee7/kathys intr/noquota/nosuid/remote on Wed Apr 24 13:22:13 2004 |