File permissions in the /project and /panasas/scratch directories are different than the /home directories.  The /project and /panasas/scratch directories are SHARED directories for a given group and everyone in the group should have read and write access to the full directory tree.  The default permissions on these directories are such that new files and subdirectories created within them are set correctly to allow this access.  


Here we review a few of these settings to give users a better understanding of how this works:


1. All faculty groups are named to include a prefix of "grp-"  For example, if your faculty group's current group name is smith, it will be named grp-smith.  If you are an industry cluster user, your group will be your company name or a shortened version of it.



2. All user accounts have a private primary group.  This group is named the same as the username.  For example, if the username is smith, the primary unix group for this account is also smith.  

id smith

uid=8845(smith) gid=8845(smith) groups=8845(smith),89245(grp-smith),89200060(davfs2),45693(academic),89200013(pi)



Following the same example, the home directory would be:  /user/smith


[smith@vortex2:~]$ ls -al /user/smith

total 6190793

drwx------  113 smith smith          9327 Oct 29 12:13 .



and the project directory: /projects/academic/smith


[smith@vortex2:~]$ ls -al /projects/academic/smith

drwxrws---  10 smith grp-smith  285 Feb 22  2016 .


The Panasas scratch directory has permissions set like the project directories.  In this example, the group's Panasas scratch directory would be:  /panasas/scratch/grp-smith


[smith@vortex2:~]$ ls -al /panasas/scratch/grp-smith

drwxrws---  10 smith grp-smith  285 Oct 22  2020 .




How does this affect me?  Why does this matter?


Files and subdirectories in the shared project and scratch spaces should be owned by your research group (grp-your_group) or company name (for industry partners).  We have set the default directory permissions to allow for sharing of files among the group.  If you change this, your group members will have problems accessing the files and you may encounter 'out of space' error messages.  



New files and subdirectories:

New files and subdirectories created in the project and scratch directories will have their permissions automatically set correctly, if the top level directory permissions are not altered.  In other words, don't change what our default is and you should not encounter any problems.  



Moving vs. Copying files:

Files copied to the project or scratch spaces will take on the default group permissions, unless you specify to preserve file permissions during the copy.  Don't do this as it is not necessary.  The read, write, execute permissions will not change when you copy a file but the group ownership will be set correctly as long as you don't specify to preserve file permissions.  If you move a file from somewhere else, the file permissions will be retained from the original location and this may result in disk space errors.  If your file or directory is group owned by your private group (see above), you will need to change the file permissions before moving or you'll get 'out of space' error messages similar to:


mv: failed to preserve ownership for 'filename': no space left on device


To change the permissions use:  


chgrp grp-your_group <filename>

example:

chgrp grp-smith /projects/academic/smith/myfile.txt



Group Sticky Bit:

If you do not see the 's' in the group permissions of a subdirectory within your project or scratch directory (see examples above), this means the group sticky bit is not set on that subdirectory.  This is what allows for the automatic setting of group permissions when files are copied or created in a subdirectory.  You must add the sticky bit to the group permissions on the subdirectory to allow for the group permissions to be set correctly:

chmod g+s directory_name


NOTE: You will NOT have to do this if you do not alter the default permissions within the project or scratch directory.  This is only if you copy over subdirectories that do not have this set or accidentally change the permissions and want to set them back.




Checking file permissions: 


The getfacl command is an easy way to see the permissions of a file or directory.  It will display the file/directory name, owner of the file/directory, group name that owns the file/directory, and the detailed permissions of the file/directory. 


[djm29@vortex2:~]$ getfacl /util/common/slurm-scripts/slurm-lammps

# file: util/common/slurm-scripts/slurm-lammps

# owner: cdc

# group: ccrstaff

user::rw-

group::r--

other::r--


For more information on command line options:

getfacl --help
or
man getfacl



All my permissions are correct but my software won't install!


Occasionally, you will run into a problem compiling new code or initializing a conda environment, despite having all your permissions set correctly.  You may get an error such as:


make Error at my_makefile:130 (file):

  file INSTALL cannot copy file


or


ERROR conda.core.link:_execute(568): An error occurred while installing package 'None'.

OSError(28, 'No space left on device')


The program you're running isn't recognizing the directory permissions and is using your private unix group on the new files it creates.  You will need to specify the group to use when the program runs.  Please see this article for details and a work around.



I'm still getting 'out of space' errors


Maybe this isn't an issue of permissions but you really are out of space in either your home directory or your share project or scratch directory.  There are limits on space and number of files you can create.  Please see this article for details on how to check your quota.