the strengths of
Linux, as well as other Unix-based operating systems, is
its capabilities as a multi-user environment.
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.
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.
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.
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.
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.
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
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
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 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:
Disk quotas for user foo (uid 1000): none
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.
is an example of installing quota on
a Debian GNU/Linux system, using the apt-get command for the APT software
$ apt-get install quota
Reading package lists… Done
Building dependency tree… Done
The following NEW packages will be installed
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.
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.
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.
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.
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.
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
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 ]
should double-check the location of your quotaon command. On some systems,
it may not be in /sbin.
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.
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.
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
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:
# cd /home
# touch quota.user
# touch quota.group
# chmod 666 quota.user
# chmod 666 quota.group
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
- 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
- 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.
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>.
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.
edit grace period settings, you would use the -t option for edquota, by entering:
allows you to set different grace period settings for different mounted
partitions that use disk quotas.
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
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.
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.
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
is invoked — you should not have to choose any filename at all, but just save
and exit from the editor you’re using.
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.
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.