Skip to content

Advanced File Sharing Concepts#

Sharing Oak Data#

The simplest way to collaborate with other people is to add them to your Oak workgroup, which gives them access to all contents in a given Oak group. If that's not desirable, please read on.

Sharing a specific directory 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.

To change file permissions, you must be the owner of the file

To determine whether you own a file, you can use the getfacl command.

From a Sherlock or SCG node, you can run $ getfacl /oak/stanford/groups/$PI_SUNET/path/to/file. This will return results that include a line '# owner:' followed by the owner's SUNet ID or User ID (UID).

Let's say your Oak group is /oak/stanford/groups/ruthm.

Suppose you have a directory in the following location: /oak/stanford/groups/ruthm/results/data/share.

If you want to share the directory share with another user, jstanford, giving them read, write, and execute permissions, you would need to run three commands:

First, let's provide them with rwx on share:

setfacl -m u:jstanford:rwx /oak/stanford/groups/ruthm/results/data/share

This change alone will only do jstanford any good once they have permission to pass through the ruthm, results, and data directories along the way. To provide this access, you will need to run a variation of the first command on each path component in the directory hirearchy to give you traversal permissions. 

setfacl -m u:jstanford:--X /oak/stanford/groups/ruthm/results/data/
setfacl -m u:jstanford:--X /oak/stanford/groups/ruthm/results/

Traversal is a special permission that can only apply to directories. It allows you to go beyond a directory to anything can access and nothing more. Sometimes, people use read for this purpose, but that may be too permissive in certain scenarios. Traversal offers a more precise way to share files.

x does not always mean execute!

When a file has a permission x, it means it is executable. When a directory has a permission x, it represents traversal.

A directory is like a door to the files and directories contained within. Traversal governs whether that 'door' is locked or not. The read permission manages what you see once the door opens. It is possible to allow someone to traverse many levels of a directory hirearchy while only allowing them to read specific content along the way.

Oak PIs decide who their group members are allowed to share with#

We haven't added traversal to the root of the Oak directory (/oak/stanford/groups/ruthm/) in this example so far, and that's because the last part of this sequence is a decision for the Oak PI on how to allow external collaboration on their Oak space.

The PI can authorize SRCC to enable sharing in their Oak space in one of two ways:

  • Allow members of their Oak group to share data with any other Oak user (add x to /oak/stanford/groups/$PI_SUNET )

    • 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 option we generally recommend because it is simple to manage and easier to interpret.


  • Allow traversal for a specific user or users.

    • Essentially, it is a one-time exception allowing explicitly named users access to traverse a file path beyond your group directory.
    • To share with other external users in the future, a separate request to SRCC must be made to allow that individual explicitly.
    • This can be more 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, 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/group/$PI_SUNET/ directory is owned by the root user, only SRCC administrators can make this change.

For help with file sharing on Oak, please email us at srcc-support@stanford.edu.