Am I reading the documentation correctly and there is no way to specify quotas with the following logic:
All users with gid X get user quota Y
How come? It seems like this would be both useful and trivial to implement?
In the situation we're looking at it is not convenient to establish a different quota tree for every group and then put default user quotas on each tree. I'm hoping I'm just not understanding the documentation. :-)
Brett
--- Brett Rabe brett@uswest.net / 612.664.3078 Senior Systems Guy U S WEST - Internet Services
All bleeding eventually stops. -- Hayden Meeker
Am I reading the documentation correctly and there is no way to specify quotas with the following logic:
All users with gid X get user quota Y
How come? It seems like this would be both useful and trivial to implement?
In the situation we're looking at it is not convenient to establish a different quota tree for every group and then put default user quotas on each tree. I'm hoping I'm just not understanding the documentation. :-)
The problem is that files have a single group, but users can belong to multiple groups. So if I am a member of two groups, which one determines my personal quota?
(Note that group quotas as currently implemented pose no problem because each file has only one group, so the disk space consumed by the file is charged to its group.)
You might suggest that the filer should use the user's primary group (the one listed in /etc/passwd) to determine the quota. This would require the filer to have a local user database or NIS map to obtain this information. For filers running NFS, however, a local user database is totally unnecessary. This is because each NFS request packet includes the uid and gids of the requestor. The filer simply checks these against the uid and gid of the file being accessed to see if the request is permitted. Since each NFS packet contains all the credentials of the requestor, what need does the filer have for a user database?
So I suppose you could suggest that *if* the filer has a local user database (but it certainly isn't required to) then it would be nice to be able to specify the user quota based on the primary group of the user.
Steve Losen scl@virginia.edu phone: 804-924-0640
University of Virginia ITC Unix Support
This would require the filer to have a local user database or NIS map to obtain this information. For filers running NFS, however, a local user database is totally unnecessary. This is
NFS only. if you want to use groups to restrict say CIFS access, then the filer needs both a copy of the group and password files.
and actually, if you are doing quotas by name ( can you do them by uid?) then the filer would also need to have access to the passwd file.
-steve
and actually, if you are doing quotas by name ( can you do them by uid?) then the filer would also need to have access to the passwd file.
-steve
I believe you can specify a uid in the quota file.
You can specify a file name or directory name in a quota entry and the quota is applied to the owner of that file or directory. The same is true for group quotas. So again, in a NFS only environment you don't need a user database. Here's a typical entry from our quota file:
/h1/s/sc/scl user 100M 100K
Steve Losen scl@virginia.edu phone: 804-924-0640
University of Virginia ITC Unix Support
You can specify a file name or directory name in a quota entry and the quota is applied to the owner of that file or directory. The same is true for group quotas. So again, in a NFS only environment you don't need a user database. Here's a typical entry from our quota file:
/h1/s/sc/scl user 100M 100K
be careful with this syntax. when i had entries in this form i had problems where once the directory /h1/s/sc/scl would fill up, no writes were permitted for that user, anywhere on the filer. this included shared directories owned by him. but written to by others. yet not existing under his homedir.
scl user@/vol/vol1/h1/s/sc/scl 100M 100K
would have the effect of only applying to their homedir. that seems to be my experience.
-steve
-
Brett Rabe -
Guy Harris -
Stephen C. Losen -
Steve Armijo