General

It is possible to share/exchange data with members of other projects. There are several ways to achieve this.

DSS/DSA: Data Exchange via Globus Online

Can be used also for external users.

WORK: Make others User a Project collaborator (shared work folder)

Say, user A1 of project A wants access to data of user B2 in project B. There are two steps.

Add other user to the project, where the data are

1. user A1 needs to be a valid user-id in an active SuperMUC-NG project
2. the master user of project B opens a ticket via the LRZ ServiceDesk
   Please note that only a project's master user (PI/PC) can submit such requests.
3. After the request has been processed, A1 is a member of project B with an additional unix group <invited project-id>-d.
4. user A1 can check this via the groups or id command in the login shell.

B2 makes his WORK data accessible to A1

The procedure does not require root- or sudo-rights. One can change the ACL (access control list).

B2@sng-login> setfacl -m u:A1:rx  $WORK_<projectID>/../B2                # this makes B2's project WORK directory accessible (ls, cd) for A1

(Replace A1 and B2 just by real user IDs!)
Warning! All other directories in B2's project WORK are also per default readable, and accessible by virtue of the normal UNIX group permissions!

This usually already suffices that A1 can read or copy data of B2.

If, additionally, A1 is supposed to work within B2's WORK directory

(creating, modifying, deleting files and directories) say in sub-directory work_together, on needs to add some ACL entries to this specific directory, too. (This is, if ONLY A1 should be allowed to work in B2's directory!!)

B2@sng-login> setfacl -R -m u:A1:rwx -d -m u:A1:rwx -m u:$USER:rwx -d -m u:$USER:rwx work_together

Some explanation. According to setfacl's manpage, one can set recursively (-R) and per default (-d; meaning that the ACLs apply also for files and directories later created) user permissions, which are thus modified (-m).
u:UserID:rwx are plain to read. u = user, UserID is the user's ID who's permissions are to be set, rwx = Read,Write,eXecute.

Please note that B2 also must add him/herself to the ACLs. Otherwise, he/she cannot access the files/directory of A1 in work_together!

After changing the ACLs on a login node, these are valid also throughout the whole cluster!

More users can be added in this way, if necessary.

Questions

1. The question might appear why not to set B2's project WORK's ACL such that other groups, or users of other groups can access immediately (without adding A1 to project B)?
   From the two-step approach just described, it would be necessary that the ACL of the project B's top-level WORK directory is changed. But this, only root can do - and we refuse this.

2. How to remove ACLs again?

   B2@sng-login> setfacl -b $WORK_<projectID>           # or also with -R in order to do that recursively

Data Exchange via SCRATCH (sharing possible as for WORK)

Via UNIX permissions

userID@sng-login> chmod g+xr $SCRATCH           # and so for sub-directories

Caution! As all SuperMUC-NG users belong to group hpcusers, this procedure would actually make your SCRATCH directory world-readable! So, we generally discourage this!

Via ACLs

More fine-control you have using Access Control Lists (ACLs). Please look under B2 makes his WORK data accessible to A1 above for using getfacl/setfacl.

Data Exchange via /tmp on specific Login Node

On login nodes, /tmp is a hard disk on about 400 GB. One can copy data there and make them accessible to others. The same rules for UNIX or ACL permissions apply here.

Take care not to completely fill this directory!
Take care to clean this directory when you finished, in order release resources for other users!
We do not encourage here that users have a common WORK directory!!