SLAC AFS Users’ Guide

Last Revised: October, 2005


Contents

Introduction

About this Guide
Notation Used in this Guide
Prerequisites
What is AFS?
AFS Documentation

AFS Concepts

Authentication and Authorization
Tokens
Cells and filenames
Cache manager
Volumes

AFS Commands

Online AFS Command Help
Authentication Commands
Tokens
kinit and aklog
Changing Your Password
Authenticating Yourself to a Foreign Cell
Caution Against Listing Directory /afs
AFS File Protection: Access Control Lists and Protection Groups
A Typical SLAC Directory’s ACL
Directory and File Access Rights
Protection Groups
Groups You Create
AFS and the Permission Bits

AFS "Gotchas"

25-hour ticket expiration and not having a token
File Backup
Default ACL for Your AFS Home Directory
AFS Command Summary
ACL Commands
Online AFS Help Commands
Miscellaneous AFS Commands


Introduction

About this Guide

The Andrew File System (AFS)® was pioneered at Carnegie Mellon University, then supported and further developed as a product of the Transarc® Corporation (now IBM Pittsburgh Labs). IBM made a copy of the source available for community development and maintenance. They called the release OpenAFS. This guide is an introduction to OpenAFS as implemented at SLAC. It describes basic AFS concepts, defines terms, and shows how to use basic AFS commands. For an overview of the AFS filesystem as a whole, see SLAC Publication 11152 "AFS - A Secure Distributed File System".

If you are a UNIX user familiar with the NFS distributed file system, you will find AFS similar to NFS. AFS fits into the UNIX directory structure starting at the root (/), and this is a point of commonality between AFS and NFS. You will notice that you will be able to share files easily with a greater number of people including those from other institutions. Most application programs, text editors for example, will work as they did do in NFS (for exceptions, see Gotchas). However, differences that you will need to learn about include file sharing, authenticating yourself as an AFS user, and access control lists (ACLs), a mechanism which essentially replaces UNIX file permissions for controlling access to files.

Notation Used in this Guide

  • UNIX and AFS commands and subcommands are given in boldface typewriter font. For example,

tokens -help

  • Variables for which you must substitute a value are given in italic font. For example,

command subcommand -help

  • In examples of system/user interaction, system prompts and responses are given in regular typewriter font, while user input is in boldface typewriter font. For example,

ilse@odysseus $ kinit
Password:

  • File pathnames are listed in regular typewriter font. For example, /afs/slac/u/sf/ilse

Prerequisites

Familiarity with basic UNIX commands, such as cd (change directory), ls (list files), cp (copy file), and mv (move file), is assumed. For more information about UNIX, see UNIX at SLAC: Getting Started. A PDF version suitable for printing is also available

What is AFS?

The Andrew File System (AFS)® is a distributed file system that allows multiple machines to share access to a set of files in a uniform way. Files are stored on disk volumes of AFS server machines and accessed through the cache manager on AFS client machines. That means that files are stored on various machines connected to the network and sent to client machines, such as yours, when you want to access them. When a file is requested, AFS calls on the cache manager, your agent in accessing files stored in the AFS file space, to copy the portion of the file on which you are working to your workstation’s local disk. You don’t need to know on which server machine disk or volume the file you want is physically stored because AFS automatically finds it.

In many ways AFS is similar to NFS. Significant advantages of AFS include:

  • Direct access to files from other institutions running AFS, such as CERN and DESY.
  • Greater file security through a system of user authentication and file access permissions.
  • A snapshot of your home directory as of last midnight, from which you can recover a file you might accidentally erase today.
  • Improved network efficiency because the user works on a copy of the file until it is saved or closed rather than working on the file directly.
  • Home directories can be relocated between file servers to balance disk space usage without impact on owners. This helps ensure that the user won’t run out of disk space.
  • A much better mechanism to ensure that one user does not fill the disk space assigned to a whole group by giving each user his or her personal quota of disk space.

AFS Documentation

  • You may print a copy of this document directly from the browser in which you are viewing it.
  • Introduction to AFS contains links to other AFS resources.
  • For remote access to hosts at SLAC or elsewhere please use only the instructions in SLAC's guide to SSH usage in Secure Shell(SSH) at SLAC.
  • For changing passwords at SLAC, please use only the instructions supplied in this guide under Changing Your Password.
  • See also SLAC's policies on disk space and file backup.


AFS Concepts

Authentication and Authorization

AFS uses authentication and authorization as its primary security techniques to ensure that files are accessed only by authorized users. Whenever you login to UNIX, AFS checks the password you supply to make sure that you are who you say you are. If you are, AFS grants you a token and thereby authenticates you as a valid AFS user and logs you into UNIX.

Authorization determines what actions you may or may not perform on AFS files via the Access Control List (ACL) mechanism. This mechanism is based on authentication. AFS Access Control Lists which are discussed in detail in AFS File Protection: Access Control Lists and Protection Groups

Tokens

A token identifies you to AFS and is used as the AFS file server and the client machine work together to give you access to your files. Without it, your access will be limited. After you have established a UNIX account, whenever you login to UNIX you will automatically be given a kerberos ticket granting ticket, which is then used by the aklog command to obtain an AFS token. An AFS token is a special kind of kerberos service ticket. All SLAC unix machines are set up to run the aklog command as part of the login process, except under certain limited circumstances when issuing the ssh (secure shell for remote login to SLAC hosts) command.

You will have only one token and kerberos ticket on each machine at SLAC to which you log on, but may have additional tokens for foreign (that is, non-SLAC) machines that run AFS. A SLAC kerberos ticket expires after 25 hours of being continuously logged in to UNIX and may be renewed with the kinit command. The klistcommand shows whether or not you have a kerberos ticket.

A token, stored by the cache manager, is usually associated with one logon session on one host computer. If you’re using X Windows on a workstation, you need to authenticate once on that system. Then you can open as many windows with that AFS token as you want.

Many people wonder: when do I have a token? when don’t I? The answer is:

  • If a task has a token, all its subtasks will have a token.
  • At logon, everything you run on the computer to which you’ve logged on will share that token.
  • When you connect to another machine, you may or may not have a token. The most reliable way of finding out is to use the qtokencommand.

See Authentication_Commands for details on the commands tokens, kinit, and aklog.

Cells and filenames

AFS, like other UNIX file sytems, uses a hierarchical file structure or tree structure. Directories, which are files that contain other files instead of text or data, are organized like inverted trees. There is a single AFS tree for the whole world. The root directory in AFS is named /afs. All subdirectories of the root are called cells. Your directories and files will be subdirectories of the cell named /afs/slac.stanford.edu or more simply /afs/slac when referred to from a computer on the SLAC network.

Cells other than /afs/slac are known as foreign cells. Finding the names or locations of files in a foreign cell and then accessing them is rather like finding out the e-mail address of someone at another institution: contact the person with whom you want to share files and arrange for the appropriate file access controls and authentication. See Authentication_Commands for more information.

Files within AFS are named /afs/cellname/pathname. For example, my home directory is named:

/afs/slac/u/sf/ilse

"/u/sf/ilse" is a pointer to one’s home directory.

Cache manager

The cache manager is a process that requests data on your behalf from the server machines and stores a copy on your machine. You then work on the copy which reduces the number of network requests to the server. When you (or someone else) closes or saves the file, the changes to the file are transmitted to the server. There is one cache manager for each client machine, such as yours.

Volumes

All AFS data are stored in volumes, which are sections of AFS server disks. Each home directory is in a separate AFS volume. You need to be aware that each volume has a size limit called a quota. Therefore, each user has his or her personal quota of disk space. If you try to exceed the quota, which is given as a number of 1K blocks, AFS will respond with an error message. The command fs listquota tells you the size of your quota and how much of it you have used for your files and directories.

For various reasons we like to keep individual volumes relatively small. If your home directory is larger than the current volume limit, we prefer to split it into multiple volumes. Other than finding a convenient subset into which to split your subdirectories, this will have no effect on the use of your home directory.

If you fill up your initial quota, use the space request form to request an increase. See also the Web page on disk space policy.


AFS Commands

Online AFS Command Help

AFS has two general types of commands: file server commands (fs) and directory protection server commands (pts). There are also several authentication commands. fs and pts commands have various subcommands or operation_codes, which indicate the specific function of the command. Examples are: fs listacl, fs listquota, pts creategroup, pts delete, kinit, tokens.

The command:

command help

will list all the subcommands for the given command name (that is, fs and pts).

To get help on a specific subcommand, type:

command subcommand -help

Examples:

fs listacl -help
pts creategroup -help
tokens -help

The help entry lists the subcommand’s arguments in the prescribed order and its flags.

If you are trying to do something and don’t know the AFS command, try:

command apropos -topic "help-string"

where help-string is a topical key word. If help-string is more than one word, surround it with single or double quotes. If a match is found, a short description of any commands that match the help-string will be listed. Example:

ilse@odysseus $ fs apropos -topic "access control"
cleanacl: clean up access control list
copyacl: Copy access control list
listacl: list access control list

Authentication Commands

Each time you log on to UNIX at SLAC or when you give the command kinit and supply your unix password, you are authenticated as a valid user and the SLAC version of kinit runs aklog to obtain a token that identifies you to AFS. This token is used as your client machine works with the AFS file server to give you access to data. Remember that the token is good for 25 hours and then expires. When you try to perform an AFS function that needs authorization after your token has expired, AFS will give you an error message, such as "permission denied". Sometimes the text of the message might be more obscure, such as when the token expires while your program is executing. Give the kinit command to reauthenticate yourself.

tokens

To see the tokens you are currently holding, use the tokens command. For example:

ilse@odysseus $ tokens
Tokens held by the Cache Manager:

User's (AFS ID 1616) tokens for afs@slac.stanford.edu [Expires Jun 13 09:12]
--End of list—

If you do not have a token, you will see:

Tokens held by the Cache Manager:
--End of list--

or

User's tokens for afs@slac.stanford.edu [*EXPIRED*]

kinit and aklog

To obtain or renew an AFS token, enter the command: kinit. The dialog between you and the Kerberos KDC will look something like this:

ilse@odysseus $ kinit
Password:your unix password
ilse@odysseus $

If you want to destroy your token, use the unlogcommand.

Changing Your Password

Before changing your password, be sure to read and understand SLAC's guidelines on selecting secure passwords in Password Policy. Choose your new password based on the guidelines in Good Passwords. Then test it with the command /usr/local/bin/test_password before actually changing it following the directions in Changing Passwords.

Authenticating Yourself to a Foreign Cell

To access protected directories in a foreign cell:

  • You need an AFS account in the foreign cell.
  • You must be on the foreign cell directory’s access control list which is set by the owner of the directory.
  • You must authenticate yourself by getting a token for the foreign cell.

Here is an example in which user bobcook, who has an account in foreign cell ir.stanford.edu, gives the kinit command to obtain a kerberos ticket in that cell. With the kinit command he must identify himself (bobcook) and then specify the cell name in which he wants to be authenticated (ir.stanford.edu) using the aklog command.

$ kinit bobcook@IR.STANFORD.EDU
Password:

$ aklog -c IR.STANFORD.EDU

You can also use the full AFS pathname as an arguement to aklog

$ aklog /afs/ir.stanford.edu/users/b/o/bobcook

User bobcook gives the tokens command to verify that he has been authenticated. Note that he now has two tokens: one for the foreign cell and one for SLAC.

$ tokens
Tokens held by the Cache Manager:

User's (AFS ID 2336) tokens for afs@ir.stanford.edu [Expires Jun 29 11:34]
User's (AFS ID 1616) tokens for afs@slac.stanford.edu [Expires Jun 29 08:36]
--End of list—

A list of foreign cells known to your cache manager is given in the file /usr/vice/etc/CellServDB, which is updated occasionally based on the list maintained by the OpenAFS vendor.

Caution Against Listing Directory /afs

/afs contains the names of all AFS cells and it can take a very long time to collect them all. Therefore, don’t do cd /afs followed by ls -F, which is the default alias for ls, or an ls -l. Instead, do a /bin/ls.

AFS File Protection: Access Control Lists and Protection Groups

You may find that the most challenging aspect of learning AFS is how AFS file protection works. We recommend that you read this section to get a sense of what is different about AFS versus UNIX file protection, but not concern yourself about learning all the details at this time. Instead, come back to it as you find you need to understand them.

You can set and modify the ACL on your directories with the fs setacl command. ACLs control who may access files and directories. More specifically, they control who may see the names of files in a directory; read, write, delete, or move a file; add or copy new files or directories; and change the ACL.

A file uses the ACL of the directory in which it resides; that is, it does not have an ACL of its own. If you move a file to a new directory, it then assumes the ACL of the new directory. To protect a file as in the original directory you must move it to a like-restricted directory.

When you create a subdirectory, it assumes the ACL of the parent directory. However, you can modify the ACL for the subdirectory independently after you have created it. But, if the parent directory has a more restrictive ACL than the child, other users might be denied some of the access rights you granted them in the child. Always provide lookup access in the parent directory for someone who has permissions in the subdirectory.

AFS_and_the_Permission_Bits describe how permission bits work in AFS.

A Typical SLAC Directory’s ACL

To give you a sense of what an ACL looks like, let’s look at the one for a typical directory, /afs/slac/u/sf/ilse:

ilse@odysseus $ fs listacl /afs/slac/u/sf/ilse
Access list for /afs/slac/u/sf/ilse is

Normal rights:

system:slac rl

system:administrators rlidwka

system:authuser rl

ilse rlidwka

In this ACL:

  • system:slac includes any user of a host connected to the SLAC local area network. Permissions granted are read and lookup.
  • system:authuser includes any user authenticated in the SLAC cell (that is, the user must have an AFS token). Permissions granted are read and lookup.
  • system:administrators includes SLAC AFS system administrators. Permissions granted include read, lookup, insert, delete, write, lock, administer (that is, write, add, and delete files as well as change the ACL for the directory).
  • ilse The userid ilse is granted all permissions: read, lookup, insert, delete, write, lock, administer (that is, read, write, add, and delete files as well as change the ACL for the directory). For more about protection groups, see Protection_Groups

Directory and File Access Rights

Now that you have a general idea of ACLs, let’s look at them in detail. Unlike UNIX, which has only three basic rights that can be controlled, AFS has seven. These rights are subdivided into two groups: four directory access rights and three file access rights.

Directory access rights apply to the directory itself. They are: l (lookup), i (insert), d (delete), and a (administer).

l (lookup): allows the user to issue the UNIX ls command to list the names of the files and subdirectories in the directory; to examine the ACL for the directory and to access the directory’s subdirectories; and to look at the contents of the directory (i.e., with the UNIX comand ls -l).
i (insert): allows the user to add new files and subdirectories to the directory (either new or copies of files or subdirectories).
d (delete): allows the user to remove files and subdirectories or move them (where the user has insert rights).
a (administer): allows the user to change the ACL for the directory.

File access rights apply only to files in the directory. They are: r (read), w (write), and k (lock).

r (read): allows the user to read and copy the contents of the files.
w (write): allows the user to modify the contents of files in the directory and to change their permission bits with the chmod command.
k (lock): allows the user to run programs that need to flock files in the directory. When a program locks the file (flock), other users and/or programs cannot read or write the file. This is used to prevent read/write conflicts.

The following shorthand forms of multiple access rights are easier to use than the combinations they represent:

write: includes rlidwk (read, lookup, insert, delete,write, and lock)
read: includes rl (read and lookup)
all: includes rlidwka (read, lookup, insert, delete, write, lock, and administrator)
none: remove the entry

Protection Groups

A protection group is similar to a UNIX group but you establish and maintain the protection group yourself. Three system-wide protection groups, provided by AFS, are available by default. They are:

  • system:administrators – AFS system administrators
  • system:authuser – any user authenticated in the SLAC cell (that is, any user who has a SLAC token)
  • system:anyuser – all users anywhere in the world, authenticated or not

In addition, SLAC has defined the group system:slac to include any user of a host connected to the SLAC local area network. You can’t create other system-wide protection groups, but you can create groups yourself.

Groups You Create

You can create groups yourself (that is, the group will be owned by you) that are local to SLAC’s cell. You can add or delete individuals to the group as needed with pts commands. After you have created a group, you can place it on a directory’s ACL with any permissions you choose, and these then apply to all members of the group. Creating a group simply allows you to give the same access rights to several people all at once instead of for each person separately. For the same reason, it is also easier to change lots of ACLs later by just changing the group.

The example below shows how to create a group and add members. Use the commands pts adduser and pts removeuser to add and remove a user, and the commands pts delete and pts rename to delete a group and change a group name.

  1. Create a group named ilse:doc where ilse is the owner-name and doc is the actual name of the group (but both components constitute the group-name).

ilse@odysseus $ pts creategroup ilse:doc
group ilse:doc has id -352
Add users winters, jxh, and bebo as members of group ilse:doc

ilse@odysseus $ pts adduser -user winters jxh bebo -group ilse:doc

  1. Verify members of group ilse:doc

ilse@odysseus $ pts membership ilse:doc
Members of ilse:doc (id: -352) are:
winters
bebo
jxh

  1. Get additional information about group ilse:doc

ilse@odysseus $ pts examine ilse:doc
Name: ilse:doc, id: -352, owner: ilse, creator: ilse,
membership: 3, flags: S-M--, group quota: 0.
Establishing an Access Control List

The fs (file server) command is used to check and set the ACL for directories. Use the command fs listacl directory-name to check the current permissions for a directory.

This section will show you how to set and change the permissions in an ACL associated with individual users, system-wide protection groups, and for groups you have created. Remember: a directory’s ACL is inherited from the parent directory and remains that way until you modify it.

Copying ACLs Between Directories

To copy an ACL from one directory to one or more other directories, use the fs copyacl command. You can copy the ACL from any directory for which you have lookup right and copy it to any directory for which you have administer right.

In the example below, user ilse is in subdirectory telecom and copies the ACL from subdirectory personnel to subdirectory atom-comm.

  1. Check the existing ACL on subdirectories personnel and atom-comm:

ilse@odysseus $ fs listacl personnel atom-comm
Access list for personnel is
Normal rights:
system:slac l
system:administrators rlidwka
system:authuser l
ilse rlidwka

Access list for atom-comm is
Normal rights:
system:slac rl
system:administrators rlidwka
system:authuser rl
ilse rlidwka

  1. Copy the ACL from subdirectory personnel to subdirectory atom-comm.

ilse@odysseus $ fs copyacl -from personnel -to atom-comm

  1. Check the new ACL on subdirectory atom-comm.

ilse@odysseus $ fs listacl atom-comm
Access list for atom-comm is
Normal rights:
system:slac l
system:administrators rlidwka
system:authuser l
ilse rlidwka

ACLs for Individual Users

Suppose you have a directory whose contents you want to share with one other user. To give this person complete access to a certain directory and all the files within that directory, you must modify the ACL for the directory.

For example, to give user winters access to the directory called doc, user ilse would follow these steps:

  1. Make a directory named doc

ilse@odysseus $ mkdir doc

  1. Check the existing ACL on directory doc:

ilse@odysseus $ fs listacl doc
Access list for doc is
Normal rights:
system:slac rl
system:administrators rlidwka
system:authuser rl

ilse rlidwka

  1. Add permissions rlidwk (read, lookup, insert, delete, write, and lock) using the shorthand notation write.

ilse@odysseus $ fs setacl doc winters write

  1. Check the permissions again.

ilse@odysseus $ fs listacl doc
Access list for doc is
Normal rights:
system:slac rl
system:administrators rlidwka
system:authuser rl
winters rlidwk
ilse rlidwka

To remove an individual user’s permissions for a directory, use the same command you use to give access. none is the shorthand notations for no access permissions.

ilse@odysseus $ fs setacl doc winters none

To make sure that winters was removed:

ilse@odysseus $ fs listacl doc
Access list for doc is
Normal rights:
system:slac rl
system:administrators rlidwka
system:authuser rl

ilse rlidwka

ACLs for User-Created Protection Groups

To give access to a directory to a user-created group, use the same command, fs setacl, as for individuals. The example below illustrates how to give members of group ilse:doc all access rights using the shorthand notation all.

  1. Check the existing ACL on directory doc:

ilse@odysseus $ fs listacl doc
Access list for doc is
Normal rights:
system:slac rl
system:administrators rlidwka
system:authuser rl
ilse rlidwka

  1. Give members of group ilse:doc all access rights using the shorthand notation all:

ilse@odysseus $ fs setacl doc ilse:doc all

  1. Check the permissions again.

ilse@odysseus $ fs listacl doc
Access list for doc is
Normal rights:
ilse:doc rlidwka
system:slac rl
system:administrators rlidwka
system:authuser rl
ilse rlidwka

ACLs for System-wide Protection Groups

To change the access on a directory for a system-wide protection group, use the command fs setacl. Do not change the permissions for system:administrators. This example shows how to change the permissions of group system:authuser from lookup and read to lookup, read, and insert files for directory doc.

Any AFS-authenticated SLAC user can now insert files as well as lookup and read files in directory doc. (Remember to specify all rights, not just the one you want to add.)

ilse@odysseus $ fs setacl doc system:authuser lri

Make sure that the correct access rights were assigned.

ilse@odysseus $ fs listacl doc
Access list for doc is
Normal rights:
ilse:doc rlidwka
system:slac rl
system:administrators rlidwka
system:authuser rli
ilse rlidwka

To make the following directory with standard protection private:

ilse@odysseus $ fs listacl /afs/slac/u/sf/ilse
Access list for /afs/slac/u/sf/ilse is

Normal rights:

system:slac rl

system:administrators rlidwka

system:authuser rl

ilse rlidwka

give the command: fs setacl /afs/slac/u/sf/ilse system:slac none system:authuser none

The following shows the revised settings.

ilse@flora01 $ fs listacl /afs/slac/u/sf/ilse

Access list for /afs/slac/u/sf/ilse is

Normal rights:

system:administrators rlidwka

ilse rlidwka

AFS and the Permission Bits

If you are an experienced UNIX user, remember that the nine permission bits have very little meaning in AFS. However, AFS does not ignore them entirely. Specifically, AFS pays attentions to the mode bits as follows:

  • AFS always ignores the six group and other bits.
  • AFS ignores the three user bits on a directory.
  • User bits on a file interact with the ACL rights as follows:
    • If the r mode bit is present, that is, enabled, anyone with the read and lookup rights on the ACL of the file’s parent directory is allowed to read the file. If the r bit is absent, no one (including the owner) can read the file, no matter what permissions they have on the ACL.
    • If the w mode bit is present, anyone with the write and lookup rights on the ACL of the file’s parent directory can modify the file; if the w bit is off, no one can modify the file, not even the owner.
    • Although no ACL right directly corresponds to x, if the x bit is on, anyone with read and lookup rights on the ACL of the file’s parent directory can read the file to execute it.

In spite of the above, the UNIX chmod command still turns the file permission bits on and off.


AFS "Gotchas"

25-hour token expiration and not having a token

An AFS token expires roughly 25 hours after it was originally obtained. For normal AFS usage, these workarounds will suffice:

  • Logoff at the end of each day; or
  • renew your token once a day (e.g. when you reconnect in the morning).

Under the circumstances described below such workarounds will not be sufficient. There are certain environments in which a program will be executed and it will not have the token it needs to write into your AFS directory. So, how does a program get a token initially if it doesn’t have one and how does it renew it when necessary? Either adopt the solution described below or store your directories into which the cron job, .forward program, or interactive command needs to write in NFS.

Cron jobs. Submit the cron job (that is, a job in which the user requests UNIX to run a specified command according to a specified schedule) with the trscrontab command rather than the crontab command: trscrontab cron-job-name Give the command man trscrontab for more information.

Interactive jobs. In another command window on the same host enter the tokens command periodically to see whether your token will soon expire. If so, renew it with the kinit command. You can also use the krenew -t command to enable jobs to run for up to 7 days.

Mail. If you have a .forward file that executes a program which modifies files in your home directory, send email to unix-admin@slac.stanford.edu for assistance.

File Backup

See the web page UNIX Backup for more information.

Default ACL for Your AFS Home Directory

Your files and subdirectories in AFS are readable, but not writeable, unless explicitly changed by the owner. The default ACL for your AFS home directory will look something like this:

Normal rights:
system:slac rl
system:administrators rlidwka
system:authuser rl
ilse rlidwka

system:slac gives all users, AFS authenticated or not, of hosts connected to the SLAC network the privilege to issue the UNIX command ls to list the names of the files and subdirectories in your home directory; they may also read the data in the files of your home directory.

system:administrators that is, SCS AFS system administrators, have all access privileges (read, lookup, insert, delete, write, lock, and administer) to the subdirectories and files in your home directory. It is our policy that you not remove the system:administrators entry from any ACLs.

system:authuser gives any user authenticated in the SLAC cell the same privileges as those described for system:slac.

ilse is the owner of this home directory and has all access privileges as described for system:administrators.

AFS Command Summary

Commands summarized in this appendix are only those used in this Guide. See Introduction to AFS for a complete list of AFS commands and a full description of the command syntax. There you will find an explanation of when keywords in arguments (e.g., -dir) must be specified and when they can be omitted, and when multiple occurrences of arguments (e.g., -user username1 username2 ...) are allowed or prohibited.

Table 1. ACL Commands

Table 1 summarizes the commands used to make modifications to the ACL for a directory (and therefore to the files within the directory). Remember that you can give access to any groups (system-wide or groups that you or others have created) or you can give access to specific individuals.

Command Action
mkdir creates a new directory, which assumes the ACL of the parent directory
fs listacl directory lists the directory's ACL
fs setacl directory username accessrights gives permissions for a single user for a directory
fs copyacl -fromdir sourcedirectory -todir destinationdirectory copies the ACL from the source directory to the destination directory
fs listquota [-path <dir|file path>+] displays information about size and quota of volume containing each specified directory or file
pts creategroup owner:groupname creates a user-owned group
pts adduser username owner:groupname adds a user to a group
pts membership owner:groupname shows the members of the group
fs setacl directory owner:groupname accessrights establishes the access rights for a group to a directory
pts adduser -user user1 user2 . . . -group owner:groupname adds multiple users to a group
pts removeuser username owner:groupname removes a user from a group
pts delete owner:groupname deletes a group
fs setacl -dir directory1 directory 2 . . . -acl username accessrights1 group accessrights2 ... sets the ACL for multiple directories, where username is a group name or an individual user's name; ACLs set must be the same for all directories
pts examine owner:groupname gives additional information about a group

 

Table 2. Online AFS Help Commands

Command Action
command help lists all subcommands for the given command name (that is, fs and pts)
command subcommand -help gives help on specific subcommand (e.g., fs listacl -help)
command apropos -topic help-string gives one line summary of topic named by help-string, which must be in single or double quotes if it is more than one word.

 

Table 3. Miscellaneous AFS Commands

Command Action
kinit obtain or renew a kerberos ticket and AFS token
unlog destroy your token
tokens display current token(s)