Project gdata group ownership can be checked and fixed in the following way:
[ab2345@gadi-login-01 ~]$ nci-files-report --group rr33 --------------------BREAKDOWN BY PROJECT, GROUP, AND USER-------------------- FILESYSTEM SCAN DATE PROJECT GROUP USER SPACE USED TOTAL SIZE COUNT gdata 2023-06-19 ww22 rr33 ab2345 170.1G 170.1G 16774 gdata 2023-06-19 rr33 rr33 xy6789 249.4G 249.4G 226 [...] -----------------------------------------------------------------------------
The above output for project rr33 shows that the data in /g/data/ww22 owned by the user ab2345 is owned by the incorrect group rr33, instead of ww22.
To fix this issue, login as the user ab2345 and execute the following command to transfer the project group ownership to ww22 for all the data in /g/data/ww22 owned by the user ab2345 and apply group sticky bit to all directories to ensure that all future data in /g/data/ww22 is always created under the ww22 project ownership:
[ab2345@gadi-login-01 ~]$ my_project=ww22
[ab2345@gadi-login-01 ~]$ find /g/data/$my_project -user $USER -a \( \( \! -group $my_project -exec chgrp -ch $my_project {} + \) , \( -type d \! -perm -g+s -exec chmod -c g+s {} + \) \) 2> /dev/null
Important
- This should be done only if it will solve a problem.
- To be done only on gdata1a, 1b and 4. Scratch and gdata5/6 now use project directory based accounting, hence presence of data owned by difference NCI projects in a project directory does not affect accounting. That data will be accounted under the project directory that they are residing in.
- Note that transfer of data ownership from one project to other will consume the storage allocation from the destination project. Estimate and ensure the target project has sufficient allocation to absorb this data.
- Inform the user of point 3 and it's implications, and get a confirmation before actioning change of group ownership.
Overview
Content Tools