It is possible to share/exchange data with members of other projects. There are several ways to achieve this.
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
- user A1 needs to be a valid user-id in an active SuperMUC-NG project
- 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.
- After the request has been processed, A1 is a member of project B with an additional unix group <invited project-id>-d.
- user A1 can check this via the
idcommand 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).
(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!!)
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
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.
- 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.
How to remove ACLs again?
Data Exchange via SCRATCH (sharing possible as for WORK)
Via UNIX permissions
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!
More fine-control you have using Access Control Lists (ACLs). Please look under B2 makes his WORK data accessible to A1 above for using
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!!