Managing Network File Systems in Oracle® Solaris 11.2

Exit Print View

 
Updated: July 2014
 
 

mount Command

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.

Each file system type included in the standard Oracle Solaris installation has specific options for the mount command. For NFS file systems options, see the mount_nfs (1M) man page. For UFS file system options, see the mount_ufs (1M) man page.

You can 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 by Using an NFS URL for further information.

Caution

Caution  -  The mount command 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.

mount Options for NFS File Systems

This section describes 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.

bg|fg

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 because it 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.

forcedirectio

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 (noforcedirectio).

To permit an application to issue concurrent writes, as well as concurrent reads and writes, to a single file on the client, use the –forcedirectio mount option. This option, enables 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.

largefiles

With this option, you can access files that are larger than 2 Gbytes. 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. 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.

nolargefiles

This option for UFS mounts guarantees that no large files can exist on the file system. Because the existence of large files can be controlled only 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.

nosuid|suid

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. Mounting 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 Oracle Solaris file systems.

public

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.

rw|ro

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.

sec=mode

You can use this option to specify the authentication mechanism to be used during the mount transaction. The available values for mode are:

  • krb5 for Kerberos Version 5 authentication service

  • krb5i for Kerberos Version 5 with integrity

  • krb5p for Kerberos Version 5 with privacy

  • none for no authentication

  • dh for Diffie-Hellman (DH) authentication

  • sys for standard UNIX authentication

The modes are also defined in /etc/nfssec.conf.

soft|hard

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. 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.

Using the mount Command

The following examples show different scenario:

  • In NFS Version 2 or NFS Version 3, both of the following 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 NFS Version 3, the –O option in the following command forces the man pages from the server bee to be mounted on the local system even if /usr/man has already been mounted.

    # mount -F nfs -O bee:/export/share/man /usr/man

    In NFS Version 4, the following command would accomplish the same mount:

    # mount -F nfs -o vers=4 -O bee:/export/share/man /usr/man

  • In NFS Version 2 or NFS Version 3, the following command uses client failover.

    # mount -F nfs -r bee,wasp:/export/share/man /usr/man

    In NFS Version 4, the following command uses client failover.

    # mount -F nfs -o vers=4 -r bee,wasp:/export/share/man /usr/man
    Note -  When used from the command line, the listed servers must support the same version of the NFS protocol. Do not use both NFS Version 2 and NFS Version 3 servers when running mount from the command line. You can use both servers with autofs because autofs automatically selects the best subset of NFS Version 2 or NFS Version 3 servers.

  • The following example shows how to use an NFS URL with the mount command in NFS Version 2 or NFS Version 3.

    # mount -F nfs nfs://bee//export/share/man /usr/man

    The following example shows how to use an NFS URL with the mount command in NFS Version 4.

    # mount -F nfs -o vers=4 nfs://bee//export/share/man /usr/man

  • The following example shows how to use the –forcedirectio mount option to enable the client to permit concurrent writes, as well as concurrent reads and writes, to a file.

    # 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.

    Note -  If support for concurrent writes is not enabled, all write requests are serialized. When a write request is in progress, a second write request has to wait for the first write request to be completed before proceeding.

  • The following example shows how to use the mount command with no arguments to display file systems that are mounted on a client.

    % 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
Copyright © 2002, 2014, Oracle and/or its affiliates. All rights reserved. Legal Notices
Previous
Next