Manage user accounts in a multi-user Linux environment with disk quotas

by Chad Perrin | May 09, 2006 8:25:00 PM

Tags: Chad Perrin, disk, computer, Linux

Takeaway: Disk quotas in Linux make use of software managed constraints on how much disk space can be used by specific user accounts. This brief tutorial explains how to set up them up on your system.

One of the strengths of Linux, as well as other Unix-based operating systems, is its capabilities as a multi-user environment. User accounts benefit from the enhanced security of strict privilege separation, and they can be simultaneously active and accessed, both locally through input and output devices and remotely through network services. This makes Linux systems ideal for many implementations as multi-user workstations, application servers, and remote test platforms.

These implementations can face social challenges that do not arise with a one user per computer scenario. One such challenge is shared storage space, and the fact that some users, for whatever reason, fail to play nicely with others. It may be due to a desire to "get away with" something, like always wanting the biggest piece of cake at a birthday party, or these problem users may just be oblivious to the concerns of sharing a single computer and unable or unwilling to keep track of their own disk use. When users start hogging disk space at the expense of other users, the system administrator for a multi-user computer needs to start thinking about how to control disk use with preset limits. In fact, when setting up a multi-user system in the first place, it is probably a good idea to think ahead, rather than waiting until someone is already over reasonable limits to do something about the problem.

You can always go to disk space hoarders and try to reason with them, but if they were that reasonable they probably would not have gotten you into this position in the first place. If you didn't plan ahead, though, you may have to ask nicely for people to reduce their disk usage anyway before you start using automated means to limit them, just to get them within the limits you intend to set. You could also try public embarrassment: publish disk usage statistics for everyone using the system somewhere that is mutually accessible to all, and hope that peer pressure will bring your problem users back in line. While this is unlikely to work in most cases, it may be your only option with people who -- perhaps for political reasons, such as your boss -- you cannot really limit against their will. Usually, technical solutions are better options than either of these. Luckily, as with most social problems involving computers, code hackers have risen to the challenge of providing more than one way to let the computers deal with other people so geeks don't have to.

If you have few enough users to make it reasonable to do so, and the roster of users for your system is not likely to change, you can always create a separate partition per user and mount them separately within the home directory area in your multi-user computer's file system. With changing lineups of users, however, or with more than a handful of people, this can quickly get out of hand and be very unwieldy to manage. In cases where significant storage volume is needed by each user, however, this might be reasonable using network attached storage. You could solve your problem using one disk per user, in fact. Unfortunately, most sysadmins for multi-user systems will not find themselves in this situation.

For most sysadmins, the right answer will be disk quotas. Disk quotas in Linux make use of software managed constraints on how much disk space can be used by specific user accounts. While there are complicated free quota management systems with many bells and whistles and clicky widgets as well as expensive commercial quota management systems that you could use to solve this problem, the simplest and perhaps the easiest is the basic command line quota toolset available to administrators of all the major Linux distributions free of charge. With this commonly available disk quota system, the limits on storage space that can be used by different user accounts are enforced by the operating system itself.

Disk quotas can be individually configured for each user account, and they can be very easily replicated for multiple users when you have groups of users that should all operate under the same constraints. The system is automated, and can be configured to give warnings and grace periods for people who stray beyond their limits, within a pre-set higher limit, to provide a helpful and forgiving -- but still effective -- manner of ensuring compliance. Unlike using separate partitions, or even entirely separate physical disks, for each user account, it is a trivial matter to alter disk quotas when needed. Perhaps best of all, it doesn't require confronting your users directly, because once set in motion your disk quota system manages itself.

Preparing for disk quotas

There are a few short steps involved in preparing your system for disk quotas. These are a one-time necessity when you decide to implement a quota system. Once your system is configured to use disk quotas, you don't need to revisit these steps again.

Installation

First, you need to ensure the quota system is installed. How this is accomplished will vary somewhat from one Linux system to the next, but your distribution's package management system should provide a simple and easy means of installing the quota system if it is not already installed by default. You can check to see if it is already installed by opening a shell interface and entering the command quota, either using a terminal emulator like kterm or gterm, or signing in at a TTY console. If quota is already installed, and if your user name is foo, you should see something like the following:

$ quota
Disk quotas for user foo (uid 1000): none

If it is not installed, you will get a "command not found" response. If you get a response that gives disk quota information, someone has already implemented disk quotas on your machine.

Here is an example of installing quota on a Debian GNU/Linux system, using the apt-get command for the APT software management system:

$ apt-get install quota
Reading package lists... Done
Building dependency tree... Done
The following NEW packages will be installed
quota
0 upgraded, 1 newly installed, 0 to remove and 0 not upgraded.
Need to get 439kB of archives.
After unpacking 1188kB of additional disk space will be used.

This will be followed by more information about the installation as it occurs, and your Debian system will ask you a couple of questions about how quota violation reports should be handled. Installation procedures on other Linux distributions will likely be very similar.

If, for some reason, your distribution does not provide a means to install quota via a package manager, you may have to download it from sourceforge.net/projects/linuxquota to install it from source.

Boot configuration

Second, you need to make sure your system is configured to enable quota management when it boots. Most distributions, such as RHEL/Fedora, Novell/SuSE, Mandrake, and Debian, should have this enabled by default, and you probably won't have to do anything about this at all.

On Debian, for instance, installing quota adds a startup script to /etc/init.d for you. At most, then, you might have to add a symlink to that startup script in the rc[n].d directory where the numeral at [n] matches the runlevel at which your system operates. You can get more information about runlevels by entering man init and reading not only that page, but some of the manpages referenced in the "SEE ALSO" section at the end of the initmanpage, as well.

To discover your current runlevel, you can simply enter the runlevel command when logged into the root account, which will tell you both the previous runlevel and the current runlevel. For most systems, most of the time, the previous runlevel will be a capital N, indicating that the current runlevel is also the only runlevel at which your system has been operating.

If for some reason your system is not already configured to enable the quota system at boot, you may have to edit a boot script yourself. If your system uses the /etc/init.d directory for service scripts, you can use the scripts already there to guide you in creating a new bash script to enable quota, and symlink to it from the appropriate rc[n].d directory. If your system uses the rc.local script instead, you may want to add the quota system's startup to that file. Either way, you'll need to add bash scripting code that looks something like this:

# first, check to see if quota is running, then turn it on if not
if [ -x /sbin/quotaon ]
then
/sbin/quotaon -avug
fi

You should double-check the location of your quotaon command. On some systems, it may not be in /sbin.

Partition configuration

Third, you need to configure partition settings to enable quotas and specify how they will be implemented on that partition. When setting up disk quotas, you can apply them to users or to groups. Each mounted partition can have its own quota configuration, which you specify in the fstab file and with quota configuration in that partition. As an example, you may create quotas on one partition to limit the size of users' home directories, and on another partition you may create a directory that is accessible to all users that are members of a given project group and limit the size of that directory for the entire group.

To enable quotas for a partition, you need to edit the /etc/fstab file. In each entry in that file, there will be a column that contains mount options, such as ro (for "read only"), rw (for "read/write"), or defaults. These options go in a comma-separated list, without spaces. If you wish to enable user quotas on a given partition, add the usrquota option, and if you wish to enable group quotas, add the grpquota option.

To prepare the partition itself, you need to set up the quota database on each partition that will use quotas. You will create empty data files to store user and group quota information in the root directory of each partition that will use quotas.

For instance, if you will be mounting /dev/hda2 at /home, you will navigate to /home when that partition is mounted there and create the empty files quota.user and quota.group. You should be logged in as root to do this: touch quota.user and touch quota.group are the commands used to create these empty files. Once they are created, you should use the chmod command to change the file permissions on these database files so that only the root user can read and write to them. In total, the commands you enter, and their output, might look like this:

$ su
Password:
# cd /home
# touch quota.user
# touch quota.group
# chmod 666 quota.user
# chmod 666 quota.group

Quotas

Finally, you should be ready to actually create your quota settings for users and groups. To do this, you'll be using the edquota command. Using this command, you can configure soft limit quotas, hard limit quotas, and grace periods for exceeding the soft limit.

A hard limit is the quota that each user's or group's disk usage cannot exceed. The operating system will prevent a user or group from exceeding its hard limit quota, as though the hard drive simply ran out of storage space. It is normal for a sysadmin to set a hard limit that is a little higher than the soft limit to provide some breathing room when a user or group needs to save a file before eliminating excess files that cause the quota limited directory to overrun its soft limit. One reason something like this might be needed, for instance, is for copying, modifying, and testing a file before deleting the copy.
A soft limit is the quota to which each user's or group's disk usage should be limited for day to day operations. The soft limit can be exceeded temporarily, as described above under the hard limit explanation, but after a short period of time the soft limit will be enforced by disabling the user account if the user's directory is not brought within standards of soft limit quota compliance. Enabling the account again will require action by the system administrator.
The grace period setting determines how long someone has to bring storage use within standards for soft limit quota compliance. For instance, a setting of seven days gives a user seven days, after first exceeding the soft limit, to bring disk usage in the quota configured directory below the soft limit again before the user account is disabled. On most systems, seven days will be the default grace period, though the sysadmin can configure the grace period for a longer or shorter time if desired.

Entering the edquota command will open the default text editor specified in your shell's $EDITOR variable. If you don't like the editor that is invoked -- for instance, if you're a vi user and edquota brings up emacs -- you can alter the $EDITOR variable with the command export EDITOR=vi.

The nano and pico editors tend to be more newbie-friendly than vi and emacs, as they give simple, common command help at the bottom of the screen at all times. If you find yourself "stuck" in vi or emacs by accident, you can exit emacs by typing Ctrl X followed by Ctrl C>.

For leaving vi without saving any accidental changes, just hit the Esc key to make sure you're in command mode (if it beeps at you, you were probably already in command mode), then type :q!and hit the Enter key. It's probably a bad idea to start trying to learn how to use either editor while editing your quota settings so you might want to just use pico or nano for now.

To edit grace period settings, you would use the -t option for edquota, by entering:

edquota -t

This allows you to set different grace period settings for different mounted partitions that use disk quotas.

To edit user or group soft and hard limits, use the -u or -g options with the name of the user account or group account whose quotas you want to edit. For instance, edquota -u foo will allow you to edit the quota settings for user "foo", while edquota -g bar will allow you to edit the quota settings for group "bar".

The -p option allows you to duplicate the settings of one user to another user. For instance, to use the same settings for user "baz" that you set for user "foo", you would enter:

edquota -p foo -u baz

This can be a timesaver when creating new user account quotas on a machine where everyone should have the same quota settings. The -p command option can be used to produce a simple one-line bash script to manipulate large numbers of accounts simultaneously, as well, when you become a bash scripting guru.

When editing quota settings, you will see that there are settings for "blocks" and "inodes". On typical Linux systems, blocks are units of one kilobyte. This determines how much disk storage space can be used by the user or group account whose quotas you are editing. The inode setting can be used to limit the number of files a given user will be allowed to use (typically, a few inodes are needed per file), and like the blocks setting it also has hard and soft limits, using the same grace period setting. Any limit settings that show a zero indicate that there is no quota enforced for that user or group account. It's common for hard and soft limits to be set for blocks, and no limits for inodes.

When you first start editing quota settings for users and groups, the configurations for each account should show a small number of blocks and inodes already in use (or a large number, if you are implementing quotas on a system that has already been in use for a while). These numbers should not be edited: only edit the hard and soft limit numbers when changing quota configurations. When you are done editing the settings, save them using the default filename given when edquota is invoked -- you should not have to choose any filename at all, but just save and exit from the editor you're using.

Quota management

Once quotas are in place, there are a number of additional tools you can use for more quota management tasks. For instance, the quotacheck utility is used to check the integrity of your quota database, the repquota utility is used to report summaries of quota usage, and the quota utility itself can be called by users to see the status of their own quota usage or by the root user to get information about any user account. For more information about each of these utilities, see the relevant manpages.

Finally, there is an additional toolset provided with some Linux distributions called quotatool. Depending on how much you work with disk quota management, it might be worth your while to investigate its use.

4 comment(s)