Sharing Within A Cluster

From UFRC
Revision as of 18:59, 7 February 2023 by Moskalenko (talk | contribs)
Jump to navigation Jump to search

Allow users to share files between themselves on the cluster. For file transfer outside of the cluster see Transfer Data

Note that if making a copy of the data is sufficient the easiest approach is to set up a Globus collection on a directory and give the other party read access to the collection.

Sharing to the same group

  • Note that all groups should have a "share" directory within their storage trees. This is the most appropriate way to share data and software among group members.

For a group that wants several people to work on the same data it may be useful to use a combination of directory and file permissions and 'umask' settings that affect all newly created files.

  • To make the data accessible to all group members, but not any other users outside of the group add the following line to the shell initialization script '~/.bashrc' in each group member's home directory:
umask 007

That umask setting will cause every newly created file to have "-rw-rw----" permissions and every new directory to have "-rwxrwx---" permissions giving full access to the user and the group, but not to anyone else.

  • To change permissions on an existing directory tree to correspond to the above set change to the directory above the one you'd like to start from and run
find DIRECTORY -type d -exec chmod 770 {} \;
find DIRECTORY -type f -exec chmod 660 {} \;

where 'DIRECTORY' is the name of the topmost directory in the tree you want to change permissions on. Note that the user who runs the above commands must be the current owner of the directory tree. The commands may take a while to run if the directory tree is large. If the directory tree has mixed ownership open a support request and we'll help.

Sharing to different groups

Sharing Data

For data that doesn't change very frequently the easiest method is to share a directory tree with Globus by creating a shared collection and giving read, write, or read/write permissions to the user(s) from another group. They will be able to transfer/sync the files to their own directory tree.

Collaborative Work

Project Group

If members of multiple groups need to work on a project together the sponsor(s) of the involved group(s) can allocate some of their Blue Storage investments to create a new project directory tree in /blue. Open a support request and we'll

  • Set up a new project group
  • Allocate a share of blue storage investment(s) to the project group.
  • Add project members from all involved groups to the project group.

Note that allocating computational resources to the project group is unnecessary in most cases as all project members will still be able to use their own groups' computational resources for analyses.

Secondary Group

If the hosting sponsor is willing a user or a sponsor can open a support request to request adding a secondary user to a group. If a request is opened by a user we'll ask the hosting group's sponsor for confirmation before making changes.

Note: that user will have the same level of access to storage and computational resources of their secondary group as the primary users of that group.

Custom Access

If it is desired to give a certain person or persons access to some directories or files in another group's storage and the above options are not acceptable it may be possible to set up a filesystem ACL i.e. additional custom permissions set on top of Linux filesystem permissions. There are many pitfalls and limitations of this approach, so we don't recommend it as the first choice. However, on request and the responsibility of the group's sponsor we can help the group determine and set ACL or ACLs. See ACLs for more details.