Softpanorama
(slightly skeptical) Open Source Software Educational Society

May the source be with you, but remember the KISS principle ;-)

Google   


Sharing NFS Resources:
share command, /etc/dfs/dfstab file and dfshares command

NFS resources can be shared using the share(1M) command and unshared using the unshare(1M) command. In addition, any resources identified in the /etc/dfs/dfstab file are automatically shared at system boot or when the shareall(1M) command is used. Shared resources are automatically recorded in the /etc/dfs/sharetab file. When the unshareall(1M) command is used, all resources listed in the /etc/dfs/sharetab file are automatically unshared.

Actually, the NFS server is started automaticcly if /etc/dfs/sharetab contains at least one entry. NFS server starts at  level 3.  To start the NFS server daemons or to specify the number of concurrent NFS requests that can be handled by the nfsd daemon, use the /etc/rc3.d/S15nfs.server script. 

The NFS client is started at run level 2.

Many users experience difficulties trying to mount the Unix server directory with write access (rw) from SFU (see posts in the News section of SFU NFS page )

One way to get write access UID and GUI od the users should match and share command should specify the IP for sharing. For example the following works with Solaris server sharing home directory with Windows client:

share -F nfs -o rw=10.194.155.10 /export/home/bezroun

 

The share Command

The share command is used to share NFS resources so that NFS clients can mount and access them. At a minimum, the full pathname of the directory (or mount point of the file system) to be shared is specified as a command-line argument.

In addition, three other command-line arguments are supported:

The share command options for NFS are listed below (important are in bold):

The following listing shows how the share command allows NFS clients to mount the /export/home file system, including WebNFS clients. All clients will have read-only access:

# share -F nfs -o public,nosuid,ro,anon=-1 /export/home
# share -F nfs -o rw=usera:userb /somefs

If the share command is used without any command-line arguments, the currently shared resources will be listed.

The unshare Command

The unshare command is used to stop the sharing of NFS resources so that NFS clients can no longer mount and access them. At a minimum, the full pathname of a directory (or mount point of the file system) that is currently shared is specified as a command-line argument.

Only one other command-line argument is supported: the -F nfs command-line argument, which is used to specify the type of file system. If not specified, the default file system type listed in the /etc/dfs/fstypes file (NFS) is assumed.

The following listing shows using the unshare command to stop the sharing of the /export/home file system:

# unshare -F nfs /export/home

The /etc/dfs/dfstab File

The /etc/dfs/dfstab file specifies resources that should be shared automatically when the system is changed to run level 3 or when the shareall command is used.

This file can be modified using any text editor. To automatically share a resource, add a line to the /etc/dfs/dfstab file that contains the share command with the desired command-line arguments and options that would have been entered manually. To remove automatic sharing of a resource, delete the appropriate share command from /etc/dfs/dfstab.

The following entry from /etc/dfs/dfstab is used to share the /export/home directory:

share -F nfs  -o public,nosuid,ro,anon=-1  -d "home directories" /export/home

You might be wondering why some of the directories, files, and even commands associated with NFS use the phrase dfs or df. This comes from the System V (5) version of the Unix operating system. Originally, Distributed File Systems (DFS) had two variations: NFS and the Remote File System (RFS). Directories, files, and commands that used the dfs phrase were used to manage and configure both types of file systems. Since then, RFS has disappeared, leaving behind the DFS legacy.

The shareall and unshareall Commands

The shareall command is used to share one or more resources. If the -F nfs command-line argument is not specified, the default file system type (NFS) is assumed. If the name of a file (that contains one or more share commands) is not specified as a command-line argument, the /etc/dfs/dfstab file is used by default.

The unshareall command is used to unshare all currently shared resources. If the -F nfs command-line argument is not specified, the default file system type (NFS) is assumed.

The dfshares Command

The dfshares(1M) command is used to list shared resources on either the local or a remote system. If the hostname (or IP address) of a remote system is specified as a command-line argument, the resources shared on that system are listed.

In addition, two other command-line arguments are supported. The -F nfs command-line argument is used to specify the type of file system. If not specified, the default file system type listed in the /etc/dfs/fstypes file (NFS) is assumed. If the -h command-line argument is specified, the header describing the columns of the resource listing is not displayed.

In addition, information on locally shared resources can be obtained from the /etc/dfs/sharetab file. This file is updated by the share, shareall, unshare, and unshareall commands to reflect the currently shared resources.


Copyright © 1996-2008 by Dr. Nikolai Bezroukov. www.softpanorama.org was created as a service to the UN Sustainable Development Networking Programme (SDNP) in the author free time. Submit comments This document is an industrial compilation designed and created exclusively for educational use and is placed under the copyright of the Open Content License(OPL). Original materials copyright belong to respective owners. Quotes are made for educational purposes only in compliance with the fair use doctrine.

Standard disclaimer: The statements, views and opinions presented on this web page are those of the author and are not endorsed by, nor do they necessarily reflect, the opinions of the author present and former employers, SDNP or any other organization the author may be associated with. We do not warrant the correctness of the information provided or its fitness for any purpose.

Last modified: February 28, 2008