4    Disk Shares

The ASU server enables you to share UNIX directories as disk shares, then make those shares available to domain user accounts and groups. For example, when a directory is shared, authorized Windows users can make connections from their workstations to the share and access its files.

The only way to make a file accessible over the network is to share one of its parent directories as disk share. When you share a directory, Windows users can gain access to that directory, the files in it, and all of the subdirectories and their contents. Every point on the directory tree below the shared directory is available to users. You use Windows NT permissions to manage user access to the share and Windows NT file system (NTFS) and Tru64 UNIX permissions to manage user access to files and directories in shares.

This chapter discusses the following topics:

See the ASU Installation and Administration Guide for information on creating disk shares.

4.1    Disk Share Permissions

Every file and directory has an owner. The owner controls how permissions are set on the file or directory and can grant permissions to others. When a file or directory is created, the person creating the file or directory automatically becomes its owner. By default, a user must pass the following levels of security before they can access a file or directory in a disk share:

The following steps describe how permissions are checked when a user maps a drive to a disk share and requests access to a file in the disk share:

  1. From a system running the Windows operating system software, a user connects to a disk share. By default, all users have permission to connect to a share.

    The user's Windows system provides the ASU server with authentication information about the user, including the user's name, password, and security ID.

  2. The ASU server checks the user's name and password in the directory database.

    If the ASU server authenticates the user's information, a unique ID is assigned to the user's Windows system. The Windows system must present this ID when the user makes subsequent requests to shares.

  3. The user attempts to open a file in the share.

    The ASU lmx.srv process services the user's request. Normally, the lmx.srv process runs as root, the highest Tru64 UNIX privilege level.

  4. The lmx.srv process determines if the user has the correct Windows NT share permissions to access the share.

    If the permissions are not correct, the lmx.srv returns an access denied error to the Windows system.

  5. The lmx.srv process determines if the user has the correct NTFS permissions to access the file in the share.

    If the permissions are not correct, the lmx.srv process returns an access denied error to the Windows system.

  6. The lmx.srv process determines Tru64 UNIX access based on the mapping of the domain user account to a Tru64 UNIX user account.

  7. The lmx.srv process changes its effective user ID from root to the ID of the corresponding Tru64 UNIX account and tries to open the file.

  8. The Tru64 UNIX operating system determines if the user has the correct Tru64 UNIX permissions.

    If the permissions are correct, the file is opened. If the permissions are not correct, the lmx.srv process returns an access denied error to the Windows system.

4.1.1    Windows NT Permissions

Table 4-1 describes the Windows NT permissions that you can set for a disk share.

Table 4-1:  Windows NT Permissions

Permission Purpose

No Access

Prevents a user from accessing the disk share

Read

Allows:

  • View file and subdirectory names

  • Move to subdirectories

  • View data in files

  • Run application files

Change

Allows everything Read allows, plus:

  • Add files and subdirectories

  • Change data in files

  • Delete subdirectories and files

Full Control

Allows everything Read and Change allows, plus:

  • Change Windows NT and NTFS permissions

  • Set Windows NT and NTFS permission to take ownership of files and subdirectories

The default is to grant the Everyone group Full Control permission to new disk shares.

Note

Permissions are cumulative except that the No Access permission overrides all other permissions. For example, if the Coworkers group has Write permission for a file while the Finance group has only Read permission and John is a member of both groups, John will be granted Read and Write permissions. However, if you change the Finance group's permission for the file to No Access, John will not be able to use the file even though he is a member of a group that has write access to the file.

See the ASU Installation and Administration Guide for information on setting Windows NT permissions.

4.1.2    Windows NTFS Permissions

There is a standard set of NTFS permissions that you can set or you can customize NTFS permissions to meet you needs. Table 4-2 describes the standard Windows NTFS permissions that you can set. Table 4-3 describes the custom Windows NTFS permissions that you can set.

Table 4-2:  NTFS Standard Permissions

Permission For File For Directory
Add Cannot read the contents of current files, change them, or list the files Can add files to the directory
AddRead Can read and execute files but cannot change files Can read, write, and execute files in the directory
Change Can change the contents of current files Can read and add files
Full control Can read and change files, add new ones, change permissions for files, and take ownership of file Change permissions for the directory and take ownership of the directory
NoAccess Not applicable Cannot access the directory in any way, even if the user is a member of a group that has been granted access to the directory
List Cannot access files List the files and subdirectories in this directory and change to a subdirectory of this directory
Read Can read the contents of files and run applications Allows viewing the names of files and subdirectories

Table 4-3:  NTFS Custom Permissions

Permission For File For Directory
Change Permissions (p) Allows changing the file's permissions Allows changing the directory's permissions
Delete (d) Allows deleting the file Allows deleting the directory
Execute (x) Allows running the file if it is a program Allows changing to subdirectories
Read (r) Allows viewing the file's data Allows viewing the names of files and subdirectories
Take Ownership (o) Allows taking ownership of the file Allows taking ownership of the directory
Write (w) Allows changing the file's data Allows adding files and subdirectories

NTFS displays two sets of permissions: the permissions set on the directory and the permissions set on files in the directory. For example, the following output would display if you set AddRead permission on a share for a user name peter. The (RWX) means Read, Write, and Execute permissions on the directory, and (RX) means Read and Execute permission on its files.

Resource:    c:\usr\net\servers\lanman\shares\share1
Owner:       server1.dom\Administrators
Name:                               Permissions:
-------------------------------------------------------------------------------
*Administrators                     FullControl(All)(All)
*Everyone                           Read(RX)(RX)
peter                               AddRead(RWX)(RX)

The ASU server displays groups by preceding the group name with an asterisk ( * ).

NTFS Permissions on files in a directory can be set to NotSpecified. This means that no permissions will be set for that user or group on the files in the directory or that are created after setting this permission. A user or group cannot access files in the directory until permission is granted.

When you set permissions on a directory, you can use the Creator Owner special group to allow users to control only the subdirectories and files that they create within the directory. Permissions set on the Creator Owner group are transferred to the user who creates a directory or file within the directory. To change permissions on the directory, you must be the owner of the directory or have been granted permission to do so by the owner.

Note

By default, Windows NTFS permissions grant read and execute permission to the Everyone group, of which every domain user account is a member. You must grant Windows NTFS write permission to the domain user account or group that will write files to the disk share.

See the ASU Installation and Administration Guide for information on setting Windows NTFS permissions.

4.1.3    Tru64 UNIX Permissions

By default, subdirectories created in a disk share have the following Tru64 UNIX permissions:

By default, files created in a disk share have the following Tru64 UNIX permissions:

See System Administration for information on setting Tru64 UNIX permissions.

4.1.4    Disk Share Permission Considerations

The user who creates a file or directory is the owner of that file or directory; however, users who are members of the Administrators group always can take ownership of a file or directory. The owner can control access to the file or directory by changing the permissions set on it. When changing the permissions on a directory, you choose whether to apply the changes to all files and subdirectories in the directory. Users cannot use a directory or file unless they have been granted permission to do so or belong to a group that has permission to do so. Each permission that you set specifies the access that a group or user can have to the directory or file. For example, when you set Read permission for the group called Coworkers on the file MY_IDEAS.DOC, the users in the Coworkers group can display the file's data and attributes, but they cannot change the file or delete it.

The easiest way to administer security is by setting permissions for groups, not individual users. Typically, a user needs access to many files. If the user is a member of a group that has access to the files, you can terminate the user's access by removing the user from the group rather than changing the permissions on each of the files. Note that setting permission for an individual user does not override the access granted to the user through groups to which the user belongs.

When copying files or directories, the current security permissions, ownership, and auditing information is discarded. The copied files or directories inherit a new set of permissions from the directory into which they are copied and the person copying the file or directory is the owner.

4.2    Directory Replication

One of the helpful tasks that the ASU server performs is keeping shared resources current, which can be accomplished by using the Replicator service. If you have directories and files that you want to distribute to many users, you can use the Replicator service to set up and maintain identical directory trees on controllers and workstations to balance the work among them.

The Replicator service requires that you configure one computer as an export server, place the master copies of directories and files on the export server, and configure other computers as import computers. You only need to create one copy of a directory or file on the export server and import computers automatically receive an identical copy of the directory or file. When you update a directory or file in the directory tree on an export server, the updated directory or file is copied automatically to all the import computers.

Every export server maintains a list of computers to which directories and files are exported, and each import computer maintains a list of computers from which directories and files are imported. Export servers can export to domain names and import computers can import from those domain names. This is a convenient way to set up directory replication for many computers; each export server and import computer needs to specify only a few domain names for export or import rather than a long list of computer names.

You can configure an ASU server as an export server and as an import computer.

4.2.1    Directory Replication Overview

The Replicator service must be running on each export server and import computer. The Replicator service sends updated directories and files on each export server to import computers that participates in replication. The Replicator service on each computer logs on to the same user account, which you create for this purpose.

A domain can have multiple export servers; however, to ensure the integrity of replicated information, do not export duplicate subdirectories. The /usr/net/servers/lanman/shares/asu/repl/export directory is the default export path on the export server and should contain the directories and files to be replicated. When changes are saved to subdirectories and files in this directory, the subdirectories and files automatically replace the existing subdirectories and files on all of the import computers.

You also can specify whether the export server sends changes as they occur or wait until an export subdirectory has been stable for two minutes. This prevents exporting partially changed subdirectory trees. In addition, you can lock an export or import directory. Changes to a locked directory are not exported or imported until you unlock the directory.

On the export server, you specify the import computers that are to receive copies of the directories and files that the export server is exporting. An export server has only one list of import computers to which it replicates. All directories to be replicated are exported as subdirectories in the export path. Subdirectories created in the export path and files in those subdirectories are exported automatically. Export servers can replicate any number of subdirectories (limited only by available memory) with each exported subdirectory having up to 32 subdirectory levels in its tree.

Imported subdirectories and their files are automatically placed in the /usr/net/servers/lanman/shares/asu/repl/import directory. You do not need to create import subdirectories. They are created automatically when directory replication occurs.

4.2.2    Configuring Directory Replication

Follow these steps to configure directory replication on export servers and import computers:

  1. Create a domain user account for the Replicator service to use to log on. Be sure the user account has the Password Never Expires option selected and all logon hours allowed.

    See the ASU Installation and Administration Guide for information about creating domain user accounts.

  2. For each computer that will be configured as an export server, use the Server Manager, select Properties from the Computer menu, then select Replication and configure:

    See Server Manager help for more information on configuring the Replicator service.

  3. On a computer that will be configured as an export server, create the directories to be exported. They must be subdirectories of the replication export path, /usr/net/servers/lanman/shares/asu/repl/export.

  4. For each computer that will be configured as an import computer, use the Server Manager, select Properties from the Computer menu, then select Replication and configure:

    See Server Manager Help for more information on configuring the Replicator service.

    You can set up an export server to replicate a directory tree to itself (from its export directory to its import directory). This replication can provide a local backup of the files, or you can use the import version of these files as another source for users to access, while preserving the export version of the files as a source master.

4.2.3    Managing Export Subdirectories

Use the Server Manager to manage exported subdirectories by clicking on Manage under Export Directories in the Directory Replication dialog box. Aspects of directory replication that you can manage include the following:

4.2.4    Managing Import Subdirectories

You can use locks to prevent imports to subdirectories on an import computer. Locking a subdirectory on an import computer prevents the replication of subdirectories to that computer until the lock is removed. Locking a subdirectory on an import computer affects replication to only that computer, not to other import computers.

Use the Server Manager to manage locks on subdirectories and also view the status of each subdirectory by clicking on Manage under Import Directories in the Directory Replication dialog box.

The Status column can have one of the following four entries:

The Last Update column shows the date and time of the latest change to the import subdirectory or to any of its subdirectories.

See To View a List of, or Manage Locks for, Import Subdirectories in Server Manager Help for more information on managing locks.

4.2.5    Replicating Logon Scripts

Logon scripts are files that can be assigned to domain user accounts. Every time a user logs on, the assigned logon script runs. Logon scripts allow administrators to affect domain users' environments without managing every aspect of it. When a controller processes a logon request, the system locates the logon script that you specified for the user. See Section 3.1.2 for more information on assigning logon scripts.

If you use logon scripts in a domain that has a PDC and at least one BDC, you should replicate logon scripts among the domain controllers. Master copies of every logon script for a domain should be stored in the replication export directory on one server, which can be the PDC but does not need to be. Copies of the logon scripts should be replicated to every controller that participates in authenticating logons for the domain. If this is done, only one copy of each logon script will need to be maintained and every controller that participates in authenticating domain logons will have identical copies of every user logon script.

By default, the ASU server exports logon scripts from the /usr/net/servers/lanman/shares/asu/repl/export/scripts directory to the /usr/net/servers/lanman/shares/asu/repl/import/scripts directory on import computers.

4.2.6    Using Directory Replication

Suppose you manage an environment in which you have a domain that contains two directory trees that you want to replicate: one for logon scripts and one for other data. The computers that need to import the two directory trees are different. Four domain controllers need the logon scripts; however, only two domain controllers and two Windows NT Servers need to import the other data.

The best solution is to set up two export servers: one for the scripts directory tree and one for the data directory tree. Remember that a single export server has only one list of import computers to which it replicates. If you set up a single export server for the two directories, it exports both directory trees to all import computers even though not all import computers use both directory trees.

4.2.7    Replication Troubleshooting Tips

Directory replication problems can have a variety of causes. When the Replicator service generates an error, it is displayed in the Event Viewer. The Event Viewer contains information about the Status column in the Manage Import Directories dialog box and information about messages that appear while you are configuring directory replication.

See Chapter 6 for more information about the Event Viewer.

4.2.7.1    Access Denied

If the Event Viewer shows access denied errors for the Replicator service, be sure that:

4.2.7.2    Exporting to Specific Computers

Be sure to specify export servers and import computers in the To List and From List in the Directory Replication dialog box. If you fail to do so, exporting will occur to all import computers in the local domain, and importing will occur from all export servers in the local domain.

An export server has only one list of import computers to which it replicates. All import computers in that list receive all the exported directories and files. You cannot be selective about which import computer receives which export file or directory. For this level of control, you must use multiple export servers and configure them accordingly.

4.2.7.3    Lost Permissions in Import Directory

Do not use the Explorer or File Manager to examine permissions in the /usr/net/servers/lanman/shares/asu/repl/import directory. If you do, special permissions initially set there might be lost. These initial permissions enable directory replication to work; you do not need to change them.

4.2.7.4    Replication to a Domain Name Over a WAN Link

Directory replication to a domain name does not always succeed when some or all import computers are located across a wide area network (WAN) bridge from an export server. When adding names to the export To List on an export server, and when adding names to the import From List on an import computer, specify the computer names (instead of or in addition to specifying the domain name) for those computers separated by a WAN bridge.

4.3    Managing Disk Share Usage

Table 4-4 describes the disk share usage information that you can display by using the Properties option in the Server Manager or net commands.

Table 4-4:  Disk Share Usage

Option Description net Command
Sessions The users who are remotely connected to the computer and the shares to which they are connected. # net session
Open Files The number of shared resources opened on the computer. # net file
File Locks The number of file locks on open resources of the computer. # net file
Open Named Pipes The number of named pipes open on the computer. In some cases, a print job is monitored as an open named pipe. # net file

See the ASU Installation and Administration Guide and the net help command for more information on net commands.

4.3.1    Disconnecting Users From Shares

You can use the Server Manager or the net commands to disconnect one or all users from a share. To prevent data loss, always warn users before disconnecting them. See Section 4.3.2 for more information on sending messages.

To use the net command to disconnect all users, enter the following command:

# net session /delete

Follow these steps to use the Server Manager disconnect one or all users from shares:

  1. If you want to disconnect users who are connected to shares on a remote controller, choose Select Domain to and enter the domain for the controller. While you are administering another computer remotely, your user account is listed as a user connected to the IPC$ resource. It cannot be disconnected.

  2. From the Computer menu, select Properties.

    A Properties dialog box is displayed.

  3. Select:

4.3.2    Sending a Message to Users

You can send a message to all users who are connected to shares by using the Send Message command on the Computer menu in Server Manager. For example, you can do this before you disconnect one or more users or before you stop the Server service on a controller.

For a message to be sent and received, the Messenger service must be running on the computer sending the message and on the computers receiving the message.

See Sending a Message to Connected Users in Server Manager Help for more information about sending messages.