CIFS Configuration

CIFS License
WINS Servers
Access Semantics
Guest Account
Home Directory
Generic Account
Scope ID
Oplocks Enabled

The CIFS configuration can only be modified when CIFS is disabled. If CIFS is enabled, you must first disable the service by shutting down the filer before you modify the CIFS configuration.

CIFS License

The filer requires software licenses to enable NFS, CIFS, or HTTP services. Licenses are 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 apply:

You purchased a filer with a release earlier than Release 4.0, and you are upgrading it to Release 4.0 or later.
You want to enable a protocol not previously licensed for your filer.
The filer's file system becomes corrupt and must be rebuilt.

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. If licensed for CIFS service, enter the code.

WINS Servers

The Windows Internet Naming Service (WINS) servers links names and IP addresses within a network and among logical subnetworks. If you have a WINS server, enter the IP addresses of the WINS server. You can specify up to four addresses.

Access Semantics

Specifies the method that the filer uses to determine CIFS users' file access rights (read, write, and execute rights). The available methods are PC style and UNIX style. If your environment consists of CIFS users only, use PC style (the default). If both NFS and CIFS users share files on the filer, read the following information to determine which method is suitable for your site (the choice between PC style and UNIX style semantics affects CIFS users only):

PC style means that a user's rights to a file are determined by the rights assigned in the share's Access Control List (ACL) and limited by the UNIX permissions associated with the file. The following example illustrates how the filer determines whether you can write to a file named file.1 in the share named doc. To be able to write to file.1, you must meet both of these requirements:
- You have write permission for the doc share according to the ACL for doc.
- You have write permission according to the UNIX-style permission bits associated with file.1. (At the time a file is created, it inherits the UNIX-style permissions from the parent directory.)
  The filer checks the UNIX-style permissions as follows:
- If you are the file owner, the filer applies the owner's permissions.
- Otherwise, the filer applies the group permissions. For the owner, the filer disregards the group ID (GID) associated with file.1. That is, the UNIX-style group permissions associated with file.1 are applicable to everyone other than the owner.
UNIX style means your read, write, and execute rights to a file depend on your user ID (UID), group ID (GID), and the UNIX-style permission bits associated with the file. The filer checks the UID, GID, and permission bits in the same way as a UNIX system. The filer only differs from a UNIX system in that the filer gives fewer rights to you if the rights specified by ACL are more restrictive than the UNIX-style permissions. The following example illustrates whether you can write to a file named file.1 in the share named doc. If you are not the owner of file.1, you must meet these requirements:
- You belong to a group that has write permission for file.1. The filer uses at least one GID of file.1 and information in /etc/group or the NIS group map to decide whether you are a member of the group.
- You have write permission for the doc share according to the share's ACL.
  
  NOTE: If you use UNIX-style permissions on the filer, set the share ACL to everyone rwx. That way the UNIX rights will work just as they do on a UNIX system.

Guest Account

Enables guest access to the filer through a guest account. If you are using a domain controller, you can allow users who are not in trusted domains to connect to the filer. When you leave this field blank, a CIFS user can log onto the filer without an account in the password database, provided a domain controller authenticates the user.

The guest account is usually set to the name of an account in the NIS passwd map or /etc/passwd file (typically, guest, which is mapped to the UNIX account nobody with the same access rights as the user everyone). When the CIFS guest account is set to the name of an account in the NIS passwd map or /etc/passwd file, guest access to the filer is enabled and the user has the UNIX user ID and the group ID of the guest account.

: NOTE: If the filer is serving NT clients that have installed NT Service Pack 3, you must configure a generic account.

Home Directory

Specifies the complete pathname of the "homes directory." The subdirectories in this directory should be named according to the users' names of the CIFS users who will be accessing the homes directory. When a CIFS user connects to the filer and there is a directory name that exactly matches their user's name, the user sees a share of that name (truncated to 12 characters), which is the user's home directory. Only the user can access their home directory using this share. All other users are denied access.

Generic Account

Enables guest access to the filer through a generic account. If you are using a domain controller, you can allow users who are in trusted domains to connect to the filer. When the CIFS generic account is set to the name of an account, users who have an account in a trusted domain but not an entry in /etc/passwd or NIS can use that account. All generic users have the same rights to generic users' account.

Scope ID

The NetBIOS scope ID feature provides a naming service for the NetBIOS over TCP/IP (NBT) module. This feature is not compatible with DNS. If you are not using DNS, NetBIOS scope ID allows you to limit traffic to only those machines with the same NetBIOS scope ID.

: NOTE: You should not enable scope ID for the filer unless you are already using it for other machines because you could unintentionally isolate the filer from clients that do not have the same NetBIOS scope ID.

You can use this feature to isolate a group of computers on a network (they would communicate only with the other computers with the identical NetBIOS ID) or to build virtual subnetworks (groups of machines that only "see" each other).

By default, the scope ID is a null string. If you want the filer to run in a NetBIOS scope, its scope ID must be set to the scope ID of that scope. The scope ID is a case-sensitive character string that is added to the end of a NetBIOS name.

Oplocks Enabled

Enabling Oplocks (opportunistic locking) allows the redirector on a client machine 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 to it) without regularly reminding the server that it needs access to the file in question. Oplocks are a significant performance enhancement, but have the potential to cause lost cached data on some networks with impaired reliability or latency, particularly wide-area networks. Oplocks are best used in an environment where most operations are reads rather than writes.

CIFS oplocks on the filer are enabled by default. You may want to disable CIFS oplocks under any of the following circumstances:

You are using a database application whose documentation recommends that oplocks be turned off.
You are handling critical data (you have good networks, but your company cannot afford data loss).
You have shared data environments, where oplocks would be granted, then broken on a regular basis, as would be typical in a database environment.
You are running across a WAN.
Your network is slow (for example, 10Base-T)
There is more than one hop between the client and the server (latency is poor).

NetApp Filer Configuration Help - 28 AUG 1997