This window configures the filer for CIFS service. After you make a change, click the Save Changes button to save the changes to the filer. To view the changes that you made, click the View Changes button. To reload the current settings from the filer, click the Reload button.
The configurable fields in this window are:
The filer requires a software license to enable CIFS service. The license is installed on the filer at the factory per your order, so the initial setup of your filer does not involve entering license codes.
You need to enter license codes only if any of the following conditions applies:
Network Appliance provides you with the appropriate license codes when shipping you the software upgrade kit or when giving you instructions for obtaining the software upgrade over the Internet.
After you select Not Licensed, the filer stops CIFS service immediately.
After you enter the license code, enable CIFS service so the filer can restart CIFS service immediately. To enable CIFS service, use the CIFS On/Off window under Task Assistant.
The Windows Internet Naming Service (WINS) allows your filer NetBIOS name to be resolved by a WINS server so that clients on different networks can resolve the filer name. You can enter up to IP addresses of up to four WINS servers.
When a CIFS user tries to obtain access to a file on the filer, the filer uses one of two methods for determining a user's file access rights: PC style and UNIX style. The two methods are offered because share-level ACLs do not work properly with the UNIX-style method but do work properly with the PC-style method. You can select PC or UNIX in this field.
If the filer uses PC style, when a CIFS user tries to obtain access to a file, the filer checks the share-level ACL before checking the UNIX-style permissions. (The filer gives each file UNIX-style permissions upon file creation.) PC style offers these advantages:
If your site requires private directories for CIFS users, use the NetApp Permissions Tool (available from NOW) on a PC to modify permissions for the private directories even when you use PC style.
When the filer uses UNIX style, when a CIFS user tries to obtain access to a file, the filer checks the UNIX-style permissions before checking the share-level ACL. (The filer gives each file UNIX-style permissions upon file creation.)
When UNIX style is used, the GID of a file is significant. That is, the filer compares the GID of the file with the GIDs of a user to determine whenever the user belongs to a particular group. The filer applies the group permissions only to members of the group as specified in the UNIX group database.
If you are using UNIX style permissions, in general it is best to set the ACL to everyone and rely on UNIX permissions to control access.
Use the following guidelines to determine whether the UNIX style is suitable for your site:
If you use a domain controller for authentication, guests are users who are not in trusted domains.
If you use a UNIX password database for authentication, guests are users who do not have an entry in the database.
Specify the name of the guest account, usually guest or nobody (a preconfigured account in the /etc/passwd file), to provide a guest account. To disable guest access, leave this field blank.
Set the guest account to the name of an account in the UNIX password database (typically guest, which is mapped to the UNIX account nobody with the same access rights as the user everyone).
This field creates a share containing home shares for registered CIFS users and a share for guest (assuming the guest access option is set to the PC convention "guest"). For example, if there are users called user1 and user2, the share contains directories for user1, user2, and guest. When user1 connects to the filer and asks for its list of shares, the display shows an offer called user1, but not user2 or guest (or any other individual user).
In the Home Directory field, specify a complete path name to the directory that contains the users' home directories. Then the filer creates a share named CIFS.HOMEDIR that maps to your specified directory. Within the specified directory, create a directory for each user. Each directory name must exactly match the user's login name. Also, make each user the directory's owner.
To each user, the home directory appears as a share. A user accesses his or her home share in the same way as any other share. That is, the user can open the share with Network Neighborhood, by mapping a drive, or by using a UNC name. The UNC name is simply
\\filer\username
Because share names are truncated to 12 characters, the home directory name might show a truncated version of the user's account name. For example, consider the 13-letter name "administrator". From the filer point of view, the home directory for "administrator" has a name that exactly matches the account name "administrator", but use of that directory is offered under the truncated share name "administrato".
(If there were users "administrator" and "administrator1", each would see an offer for his or her own home directory, but both would see it as an offer to share the name "administrato". Thus, each gets the correct directory, even though the share names appear the same.)
Using the Home Directory field to create home directories is useful only if users do not need to read or write other users' home directories.
If you are using a domain controller, you can allow users who are in trusted domains but who do not have a password on the filer to connect to the filer. To create such an account, enter the name of the generic account. All users in the generic account have the same rights.
The NetBIOS scope ID feature provides a naming service for the NetBIOS over TCP/IP (NBT) module. The NetBIOS scope ID feature is not compatible with DNS. The scope ID is a case-sensitive character string that is added to the end of a NetBIOS name.
NOTE: Microsoft recommends that you not use NetBIOS scope ID if you are not currently using it.
Do not enable scope ID for the filer unless you are already using it for other machines because you can unintentionally isolate the filer from clients that do not have the same NetBIOS scope ID.
If you are not using DNS, NetBIOS scope ID enables you to limit traffic to only those machines with the same NetBIOS scope ID.
You can use this feature to isolate a group of computers on a network so they can communicate only with other computers with the identical NetBIOS Scope ID, or to build virtual subnetworks (groups of machines that see each only other). By default, the scope ID is a null string, but if the filer is to run in a NetBIOS scope other than the default one, its scope ID must be set to the ID of that scope. The scope ID can be changed only when CIFS is not running.
Oplocks (opportunistic locks) enable the redirector on a client in certain file-sharing scenarios to perform client-side caching of read-ahead, write-behind, and lock information. A client can, therefore, work with a file (read or write it) without regularly reminding the server that it needs access to the file in question, thus improving performance by reducing network traffic.
Under some circumstances, if a process has an exclusive oplock on a file and a second process attempts to open the file, the first process must relinquish the oplock and access to the file. The redirector must then invalidate cached data and flush writes and locks, resulting in possible loss of data that was to be written. Oplocks are, therefore, best used in an environment where most operations are reads rather than writes.
Any application that has write-cached data can lose that data under the following set of circumstances:
The cache itself does not have any error handling - the applications do. When the application makes a write to cache, it always completes. If the cache in turn makes a write to the target system over a network, it must assume that the write will complete because if it does not the data is lost.
Turn CIFS oplocks off under either of the following circumstances:
Otherwise, you leave CIFS oplocks on.
For additional information about oplocks, consult the Microsoft Knowledge Base at http://www.microsoft.com/kb
NOTE: You can turn CIFS oplocks on or off at individual clients. Turning CIFS oplocks on at the filer does not override any client-specific settings. Turning CIFS oplocks off at the filer disables all oplocks to or from the filer.