Shared folders: Difference between revisions

From HPCwiki
Jump to navigation Jump to search
No edit summary
 
(18 intermediate revisions by 5 users not shown)
Line 1: Line 1:
= Working with shared folders on Anunna =


== Working with shared folders in the Lustre file system ==
If you work in a group or team, it is sometimes useful to work within a shared space. Users can thus share inputs to their models and make their outputs also easily available to each other. This article explains how to do so within the Lustre file system and home or archive folder (NFS).


If you work in a group or team and use large volumes of data, it is useful to work within a shared space. User can thus share inputs to their models and make their outputs also easily available. This article explains how to do so within the Lustre file system, that presently supports the HPC.
There are two main methods available to you: Access Control List (ACL) access (that you can administer yourself), group access with AD rights or group access within Anunna (which are centrally administered).


=== Identifying a suitable user group ===
Below we will split out the options for each method.


Users access the HPC cluster with their WUR-wide account. This means that all the membership information is also available in the HPC system. To check of which groups is your user a member of, use the following command:
== ACL shared directories ==
=== ACL shared directories on Lustre ===
You may create a folder that can be accessed by yourself and someone else in the following manner:


<code>groups <username></code>
<pre>
cd /lustre/shared
mkdir shared_folder
chmod 700 shared_folder
setfacl -R -m u:my_id:rwx shared_folder
setfacl -R -d -m u:my_id:rwx shared_folder
</pre>


This can result in a rather long list, reflecting permissions in the overall WUR systems. Within these groups you must then identify the one that is closer to match the team or group with which you wish to collaborate.
Then, for each person who you want to have access to this:
<pre>
setfacl -R -m u:my_friend:rwx shared_folder
setfacl -R -d -m u:my_friend:rwx shared_folder
</pre>
 
Adding users later can be done using the same method, but it might be hard.
You may have trouble updating ACLs on files that aren't yours, and you cannot change ownership of files to yourself.
Each user with files in the folder will need to update their ACLs appropriately themselves, or you can contact your sysadmins to assist.
 
=== ACL shared directories on NFS folders ===
 
If you want to share e.g. you home folder with another user, follow these steps:
 
==== Set access rights on folder ====
 
If you want to e.g. allow somebody (as identified by their user id) full read access on your homefolder, run this :
<pre>
setfacl --recursive --modify u:haars001:r-x $HOME
</pre>
 
== Group shared directories ==
 
Users access the Anunna cluster with their WUR-wide (Active Directory) or Anunna only account. This means that all the membership information of the AD is also available on Anunna. To check of which groups your user is a member of, use the following command:
 
<pre>groups <username></pre>
 
This can result in a rather long list, reflecting permissions in the system. Within these groups you must then identify the one that is closer to match the team or group with which you wish to collaborate.


For instance, if I wish to work together with colleagues at ISRIC, I can search within my groups an appropriate match:
For instance, if I wish to work together with colleagues at ISRIC, I can search within my groups an appropriate match:


<code>groups duque004 | grep isric</code>
<pre>groups duque004 | grep isric</pre>


In my case the group des-isric-users looked appropriate. Then next step is to confirm if the other users in my team are also members of the group.
In my case the group des-isric-users looked appropriate. Then next step is to confirm if the other users in my team are also members of the group.


=== Creating a shared folder with correct permissions ===
If a group isn't available (cooperation with people outside WUR), please ask the administrators for help, they can then set up a group for you.
 
=== Creating a shared Lustre folder with correct permissions ===


The Lustre file system is accessible in the <code>/lustre</code> folder and then divided into the <code>/backup</code> and <code>/nobackup</code> sections (corresponding to the different usage plans). Inside each of these folders there is a sub-folder named <code>SHARED</code> in which users are to create their own assets.
The Lustre file system is accessible in the <code>/lustre</code> folder and then divided into the <code>/backup</code> and <code>/nobackup</code> sections (corresponding to the different usage plans). Inside each of these folders there is a sub-folder named <code>SHARED</code> in which users are to create their own assets.
Line 24: Line 62:
You start by creating a folder in this space; it is probably better if it matches the name of your group or team, e.g.:
You start by creating a folder in this space; it is probably better if it matches the name of your group or team, e.g.:


<code>mkdir /lustre/nobackup/SHARED/myTeamWorkspace</code>  
<pre>mkdir /lustre/nobackup/SHARED/myTeamWorkspace</pre>  


Or in alternative:
Or in alternative:


<code>cd /lustre/nobackup/SHARED
<pre>
cd /lustre/nobackup/SHARED


mkdir myTeamWorkspace</code>  
mkdir myTeamWorkspace
</pre>


=== Setting permissions ===
=== Setting permissions ===
Line 38: Line 78:
1. Pass the ownership of the group to the team. In the example below it is applied recursively to all sub-folder and files that may exist:
1. Pass the ownership of the group to the team. In the example below it is applied recursively to all sub-folder and files that may exist:


<code>chgrp -R my-team-group myTeamWorkspace</code>
<pre>chgrp -R my-team-group myTeamWorkspace</pre>


2. Concede read/write permissions to the group. This allows other members of the group to read and write in the shared folder. If you wish other team members to only read from the folder then remove the <code>w</code> character from the <code>+rw</code> bit:
2. Concede read/write permissions to the group. This allows other members of the group to read and write in the shared folder. If you wish other team members to only read from the folder then remove the <code>w</code> character from the <code>+rw</code> bit:


<code>chmod -R g+rw myTeamWorkspace</code>
<pre>chmod -R g+rw myTeamWorkspace</pre>


3. Set default ownership within the group. This guarantees that any new files or folders created within the shared folder are owned by default owned by your team group:
3. Set default ownership within the group. This guarantees that any new files or folders created within the shared folder are owned by default owned by your team group:


<code>chmod -R g+s myTeamWorkspace</code>
<pre>chmod -R g+s myTeamWorkspace</pre>


In case the contents of the shared are sensitive or private, and should be accessed by your team, you can block access from any other users with the following command:
In case the contents of the shared are sensitive or private, and should be accessed by your team, you can block access from any other users with the following command:


<code>chmod -R o-rw myTeamWorkspace</code>
<pre>chmod -R o-rw myTeamWorkspace</pre>


=== Further reading ===
== Further reading ==


[https://www.digitalocean.com/community/tutorials/an-introduction-to-linux-permissions An Introduction to Linux Permissions]
[https://www.digitalocean.com/community/tutorials/an-introduction-to-linux-permissions An Introduction to Linux Permissions]

Latest revision as of 13:28, 16 September 2024

Working with shared folders on Anunna

If you work in a group or team, it is sometimes useful to work within a shared space. Users can thus share inputs to their models and make their outputs also easily available to each other. This article explains how to do so within the Lustre file system and home or archive folder (NFS).

There are two main methods available to you: Access Control List (ACL) access (that you can administer yourself), group access with AD rights or group access within Anunna (which are centrally administered).

Below we will split out the options for each method.

ACL shared directories

ACL shared directories on Lustre

You may create a folder that can be accessed by yourself and someone else in the following manner:

cd /lustre/shared
mkdir shared_folder
chmod 700 shared_folder
setfacl -R -m u:my_id:rwx shared_folder
setfacl -R -d -m u:my_id:rwx shared_folder

Then, for each person who you want to have access to this:

setfacl -R -m u:my_friend:rwx shared_folder
setfacl -R -d -m u:my_friend:rwx shared_folder

Adding users later can be done using the same method, but it might be hard. You may have trouble updating ACLs on files that aren't yours, and you cannot change ownership of files to yourself. Each user with files in the folder will need to update their ACLs appropriately themselves, or you can contact your sysadmins to assist.

ACL shared directories on NFS folders

If you want to share e.g. you home folder with another user, follow these steps:

Set access rights on folder

If you want to e.g. allow somebody (as identified by their user id) full read access on your homefolder, run this :

setfacl --recursive --modify u:haars001:r-x $HOME

Group shared directories

Users access the Anunna cluster with their WUR-wide (Active Directory) or Anunna only account. This means that all the membership information of the AD is also available on Anunna. To check of which groups your user is a member of, use the following command:

groups <username>

This can result in a rather long list, reflecting permissions in the system. Within these groups you must then identify the one that is closer to match the team or group with which you wish to collaborate.

For instance, if I wish to work together with colleagues at ISRIC, I can search within my groups an appropriate match:

groups duque004 | grep isric

In my case the group des-isric-users looked appropriate. Then next step is to confirm if the other users in my team are also members of the group.

If a group isn't available (cooperation with people outside WUR), please ask the administrators for help, they can then set up a group for you.

Creating a shared Lustre folder with correct permissions

The Lustre file system is accessible in the /lustre folder and then divided into the /backup and /nobackup sections (corresponding to the different usage plans). Inside each of these folders there is a sub-folder named SHARED in which users are to create their own assets.

You start by creating a folder in this space; it is probably better if it matches the name of your group or team, e.g.:

mkdir /lustre/nobackup/SHARED/myTeamWorkspace

Or in alternative:

cd /lustre/nobackup/SHARED

mkdir myTeamWorkspace

Setting permissions

Three basic steps are involved in stepping permissions correctly:

1. Pass the ownership of the group to the team. In the example below it is applied recursively to all sub-folder and files that may exist:

chgrp -R my-team-group myTeamWorkspace

2. Concede read/write permissions to the group. This allows other members of the group to read and write in the shared folder. If you wish other team members to only read from the folder then remove the w character from the +rw bit:

chmod -R g+rw myTeamWorkspace

3. Set default ownership within the group. This guarantees that any new files or folders created within the shared folder are owned by default owned by your team group:

chmod -R g+s myTeamWorkspace

In case the contents of the shared are sensitive or private, and should be accessed by your team, you can block access from any other users with the following command:

chmod -R o-rw myTeamWorkspace

Further reading

An Introduction to Linux Permissions

Linux Users and Groups

Linux Permissions Basics and How to Use Umask on a VPS

Linux Tutorial - Managing Group Access on Linux and UNIX