Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I wrote a package, and would like to use /var to persist some data. The data I'm storing would perhaps even be thought of as an addition for /var/db.

The pattern I observe is that files in /var/db, and the surrounds, are owned by root. The primary (intended) use of the package filters cron jobs - meaning you would need permissions to edit the crontab.

  1. Should I presume a sudo install of the package?
  2. Should I have the package gracefully degrade to a /usr subdir, and if so then which one?
  3. If I 'opinionate' that any non-sudo install requires a configrc (with paths), where should the package look (presuming a shared-host environment) for that config file?
  4. Should I use /usr/lib as per the thoughts in this article?

Incidentally, this package is a ruby gem, and you can find it here.

share|improve this question
up vote 1 down vote accepted

If that package is installed as root it has access to /var.

If it's installed by a user (who can neither write to /var nor /usr) the default procedure is to set --prefix=$HOME/somedir in the configure script. Or you provide other means to set the directory to a location the user has write access to.

share|improve this answer

/var is a bit of a “whatever didn't fit elsewhere”. The structure is not intended to allow individual users to add to the hierarchy.

If your package is installed by an ordinary user, they would typically put the program, its static data and its dynamic data all under one directory somewhere under their home directory. I recommend packaging the program in a way that just works if you unzip it and run from there or run ./configure && make && make install, e.g. a structure like


If your package is installed by an administrator, then an application-specific directory under /var/lib is the usual place for dynamic data that is not specific to one user. Packages intended for system-wide use are normally provided in distribution-specific packaging formats (.deb, .rpm, …); the package build script takes care of setting up paths correctly.

share|improve this answer
I already have my app/package set to create a default config file and a store-file for the data-swapping it performs. I do see the pattern in some distros setup of /var/lib. Why not /var/db? – New Alexandria Oct 26 '12 at 2:55
@NewAlexandria /var/db is not in the FHS. Stick to FHS directories for your default packaging when distributing for Linux. About /usr/lib: use it for static, architecture-dependent data; use /usr/share for static, architecture-independent data such as Ruby source files (bytecode could be on either side: /usr/share because it's architecture-independent, /usr/lib because it's system-dependent as it depends on the interpreter version). Don't store any variable data under /usr: although it's rare nowadays it could be read-only. – Gilles Oct 26 '12 at 8:49

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.