rsnt_translations
56,420
edits
No edit summary |
No edit summary |
||
Line 64: | Line 64: | ||
In the context of the project space, the directory owner will be the PI who sponsors the roles of the students and collaborators. | In the context of the project space, the directory owner will be the PI who sponsors the roles of the students and collaborators. | ||
=== | === Group ID === <!--T:16--> | ||
When creating files and directories within a parent directory it is often useful to match the group | When creating files and directories within a parent directory it is often useful to match the group ownership of the new files or directories to the parent directory's owner or group automatically. This is key to the operation of the [[Project layout|Project]] filesystems at Graham and Cedar for example, since storage quotas in Project spaces are enforced by group. | ||
<!--T:18--> | <!--T:18--> | ||
If | If the <tt>setGID</tt> bit is set for a directory, new files and directories in that directory will be created with the same group ownership as the directory. To illustrate the use of this mode, let us walk through an example. | ||
<!--T:17--> | <!--T:17--> | ||
Line 100: | Line 100: | ||
-rw-rw-r-- 1 someuser def-someuser 0 Oct 13 19:39 test02.txt | -rw-rw-r-- 1 someuser def-someuser 0 Oct 13 19:39 test02.txt | ||
</source> | </source> | ||
If we create a directory inside a directory with the | If we create a directory inside a directory with the <tt>setGID</tt> set it will have the same group as the parent folder and also have its <tt>setGID</tt> set. | ||
<source lang="console"> | <source lang="console"> | ||
[someuser@server]$ mkdir dirTest/dirChild | [someuser@server]$ mkdir dirTest/dirChild | ||
Line 108: | Line 108: | ||
drwxrwsr-x 1 someuser def-someuser 0 Oct 13 19:39 dirChild | drwxrwsr-x 1 someuser def-someuser 0 Oct 13 19:39 dirChild | ||
</source> | </source> | ||
Finally it can be important to note the difference between a <code>S</code> ( | Finally it can be important to note the difference between a <code>S</code> (uppercase S) and <code>s</code>. The uppercase S indicates that execute permissions have been removed from the directory but the <tt>setGID</tt> is still in place. It can be easy to miss this and may result in unexpected problems, such as others in the group not being able to access files within your directory. | ||
<source lang="console"> | <source lang="console"> | ||
[someuser@server]$ chmod g-x dirTest/ | [someuser@server]$ chmod g-x dirTest/ |