CIFS config

WINS servers

Access semantics

Guest account

Home directory

Generic account

Scope ID

Comment

Codepage

Oplocks enabled

NOTE: You can configure the following fields only if CIFS is not running:

• WINS Servers
• Comment
• Codepage

CIFS license

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:

• You purchased a filer with a release earlier than Release 4.0 and you are upgrading it.
• You want to enable CIFS, which was not previously licensed for your filer.
• You reinstalled the file system on the filer.

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, CIFS does not start automatically. You have to start the CIFS service.

WINS servers

The Windows Internet Naming Service (WINS) enables 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 four WINS server IP addresses.

Access semantics

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 Windows NT permissions do not work properly with the UNIX-style method but do work properly with the PC-style method. The following list describes the meaning of the PC style and UNIX style:

PC

If the filer uses PC style, when a CIFS user tries to obtain access to a file, the filer checks the share-level Windows NT permissions before checking the UNIX-style permissions. (The filer gives each file UNIX-style permissions upon file creation.) PC style offers these advantages:

• Windows NT permissions work.
• You do not need a UNIX client to manage file permissions. You can leave the file permissions at their default settings, and use share-level Windows NT permissions to control the access rights of CIFS users.

If your site requires private directories for CIFS users, use the NetApp Permissions Tool (available from NOW and from the Data ONTAP CD) on a PC to modify permissions for the private directories even when you use PC style.

UNIX

If 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 Windows NT permissions. (The filer gives each file UNIX-style permissions upon file creation.)

When the filer uses UNIX style, 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 Windows NT permissions to everyone and rely on UNIX permissions to control access.

Use the following guidelines to determine whether UNIX style is suitable for your site:

• If the CIFS users also use NFS to mount directories and are familiar with UNIX-style file permissions, the users can use UNIX clients to manage the permissions of the files they create.
• If you are satisfied with the way UNIX systems define groups, use the UNIX style to minimize the work required for managing access rights. For example, if you want all members of the "hr" group to have the same rights, in the Windows NT permissions, assign read, write, and execute rights to the group "hr." In this way, you can use UNIX permissions for each file exclusively for managing access rights; you need to add entries to the Windows NT permissions only if you want to limit the access rights for particular users of the "hr" group.

Guest account

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).

Home directory

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. Users accesses their home shares in the same way as any other share. That is, users 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.

Generic account

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.

Scope ID

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 only each 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.

Comment

The Comment field contains a description about the filer. This description appears next to the filer name in Server Manager. The description helps you distinguish the filer from other CIFS servers.

Initially, the filer does not have any comment associated with it.

Codepage

This field provides support for international character sets. Clients can use non-ASCII characters for domain names, host names, share names, file names, and user names.

Follow these guidelines when selecting the code page:

• If all of the filer's clients use English, select 437 (English).
• If some of the filer's clients use English, some use other European languages, and all clients are 32-bit systems, select 850 (Western Europe).
• If the clients are Windows for Workgroups or DOS systems and they  need to use non-ASCII characters, select a code page that is the same as the clients'.

NOTE: Select the code page carefully. If you change the code page, a name previously encoded in non-ASCII characters become unreadable.

Oplocks enabled

How oplocks work

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:

• It has an exclusive oplock on the file.
• It is told to either break that oplock or close the file.
• During the process of flushing the write cache, the network or target system generates an error.

The cache itself does not have any error handling but 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.

Deciding whether oplocks should be enabled

Turn CIFS oplocks Off under either of the following circumstances:

• You are using a database application whose documentation recommends that oplocks be turned Off.
• You are handling critical data. (That is, you have a good network but you cannot afford data loss).

After you disable oplocks, the filer stops granting new oplocks and tries to break all the existing oplocks. If a client does not respond to the filer's oplock break request, you can break the oplocks on that client by disconnecting the filer from that client.

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.

For additional information about oplocks, consult the Microsoft Knowledge Base at http://www.microsoft.com/kb