Disk Management and Use at D0

Most data disks at D0 are "owned" by a Unix "group", a gid. These disks include /prj_root/* "owned" by a project such as a physics group, /tmp_root/* "owned" by an institution based group, and various miscellaneous areas such as many of the www-d0 web areas. Each gid has one or more managers. It is the responsibility of the manager(s) to police their disk areas, determining what is stored there and for how long. It is also their responsibility to grant and revoke write privilege to the disk areas by adding and deleting members to/from the unix group.

Use of disks

Using group "owned" disks is almost the same as using user owned disks. The only difference is that you must make sure that the entire group has full access to the files and directories that you create. For most users, by default your group does not have full access to your files. The group used in your home area is most likely the D0 group. It would be interesting to allow the entire collaboration full access to all of your files.

Most group owned disks are set to propagate the group ownership of their top level directories. Therefore, you effectively switch groups when you cd to them. However, some are not. If they are not, you can set each directory to do so by:

You can also set your default group to be the one you need: In any case, you need to remember to If you do the umask, do not forget to set it back or any files you create in your home area will be writable by all of D0.

ALSO: When you create new files, especially when using tar, check that both the ownership and protections of the newly created files are correct. Correct them, if needed by using:

Managing the disks

To determine what groups exist, and who is in the groups, on d0mino* or another of the D0 CAS machines: 
   ypcat group | grep <search-string>
To determine who manages a specific Unix group, on d0me.fnal.gov: 
   cmd gldr <unix-group>    # gldr is short for "group leader"
To change the manager(s) of a unix group, send email requesting the change (old and new managers user names and Unix Group name required) to helpdesk@fnal.gov. It is best if one of the existing managers make the request.

Adding and deleting members of the group is done by the group's managers. The group access manipulation utilities actually modify the /etc/group file on the yellow pages server. Because of this you will need to login to d0me.fnal.gov (the NIS master) to do any of the manipulations described below.

There are two basic commands you need to know for granting/rescinding write access to your project disks: 

   cmd addmember <username>     # to add a new member to the group
   cmd delmember <username>     # to delete a member from the group
"cmd" is a Fermilab written utility that allows non-privileged users to perform privilege tasks in a well controlled manner. Any errors in this must be corrected by one of the sys-admin team. So send mail to the helpdesk.

Issuing either of these commands will either perform the action or print out a list of all the groups that you manage. Choose the appropriate group by typing the corresponding number.

Trouble Shooting

If you get a bizarre complaint about "not exactly one user" on the system, you are probably on the wrong node. Login to d0me.fnal.gov.

If you cannot login to d0me or are logged out after a very short time, you must be added to the list of people allowed to login. Contact the helpdesk.

If you get an error: "cmd: No authorization for '<your-username>' to do 'addmember'" then you are not a manager of any groups (or your username is misspelled). Contact the helpdesk.

If the group you want to manager isn't listed, then see the previous answer.

Details specific to prj_root and tmp_root disks

The top directory of the project area should have your group's ownership. Any directories made below this area must also have the group ownership. The group of any files or subdirectories created should be the same as the parent directory. If this doesn't happen, contact the helpdesk.

There should also be two zero length files at the top level of your disk:

The first of these tells you where the disk is really mounted (or was at some time, they are often out of date). The second tells you the group who owns it, the size, that it's not backed up and who the managers are. These files are owned by "root". So if any of the information is wrong, contact helpdesk.

Anyone who is a member of your group should be able to add or delete files from the group's area. If someone who is a member of the group simply logs in and puts a file in the project area, it will normally show up in the "ls -l" as -rw-r--r--, that is no "other=world" (right 3 positions) or "group" (middle three positions) write privilege. Ask the owner of the files and/or directories to "chmod g+w <file>" the files. The "-R" (NOTE: UPPERCASE R, lowercase r will remove your read privilege) switch may be used to do this recursively. If the person is gone or can't be reached, (you guessed it) contact the helpdesk.

Group Ownership

Some of the project disks are shared by groups and usage limits are controlled by group quotas. On these disks files must be owned by by the appropriate group and this can be assured by using the newgrp command to set the group ownership of files that you create. For example: 


% cd /prj_root/706/wz_1
% echo Hello > test.txt
% ls -l test.txt
-rwx-r--r-- 1 casey D0 5555 Jan 22 00.00 test.txt

or

% newgrp wz_write
% cd /prj_root/706/wz_1
% echo Hello > test.txt
% ls -l test.txt
-rwx-r--r--     1       casey   wz_write 5555    Jan 22 00.00 test.txt

Determining Quota Statistics

The command "quota -g " will report the disk quota usage for a group. For example: 

# quota -g mc_write
Disk quotas for group mc_write (gid 2807):
     Filesystem  blocks   quota   limit   grace   files   quota   limit   grace      /dev/sdb1       4  820000000 820408804               1       0       0

Do "man quota" to see the meaning of the quota, limit, and grace fields. Note you must run this command on a machine that supports group quotas to use this command.

Last modified: Wed Jan 16 20:35:33 CST 2008