HP OpenVMS Systems

HP Advanced Server for OpenVMSServer
Administrator's Guide

Share permissions apply to network users, not OpenVMS users.
However, network user accounts can be host mapped to OpenVMS user
accounts, providing access to OpenVMS resources for network users based
on their OpenVMS user accounts.

Share permissions apply to all files and subdirectories created in
the shared directory. You can set access permissions for specific files
and subdirectories in the share. For more information, see
Section 4.3.5.3, Inheriting Permissions. Note that you can restrict user access to specific files
and subdirectories in a share (using the SET FILE command), or you can
restrict user access at the share level (using the ADD
SHARE/PERMISSIONS= or MODIFY SHARE/PERMISSIONS= command). For example,
you can restrict a user to READ access to the contents of a share by
modifying the permissions for that share. This would override any other
access previously granted the user to the contents of that share.

You can share an existing OpenVMS directory. When you share a
directory, you specify its location on the server, including the disk
device, the directory name, and the name for the share. The following
example shows how to share a directory on the server:

This command adds a directory share named RAINBOW for the directory
USER1:[SHARED]. Files created in this directory will be RMS
stream-format files. Because the /PERMISSIONS qualifier is not included
on the command line, the new share is available to all network users.

The Advanced Server allows you to set up personal shares, which are
typically used for sharing a user's OpenVMS login directory. Personal
shares are unique in that they are hidden (they will not appear in the
list of shares users can display, such as in Network Neighborhood), but
the names of personal shares do not end with a dollar sign ($). Thus,
when users want to map a drive to their OpenVMS login directory, they
specify a personal share name (typically the same as their user name)
without having to include a dollar sign in the share name.

Note

Users cannot specify personal shares in the UNC path when connecting to
or listing resources. To access such a file or run an application from
the personal share, users must specify the device associated with the
share.

A personal share typically points to the root directory of a user's
OpenVMS account. For example, network user SCARECROW has a personal
share that is mapped to the OpenVMS directory [STRAWMAN] on server
TINMAN. If you display the personal shares on TINMAN, the following
information appears:

STRAWMAN, the host mapped OpenVMS account, has a login directory
defined in the UAF record; for example: DUA1:[000000]STRAWMAN.DIR, or
DUA1:[STRAWMAN]. You can use the AUTHORIZE utility to display a
system's UAF records. For example:

After the personal share is created, you can set up the associated
directory as the user's home directory. The home directory contains
files and programs for the user, and is automatically accessible when
the user logs on to the network. For information about setting up home
directories, see Section 3.1.10, Specifying Home Directories.

You may need to stop sharing a directory when the directory is no
longer being used and you want to delete it; for example, when a
project requiring the use of shared files is completed. Advise users
when you are planning to stop sharing a directory.

For example, to stop sharing the directory GREATOZ, use the ADMINISTER
command REMOVE SHARE, as follows:

This example removes the share named GREATOZ from the server named
TINMAN; no confirmation is required. When you stop sharing a directory,
the share name is removed from the share database and no longer appears
on the list of available shares. However, the directory and its files
are not deleted.

You can use the SHOW SHARES command to display the shares provided by a
server and to see which shares are available to the network. Before
sharing a new directory from the server, first check which shares are
currently available.

The following example shows how to display the shared directories for
your server:

Users and groups can be granted or denied access to specific files and
subdirectories in a shared directory. A user denied access to a file or
directory, either individually or as a member of a group, can connect
to the share but cannot perform any operations with the files and
directories in the share. You can grant specific unique access
permissions for files and directories in shares that users can access.
Once a user connects to the resource, the file and directory access
permissions control the operations that the user can perform. For
information about specifying share permissions, see Section 4.3.2.2, Planning Share Permissions.

You can enable users to set access permissions on their own files and
directories. These users can then control whether other users can read,
write, or modify files in that directory. To enable users to set access
permissions, give them full control using the SET FILE command.

By default, anyone with a valid network user name and password can log
on to a server and connect to a share on that server. However, a user
must have the requisite permissions to access the directories and files
in the share. You use the SET FILE/PERMISSIONS command to set
permissions on a shared directory. You may need to change access
permissions if users cannot access the directories or files they need,
or if unauthorized users can access them. For information about how a
file or directory that does not have explicit permissions inherits the
permissions, see Section 4.1.3.1, Inheritance of Directory Permissions, and Section 4.3.5.3, Inheriting Permissions.

Permissions for disk resources are stored on the disk with each
resource as an OpenVMS access control list (ACL). Thus, resource
permissions are backed up by the OpenVMS Backup utility.

As you create subdirectories and files in shared directories that have
existing permissions, those permissions are automatically propagated to
the new subdirectories and files. (This assumes the default for the
STORE_SECURITY_ACES is in effect; see Section 4.1.3.6, Streamlining Security Information Storage and Lookups,
for more information.) However, if you decide to share a directory that
contains existing subdirectories and files, the permissions you assign
to the new share are not propagated to its subdirectories and files.
You can either explicitly set permissions for each subdirectory and
file, or you allow their permissions to be inherited.

When sharing a directory on a server, you specify the name of the
groups and users who can access the share, its subdirectories, and its
files, and the permissions each group or user has for the share. After
the share has been created, you can modify the permissions on the files
and directories in the share. The following example shows how to use
the SET FILE/PERMISSIONS command to modify permissions. In this
example, the command specifies the access permissions for all files
with the .C extension in the directory CURTAIN in share GREATOZ.