File Share resource type

  • [アーティクル]

Applies To: Windows Server 2003, Windows Server 2003 R2, Windows Server 2003 with SP1, Windows Server 2003 with SP2

File Share resource type

If you want to use a server cluster to provide a high availability file server you need to use the File Share resource type. You can use this resource type in three major ways:

  • Normal file share

    You can use the File Share resource type to provide a basic file share. Using this method, a single file folder is published to the network under a single name and functions much as an Server Message Block (SMB) share does.

  • Share or hide subdirectories

    You can also use the File Share resource to publish several network names: one each for a file folder and all of its immediate subfolders. This is an efficient way to create large numbers of related file shares on a single file server. An example application for this is creating a file share for each user who has files on the server. For more information on why you would want to share subdirectories, see Using a server cluster with large numbers of file shares. You can also prevent users from seeing the subdirectory shares when they browse the network. For more information on sharing or hiding subdirectories, see Share subfolders on a File Share resource.

    Important

    • When you share subdirectories, do not use the same name for subfolders under different folders (for example, \folder1\name1 and \folder2\name1). The first shared subdirectory to come online will remain online, but the second shared subdirectory will not be initialized and will not come online.

  • DFS root

    You can use the File Share resource type to create a resource that manages a stand-alone DFS root. Fault-tolerant DFS roots cannot be managed by this resource. The DFS root File Share resource has required dependencies on a network name and an Internet Protocol (IP) address. The network name can be either the cluster name or any other network name for a virtual server.

    A cluster-managed DFS root is very different from an Active Directory (or domain-based) DFS root. If the data that needs to be replicated is not changed very often, using a domain-based DFS root with replicas can be a better choice than a cluster-managed DFS root for providing high availability. If the data set changes frequently, replication is usually undesirable, and a cluster-managed DFS root is recommended.

    In Windows Server 2003, Enterprise Edition and Windows Server 2003, Datacenter Edition, server clusters support multiple standalone DFS roots. These multiple DFS roots can exist in multiple resource groups and each group can be hosted on a different node.

    Important

    • Clusters running Windows Server 2003, Enterprise Edition or Windows Server 2003, Datacenter Edition on some nodes and Windows 2000 on others will only support one DFS root per cluster.

    • Do not make DFS configuration changes (for example, by adding new links) while operating a mixed-version cluster.

    If you create multiple DFS roots in a single cluster, be aware of the following restrictions:

    • The name you specify for one DFS root cannot overlap with the names for other DFS roots in the same cluster. For example, if you named one DFS file share c:\dfsroots\root1, you could not share out other roots using names derived from the first DFS root, for example, c:\dfsroots, c:\dfsroots\root1, or c:\dfsroots\root1\root2.

    • The DFS roots must be hosted on NTFS partitions.

    • The name you give a non-clustered DFS root on a node's local storage must be different from the name you give a clustered DFS root on the cluster storage.

    For more information on DFS in a server cluster, see article Q301588, "Using DFS on a Server Cluster to Maintain a Single Namespace" in the Microsoft Knowledge Base.

    For more information on DFS, see Distributed File System (DFS).

When you create a new File Share resource, permissions for the Everyone group for that file share are automatically set by default to Read only. You can use Cluster Administrator or Cluster.exe to change the default permissions. For more information about using Cluster Administrator for this purpose, see View or set resource properties. For more information about using Cluster.exe for this purpose, see information about private property names for a File Share resource in Cluster resource.

You can also cache files from a cluster file share onto client computers. Clients can then have access to these files even when the client computer is disconnected from the network. For more information, see Set client-side caching for a File Share resource.

For more information on creating a highly available file share, see Create a cluster-managed file share.

You can also encrypt the data on your clustered file shares using Encrypting File System (EFS). For more information, see Create a cluster-managed encrypted file share.