The Problem:


The "make install" phase of a software build in a shared project or Panasas scratch directory fails to copy the compiled files to the install target directory, e.g.


vortex1$ make install
[...]
-- Installing: /projects/academic/projname/software/builddir/newfile
make Error at my_makefile:130 (file):
file INSTALL cannot copy file
"/projects/academic/projname/software/builddir/newfile"
to
"/projects/academic/projname/software/install/dir/bin/newfile":
[...]
make: *** [install] Error 1
vortex1$

or you're getting the error 'no space left on device,' e.g.


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

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



The Background:


When you are writing to a /projects directory tree, for example: /projects/academic/projname
If you look at the permissions of this directory you will see that the group sticky bit is set:


vortex1$ ls -ld /projects/academic/projname/
drwxrws--- 4 projname grp-projname 53 Apr 10 11:40 /projects/academic/projname/
vortex1$


This means that (by default) files & directories created in this directory will be owned by the group "grp‑projname" (i.e. the group that owns the directory.) 


Everyone's user account has a personal group the same name as their username, as the primary group:


vortex1$ id
uid=(89100000) gid=89100000(myuser) groups=89100000(myuser),88010000(grp-projname),45693(academic)
vortex1$


This is your default group, i.e. if you create a file or directory, this is the group that will own the file or directory.
When you create a file or directory in the  /projects/academic/projname/ directory  the group stick bit set on that directory overrides the default behavior.
When you run a "make install" which uses an install program that forces specific  permissions on a directory (overriding the group sticky bit, which is otherwise inherited from the parent directory) files crested in the new directory will not be owned by the parent dir group e.g. in this case they would be owned by the "myuser" group, not the "grp‑projname" group.   The personal group "myuser" does not have a quota to write to the /projects directory tree, so you would get an out of space (out of quota) error.


The Solution:


The newgrp command changes your (active) primary group, e.g.


vortex1$ id
uid=(89100000) gid=89100000(myuser) groups=89100000(myuser),88010000(grp-projname),45693(academic)
vortex1$ newgrp grp-projname
vortex1$ id
uid=(89100000) gid=88010000(grp-projname) groups=88010000(grp-projname),89100000(myuser),45693(academic)
vortex1$


...so now files & directories you create will be owned be group owned by the "grp‑projname" by default, so you shouldn't run into quota problems; even if the group sticky bit it not set on a directory.
Hence "make install" will complete without error.