Skip Navigation Links | |
Exit Print View | |
Managing Network File Systems in Oracle Solaris 11.1 Oracle Solaris 11.1 Information Library |
1. Managing Network File Systems (Overview)
2. Network File System Administration (Tasks)
3. Accessing Network File Systems (Reference)
Configuration Files and nfsmapid
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
mount Options for NFS File Systems
Non-File-System-Specific share Options
Setting Access Lists With the share Command
Commands for Troubleshooting NFS Problems
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
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
File Transfer Size Negotiation
Effects of the -public Option and NFS URLs When Mounting
What Is a Replicated File System?
Client-Side Failover in NFS Version 4
How WebNFS Security Negotiation Works
WebNFS Limitations With Web Browser Use
How Autofs Navigates Through the Network (Maps)
How Autofs Starts the Navigation Process (Master Map)
How Autofs Selects the Nearest Read-Only Files for Clients (Multiple Locations)
Variables in a Autofs Map Entry
Modifying How Autofs Navigates the Network (Modifying Maps)
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.
Generally, using the mirror mount facility is optimal for your NFSv4 clients except when you:
Need to use a different hierarchy on the client, than exists on the server
Need to use different mount options than those of the parent file system
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:
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.