What's the best method for creating a quota controlled shared disk space for a group of users on a Linux system?

Question

Our users often request a shared disk space to use with a group of users in order to exchange or work on some files. To be able to also utilize quota management we create a new user account (which is quota controlled) and give access to that user's home from the group of users. I actually do not like this approach. How can we build a flexible solution which will allow us to give some amount of space to some users on demand with quota control enabled?

(One solution I think of is making heavy use of LVM in order to create a new partition (lv) for each group but I am not sure how it will scale.)

Answer 1

I'm a fan of "soft-quotas". Hard quota and disk limits can impair ability to work, if they happen to actually need 30 G of space one day to do some large project, let's say. At my company we have a very simple script which grabs all the users from AD, SMB mounts their home directories and does size calculation. Attached to this script is a standard quota limit (2G for us), as well as an exceptions list.

If they violate the quota they, along with management, receive an E-Mail notification of the size of their directory, as well as their quota.

Doesn't work for every environment, or every scale, but it beats impairing productivity when you have a hard quota limit.

Answer 2

In my experience, the big issues are:

Quotas

We've defined "project" directories and use XFS project quotas to enforce quotas. We apply both soft and hard quotas, and have scripts to alert users by email when their soft quotas are reached. This is braindead easy to do with XFS.

Permissions

Permissions always seem to be a huge problem. We now use ACLs to ensure that all members of the group have access to all files that are created, but problems arise when we share the directories to computers that don't understand those ACLs, or when programs create files with explicitly narrow permissions. We end up with subdirectories that don't have the correct ACLs, and then users complain that they can't edit some items in their group folder that someone else created. This leads to everyone getting frusterated and running chmod -R 777 * on everything they own. It seems that most people expect a group folder to have a single set of permissions which apply equally to all descendant filesystem objects.

To enforce this, we have a cron script called the permission smasher that periodically walks through all project directories and fixes up the permissions (both standard and ACLs) of all filesystem objects. Everything gets the same permission levels (although it maintains the eXecutable bit), and the permissions are defined in a config file that is version controlled. This gives us excellent assurance that users aren't unknowingly circumventing access controls to give access to the wrong people.

On our Mac OS X Servers, this is quite a bit easier. HFS has ACLs that can override the ACLs of all descendant filesystem objects. Even better, they're applied on the server side, so clients that don't understand HFS ACLs (linux NFS clients, for example) work as expected too. We simply define the ACL on the group directory itself, and all of its contents are always available uniformly to the entire group.

Accountability

Another tricky issue is who is ultimately responsible for data that is stored in group/project directories. Data tends to accumulate and rot in them, because no single person is responsible for keeping it tidy. When the quota is reached, it is sometimes difficult to find the appropriate person to notify. To solve this, we try to designate a single user as the maintainer for each directory.

Answer 3

We used a separate partition for group shared data. We then set up group quotas and have one directory per group. We also set the directories to be setgid, so newly created files would inherit the permission of the group. This probably doesn't form a complete solution, but might be a useful start.

Answer 4

If you can swing it, use a Solaris (or OpenSolaris) machine for your fileserver. ZFS and the more advanced NFSv4 ACLs are lightyears beyond what you can do with Posix permissions, Posix ACLs, LVM etc. Even if the client doesn't talk NFSv4 the ACLs will still be enforced and propagated by ZFS, they just have to be managed from the server. This is actually probably better in most cases as the complexity is hidden from the end users.

You can then easily create ZFS filesystems for each operational group, project, or whatever, and assign quotas and quota policies as necessary.

This is by far the most flexible type of system I've seen for this purpose, but of course not applicable to every environment.