This tells how to create and maintain a shared directory on BioComp.
This is useful when at least two people in a group need to modify common
files in a project directory.

The default on BioComp is that users in a group can read each other's
files but not write them (users cannot read files in someone else's
group). It is fairly easy to implement shared directories by creating
subdirectories under a group member's username using UNIX protection
modes -- specifically the group mode -- to allow all group members to write
into the shared directory.

For example, to create a subdirectory
named project1 under your main directory that will allow read and write
access to all group members, type the bolded text (the '%' is the UNIX
shell prompt, and the '#' and everything after it is a comment; don't
type either):

    % mkdir project1		# create the subdirectory
    % chmod g+w project1	# add Write access for Group members to project1

If you (or someone else in your group) goes into the project1
subdirectory and creates a file named
test.seq, they should give the group write access
to the file with:

    % chmod g+w test.seq	# add Write access for Group members to test.seq

You'll find the ls -l command useful for examining
protection modes you've placed on files and directories. See the
ls man page for complete information.

It's important to realize that when you ask us to delete a username, we
delete all subdirectories and files stored under that username, including
shared directories. If you want a shared directory moved to some
other group member's username, let us know before you ask us to
delete the username.

If you're just going to have a few files in the shared directory, you're
done. Here is the man page for chmod
if you need more information about it.

Many files

If you're going to have many files in the shared directory, you
may tire of adding group write access to each file. Instead, you can have the
operating system automatically add this access when a file is created.
In addition to the first two commands above (mkdir and chmod),
you'll need to create a default Access Control List (ACL) for the
directory, like:

    % setfacl -m d:u::rwx,d:g::rwx,d:o:---,d:m:rwx project1

As you can see, the syntax is pretty unwieldy. setfacl is the program
that associates an ACL with a directory (or file). The -m option modifies
an existing ACL (or adds an ACL if it didn't exist). d stands for
default (it's called a default ACL because the protection specified will be
the default protection that newly created files will receive). u, g,

o, and m specify who the protections pertain to, and are short for
user, group, other, and mask, respectively.
In fact, the whole word can be used, like:

    % setfacl -m default:user::rwx,default:group::rwx,default:other:---,default:mask:rwx project1

r, w, and x indicate permissions and are short for read, write, and
execute.
In this case, only the abbreviation can be used. - indicates that
no permission is allowed.

With this command, we are telling the operating system that we want
each file that gets created in the project1 subdirectory to have
permissions that allow the user and group to be able to read and write
the file, but other users have no access. The execute access is used
when the file created is actually a subdirectory underneath project1
and allows the user and group to be able to list files in the subdirectory.

Note that the setfacl command not only has unwieldy syntax, but also
has lousy error messages. If you don't specify the syntax correctly,
you may get the message "Missing user/group owner, other, mask entry", or
worse yet, the command may silently fail.

For this reason, you may have a need to examine the ACL that you set on
a file; do this with:

    % getfacl project1

Here are the man pages for setfacl and
getfacl if you need more information.
Pay particular attention to the default ACLs for directories.
The setfacl command can do much more, like allowing another group
to read and/or write your files.

Note that
you can tell if a file or directory has an ACL associated with it by the
presence of a plus sign '+' immediately after the protections in an
ls -l listing.

If you want a shared subdirectory below project1, you may need to execute
a chmod for it, too. For example, to add the subdirectory
named subproject when you're in the project1 directory, use:

    % mkdir subproject		# create the subdirectory
    % chmod g+w subproject	# add Write access for Group members to subproject

Another way

It is worth mentioning that there's another approach to setting protections
on files in a shared directory: the umask command. You can use umask

to set the file mode protections on all newly created files and directories.
BioComp sets your umask to the octal code 027; the 0 means that user has
rwx access to files, the 2 means that group has rx access, and the 7 means
that other has no access. You'll probably need to see the
man page for umask for a deeper explanation of umask,
and the man page for chmod to figure
out what the mask code means.

A umask of 007 will enable group members to write files and directories. If
all users in a group use

    % umask 007			# allow user and group rwx access, other none

before creating files in a shared directory, then all files and subdirectories
will be writable by other group members. After you're done in the shared
directory, reset your umask back to the BioComp default with:

    % umask 027			# allow user rwx, group rx access, other none

Using umask is a little simpler than using ACLs (except that all group
members need to do it),
but a little more dangerous since someone may forget to change their umask
before working in other directories, thus giving group write access to files
they hadn't intended. It's also quite easy for the uninitiated to specify
a umask that would grant write access to all users on BioComp, not just
users in your group.

While you can put the umask command in your .cshrc script that gets
executed at login time, we don't recommend it since that will give
all users in your group write access to all of your files.