Advanced File Sharing Concepts¶
Changing file permissions is the responsibility of the data owner¶
Oak administrators generally defer permission changes to data owners. If the data owner is not able to update permissions, we can transfer ownership to a new user with PI approval. Once that is completed, the new owner can update permissions as they see fit.
Sharing Oak Data¶
The simplest way to collaborate with other people is to add them to your Oak group, though this gives them access to all contents in a given Oak group. If that’s not desirable, please read on.
Sharing a specific folder with a user outside of your Oak group¶
If you want to share a single directory and its contents with another Oak user, but that person isn’t a part of your Oak group, you can follow the steps outlined below.
Let’s say that your Oak group is
Suppose you have a folder in the following location:
If you want to share the folder
share with another user,
jstanford, giving them read, write, and execute permissions, you would need to run three commands:
First, let’s give them
setfacl -m u:jstanford:rwx /oak/stanford/scg/lab_ruthm/project/data/share
This alone won’t do
jstanford any good until they have permission to pass through the
data folders along the way. To do that, you will need to run a variation of the first command on each path component (folder) along the way to give you traversal permissions.
setfacl -m u:jstanford:--X /oak/stanford/scg/lab_ruthm/project/data/
setfacl -m u:jstanford:--X /oak/stanford/scg/lab_ruthm/project/
Traversal is a special permission that can only apply to folders. It allows you to go beyond that directory to anything you have access to and nothing more. Sometimes people use
read for this purpose, but that can be too permissive, so Traversal is a more precise way to go about it.
x does not always mean
When a file has a permission `x`, it means it is executable. When a folder has a permission `x`, it represents traversal.
We haven’t added traversal to
/oak/stanford/scg/lab_ruthm/ in this example yet, and that’s because the last part of this sequence is a decision for your Oak PI on how to allow external collaboration on their Oak space. There are two ways to approach this.
The PI can either:
- Allow members of their Oak group to share data with any other Oak user (add
Xto /oak/stanford/scg/lab_PI_GROUP/ )
- This configuration exists across other PI groups in Sherlock and Oak, and is not unheard of.
- Allowing traversal alone will not allow others to read what is in their space. It effectively allows their lab members to share file paths with other Oak users who are not members of their Oak workgroup.
- This option is much easier to maintain rather than a specific user ACL.
- This is the preferred option our most senior system administrators recommend because it is easy to manage and easier to interpret for users.
- Allowing Traversal for ONLY one individual
- Essentially a one-time exception to allow this single user to traverse a file path beyond your group folder.
- If data is shared with another external user in the future, a separate request to SRCC must be made to explicitly allow that individual.
- Difficult to manage over time as someone in the lab will have to remember to ask SRCC to remove this at some point in the future. Removing permission also requires explicit PI authorization.
- This route is not a typical use case, so it is not usually recommended by SRCC sysadmins, though we can do this if it’s what you would prefer.
Either way, the PI must send an email approval for one of these options. Because each
/oak/stanford/scg/lab_PI_NAME/ folder is owned by the
root user, only SRCC administrators can make this change.
For help with file sharing on Oak, please email us at email@example.com.