Many Biowulf users are working on projects with other Biowulf users, who may be in the same lab, same IC, or in
other NIH ICs. A group of users may need to share data, software installations, and scripts on a regular basis. The best way to
approach this kind of workload is to set up a group with a shared directory.
All groups have a group owner and group members. The group owner and members must all have Biowulf accounts. The group owner is the only person in the group who can request the addition or deletion of users from the group, and who can apply for a quota increase for the shared directory. To apply for a shared group and an associated data directory, the group owner should fill out the online form at https://hpcnihapps.cit.nih.gov/auth/dashboard/shared_data_request.php |
The Principal Investigator (PI) of the group owner has the final responsibility for data in the shared group directory. If there are questions about the ownership of any of the data, or if all the group members leave, the PI is responsible for decisions about the disposition of the data.
The group owner is the first member listed in the group. Via the HPC Dashboard, this person will be able to check the members of the group, and make the following changes. Only the group owner (or the PI) can request such changes.
The shared group directory is initially set up to be owned by the group owner, with read-write-execute permission by the group members. e.g.
drwxrws---. 6 groupowner XYZLab 4096 Aug 10 15:13 /gs6/users/XYZLab/The group directory has 'setgid' set, which causes all new files and directories created to inherit the group, and propagates the setgid to subdirectories. This is indicated by the 's' in the 7th position of the permission string:
drwxrws---.
Group members are responsible for any data that they write into the shared directory. They should:
If the group directory is nearing or hits its quota limit, an alert email will go out to all members of the group.
Each Biowulf user is responsible for ensuring proper group ownerships are applied and file permissions are appropriately set in shared directories.
A common problem is when a group member miss sets permissions on a file or directory, and other group members are unable to read it.
If the group owner and group members are not familiar with Unix permissions and umasks, it is highly recommended that they read through Data Management for Groups, which describes in detail some approaches to data management, how to set and manage permissions, and how to fix problems.
Within the shared directory, some groups may want all group members to have read-write access to all subdirectories. In that case, all group members should be sure to set their umask appropriately, e.g. by setting
umask 007either in their /home/$USER/.bashrc (which then applies to all jobs and all login sesssions thereafter), or for a particular session. See here for a more thorough explanation of startup files.
Other groups may want subdirectories owned by each group member with only read access for other group members, e.g.
The group owner should ensure that each member of the group follows best practices for management of the group directory.
Explanation: The most likely issue is that the group of the folder is not set to the desired group. By default, all folders in the shared data area are configured to inherit the group by setting the setgid permission. This works well when files or folders are created in the data share directory. However, if a folder or file are copied or moved into the shared directory, the group and permissions may need to be manually configured. The ls -l command is useful to see the ownership and permissions of the file (ls -ld for a folder) For a full description of the ls output, see our Unix Permissions documentation. A second possibility are the lack of group read and execute permissions. Due to the default permissions on the HPC system, this is less common. If a directory does not have the correct group or permissions, you should contact the file owner to get them updated.
Explanation: The most likely issue is the group permissions on the folder do not allow group write access. The ls -ld command is useful to see what the group permissions are on a folder. If a directory does not have the expected group permissions, you should contact the folder owner to have them updated the group permissions. For a full description of the chmod command, see our Permission Mode documentation.
Explanation: The root of the problem are the default group permissions (see FAQ #2). The default permissions set on a file or directory is determined by the current setting of umask. For security purposes, the default umask does not allow group write permissions. For a full description of default permissions, see our umask documentation. If you wish to modify your default permissions, it is important to read and understand the umask documentation implications.
If a folder has been created with the wrong permissions, they can be fixed later by using chmod.
Explanation: The set-gid bit forces new files or folders to inherit the group owner of the parent folder. By default, all top level shared data directories are configured with the set-git bit enabled. This means any file or folder created in the top level data share directory will inherit the correct group-owner. In some situations, the set-gid bit of child directories can become unset. Once the set-gid is unset, new files or folders will be group-owned by the default group of the user.
The set-gid bit is denoted by an 's' in the group-execute field of a folder. To add the set-gid bit to a folder, use:
For a full description of the set-gid, see our Unix Permissions documentation.
If there is still data left in the shared group directory, the HPC staff will contact the responsible PI (the PI of the last group owner) to discuss downloading/deleting of any remaining data.