Data sharing
Sometimes two or more MetaCentrum users need to work on the same files and directories.
Since setting whole home
directory as accessible to anyone is considered a security vulnerability (due to the possibility to manipulate sensitive files like .k5login, .bashrc by a third party) such settings are discouraged and are automatically reset.
To make sharing of data possible and at the time safe, we offer two options varying slightly with respect to the expected volume of shared data, namely:
- sharing based on a group (moderate amount of data)
- sharing based on project directory (large amount of data)
What is the difference between *group* and *project directory*?
With project directory the data are not accounted to users’ quotas, therefore project directory is best suited for sharing a large volume of data and/or large amount of files which could otherwise fill individual users’ quotas easily.
On the other hand, in sharing based on group the data are accounted to users quotas based on the ownership of individual files.
Group setup
- Choose a name for your group and ask us at meta@cesnet.cz to create it
- Include a list of members of the group and choose at least one group manager
The group manager can later add/remove members of this group through the Perun interface.
After the group is created, you will be notified.
Finally, create a directory dedicated for shared data, e.g. mkdir /storage/CITY/home/USER/shared
.
Note
This directory for shared data needs to be created by the user, and also the name of it can be different.
Project directory setup
- Choose a name for your group and ask us at meta@cesnet.cz to create it together with a project directory
- Include list of members of the group and choose at least one group manager
The group manager can later add/remove members of this group through the Perun interface.
After the group is created, you will be notified.
There will be also a /storage/projects/GROUP_NAME
directory created to store the data in.
The Unix file permissions for project directory are 770
.
Using the shared directory
The usage of shared directory is the same for both shared directories in /storage/projects
and in /storage/CITY/home/USER/
.
- assign the directory to your group (denoted by “MYGROUP”)
- set a “sticky bit” (permission atribute) to the directory, so that all the data created within it will belong to the group
- Ensure the correct identity within the system/job environment
When creating files, the system has to know under which group identity the files should be created.
Here, it is necessary to distinguish between the work on frontends and work within running jobs.
Identity on frontends
To create files when working on frontends, it is necessary to change your primary group to the requested one:
You can include the above lines into system start-up scripts /storage/*/home/USER/.profile
or equivalent file (e.g. /storage/*/home/USER/.bash_profile
) so that the correct group is set automatically.
Alternatively, you can ask us to change your primary group within the whole MetaCentrum infrastructure.
Identity in running jobs
When creating files within running jobs, it is necessary to have the following lines within your batch script:
- option
-W umask=002
ensures the correct access rights to created files (rwxrwxr-x
) - option
-W group_list=MYGROUP
ensures that all the processes will run under the groupMYGROUP
these options further ensure an availability of the $SCRATCHDIR
directory to the group members as well - the directory will be owned by the requested group and the access rights will be rwx:
Warning
Because of a bug in the Network File System (NFS) we use, it is necessary to explicitly change the group ownership of the newly created files/directories (at the end of an interactive session or job) by calling the command
(Otherwise, the data will be saved under your primary group.) Alternatively, you can ask us for changing your primary group throughout the whole MetaCentrum infrastructure.
sync_with_group
usage
Some users find changing umask
inconvenient. For these users we recommend another approach.
- Copy the files you need to work with from the shared directory elsewhere.
- Process the data, create new files etc.
- When ready to share the data, send them back into the shared directory by a command
where
NFSv4 usage
Common user requirement is the need to share a certain directory with other users(s). While for more extensive co-operations we recommend to set up a project directory , for smaller-scaled collaborations it is often sufficient to set up access rights accordingly.
This is an alternative way of access control to the above described methods.
Warning
Remember that sharing of user passwords is prohibited by MetaCentrum end-user statement.
Warning
Please note that due to security reasons it is forbidden to grant write permissions to other users or groups of users to a home directory as a whole.
Any files you create, no matter whether inside or outside your home directory tree, are still yours and will be included in your quotas. If you produce tons of data in other user’s directory, you may run out of your quota without seeing any obvious problem in your home.
within the shared directory, any user to whom you grant access can change, delete or rename the files and directories regardless of their owner. It is upon the collaborating group to ensure all users are able to manipulate data safely and to prevent the risks of unwanted loss of data.
Yes, you can grant access to another user very easily by running chmod 777
. Doing so is extremely risky, as you grant access to all users and anyone can, if only by accident, delete your files.
The ls -l
command will not list full ACL. You have to use nfs4_getfacl
command instead. Furthermore, don’t use commands like chmod
(POSIX commands) together with nfs4_setfacl
.
Set up a shared directory
First create the directory to be shared:
Add group of users
If you wish to share the directory within a group of users, run the script as
In the (improbable) case you yourself do not belong to the group, add also yourself as a particular user:
Add particular users
If you want to share the directory only with selected user, proceed as follows:
Strange as it may seem, you need to grant yourself privileged access to be able to manipulate with files created by another user.
Use the shared directory
Work with files and directories
Always set your umask to 0002 when working in shared directory:
The same is true for any of your “hosting users”:
What to do if forgot to set umask to 0002?
If you work in the shared directory with mask set to 0022 (which is the default), the newly created files and directories will not be writable to other users.
Unfortunately the nfs4_setfacl
seems not to work correctly in recursive mode (there seems to be a bug in nfs4_setfacl
), so the obvious solution like running nfs4_setfacl -R -a A::dummy1@META:RWX my_shared_dir
recursively will not work in case you have both subdirectories and files in your shared directory. Therefore you have to circumvent the problem by setting the ACL rights for directories and files separately, as in this script:
Submit jobs
If you submit jobs and wish to copy results to the shared directory, set umask 0002
somewhere at the beginning of the script.
Last updated on