We have a /projects filesystem where individual projects can "buy" a specific amount of disk space. We enforce this purchase limit by creating a specific group for the allocation, adding designated users to the group and setting a group quota.
This works fine as long as the users properly use setgid directories and keep proper group ownership of the files and directories. However, for various reasons our users keep creating files and directories with incorrect group ownership. In most cases this is accidental and eventually causes problems when other group members need to access the files. In abusive cases (not yet seen) people could use this to exceed project disk space allocations. To address this problem we have default quotas set to about 2GB (the smallest we seem to be able to set). This prevents users for consuming too much unpurchased disk space. However, this continues to allow users to create files and directories with incorrect group ownership and it takes users a while to discover their error. User education and cleanup becomes a problem long after the user thinks things are working. We would like to have groups without quota definitions to not be able to create any files. This would prevent accidental file creation at the first attempt. Stuart Barkley On Mon, 4 Dec 2017 at 08:46 -0000, Stephen Ulmer wrote: > I don?t understand why not having permission(s) doesn?t prevent the > user from writing into the fileset... > > As described, your case is about not wanting userA to be able to > write to a fileset if userA isn?t in some groups. Don?t put them in > those groups. That?s not even Spectrum Scale specific, it?s about > generic *nix permissions. > > What am I missing? I don?t understand why you would want to use > quota to enforce permissions. (There could be a legitimate reason > here, but I don?t understand it.) > > Liberty, > > -- > Stephen Ulmer > > Sent from a mobile device; please excuse autocorrect silliness. > > > On Dec 3, 2017, at 10:49 PM, IBM Spectrum Scale <[email protected]> wrote: > > > > Hi Keith, > > > > You can use ACLs for fine grained permissions. A quota limit of 0 > > in GPFS implies no limits. > > > > Regards, The Spectrum Scale (GPFS) team > > > > From: Keith Ball <[email protected]> > > To: [email protected] > > Date: 12/04/2017 08:19 AM > > Subject: [gpfsug-discuss] Smallest block quota/limit and file > > quota/limit possible to set? > > Sent by: [email protected] > > > > HI All, > > > > We have a system where all users have their own private group as > > well. However, for a given fileset (we are using > > --perfileset-quota), we would like to ONLY allow users who also > > belong to just a few central groups to be able to write to the > > fileset. > > > > That is, user "userA" has its own "groupA", but we only want the > > user to be able to write to the fileset if: > > - userA belongs to one of the groups (e.g. group1, group2, > > group3) that have explicitly set quotas > > - The group(s) in question are within quota/limits. > > > > In general, we do not want any users that do NOT belong to one of > > the three groups with enabled quotas to be able to write anything > > at all to the fileset. > > > > Is there a way to set a ZERO quota for block/file in GPFS, that > > means what it actually should mean? i.e. "Your limit is 0 file = > > you cannot create files in this fileset". Creating some kind of > > "supergroup" owner of the fileset (with entitled users as members > > of the group) could work, but that will only work for *one* group. > > > > If we cannot set the block and file limits to zero, what *are* the > > smallest block and fie limits? In GPFS 3.5, they seem to be 1760MB > > for block. Is there a smallest quota for files? (blocksize is > > 16MB, which will be reduced to 4MB probably, in a subsequent > > cluster). > > > > Many Thanks, > > Keith _______________________________________________ gpfsug-discuss mailing list gpfsug-discuss at spectrumscale.org http://gpfsug.org/mailman/listinfo/gpfsug-discuss
