JavaScript is required to for searching.
Skip Navigation Links
Exit Print View
Managing Network File Systems in Oracle Solaris 11.1     Oracle Solaris 11.1 Information Library
search filter icon
search icon

Document Information


1.  Managing Network File Systems (Overview)

2.  Network File System Administration (Tasks)

3.  Accessing Network File Systems (Reference)

NFS Files

/etc/default/nfslogd File

/etc/nfs/nfslog.conf File

NFS Daemons

automountd Daemon

lockd Daemon

mountd Daemon

nfs4cbd Daemon

nfsd Daemon

nfslogd Daemon

nfsmapid Daemon

Configuration Files and nfsmapid

Precedence Rules

nfsmapid and DNS TXT Records

Checking for the NFS Version 4 Domain

Configuring the NFS Version 4 Default Domain

Configuring an NFS Version 4 Default Domain in the Oracle Solaris 11 Release

Configuring an NFS Version 4 Default Domain in the Solaris 10 Release

Additional Information About nfsmapid

reparsed Daemon

statd Daemon

NFS Commands

automount Command

clear_locks Command

fsstat Command

mount Command

mount Options for NFS File Systems

Using the mount Command

umount Command

mountall Command

umountall Command

sharectl Command

set Subcommand

get Subcommand

status Subcommand

share Command

Non-File-System-Specific share Options

NFS-Specific share Options

Setting Access Lists With the share Command

unshare Command

shareall Command

unshareall Command

showmount Command

nfsref Command

FedFS Commands

Commands for Troubleshooting NFS Problems

nfsstat Command

pstack Command

rpcinfo Command

snoop Command

truss Command


How the NFS Service Works

Version Negotiation in NFS

Features in NFS Version 4

Unsharing and Resharing a File System in NFS Version 4

File-System Namespace in NFS Version 4

Volatile File Handles in NFS Version 4

Client Recovery in NFS Version 4

OPEN Share Support in NFS Version 4

Delegation in NFS Version 4

ACLs and nfsmapid in NFS Version 4

Reasons for ID Mapping to Fail

Avoiding ID Mapping Problems With ACLs

Checking for Unmapped User or Group IDs

Additional Information About ACLs or nfsmapid

UDP and TCP Negotiation

File Transfer Size Negotiation

How File Systems Are Mounted

Effects of the -public Option and NFS URLs When Mounting

Client-Side Failover

Failover Terminology

What Is a Replicated File System?

Failover and NFS Locking

Client-Side Failover in NFS Version 4

How NFS Server Logging Works

How the WebNFS Service Works

How WebNFS Security Negotiation Works

WebNFS Limitations With Web Browser Use

Secure NFS System

Secure RPC

DH Authentication

KERB Authentication

Using Secure RPC With NFS

How Mirror Mounts Work

When to Use Mirror Mounts

Mounting a File System Using Mirror Mounts

Unmounting a File System Using Mirror Mounts

How NFS Referrals Work

When to Use NFS Referrals?

Creating an NFS Referral

Removing an NFS Referral

Autofs Maps

Master Autofs Map

Mount Point /home

Mount Point /net

Mount Point /nfs4

Direct Autofs Maps

Mount Point /-

Indirect Autofs Maps

How Autofs Works

How Autofs Navigates Through the Network (Maps)

How Autofs Starts the Navigation Process (Master Map)

Autofs Mount Process

Simple Autofs Mount

Hierarchical Mounting

Autofs Unmounting

How Autofs Selects the Nearest Read-Only Files for Clients (Multiple Locations)

Autofs and Weighting

Variables in a Autofs Map Entry

Maps That Refer to Other Maps

Executable Autofs Maps

Modifying How Autofs Navigates the Network (Modifying Maps)

Default Autofs Behavior With Name Services

Autofs Reference

Autofs and Metacharacters

Ampersand (&)

Asterisk (*)

Autofs and Special Characters


How Mirror Mounts Work

The Oracle Solaris release includes a new mounting facility called mirror mounts. Mirror mounts allow a NFSv4 client to access files in a file system as soon as the file system is shared on an NFSv4 server. The files can be accessed without the overhead of using the mount command or updating autofs maps. In effect, once a NFSv4 file system is mounted on a client, any other file systems from that server could also be mounted.

When to Use Mirror Mounts

Generally, using the mirror mount facility is optimal for your NFSv4 clients except when you:

Mounting a File System Using Mirror Mounts

If a file system is mounted on an NFSv4 client using manual mounts or autofs, any additional file systems added to the mounted file system, may be mounted on the client using the mirror mount facility. The client requests access to the new file system using the same mount options as were used on the parent directory. If the mount fails for any reason, the normal NFSv4 security negotiations occur between the server and the client to adjust the mount options so that the mount request succeeds.

Where there is an existing automount trigger point setup for a particular server file system, the automount trigger takes precedence over mirror mounting, so a mirror mount will not occur for that file system. To use mirror mounts in this case, the automount entry would need to be removed.

In the Oracle Solaris 11 release, accessing /net or /home automount point cause a mount of the /net or /home server namespace. Access to directories or files under those directories will be given through the mirror mounts feature.

For specific instructions on how to get mirror mounts to work see:

Unmounting a File System Using Mirror Mounts

Mirror mounted file systems will be automatically unmounted if idle, after a certain period of inactivity. The period is set using the timeout parameter, which is used by the automounter for the same purpose.

If an NFS file system is manually unmounted, then any mirror mounted file systems contained within it will also be unmounted, if idle. If there is an active mirror mounted file system within, the manual unmount will fail, as though that original file system were busy. A forced unmount will, however, be propagated through to all enclosed mirror-mounted file systems.

If a file system boundary is encountered within an automounted file system, a mirror mount will occur. When the automounter unmounts the parent filesystem, any mirror-mounted file systems within it will also be automatically unmounted, if idle. If there is an active mirror mounted file system, the automatic unmount will not occur, which preserves current automount behavior.