I'm quite new in the UNIX world, so feel free to let me know if my question is silly.

So-called Filesystem Hierarchy Standard states that the /var directory is supposed to keep data like logs and caches of including but not limited to local packages:

/var contains variable data files. This includes spool directories and files, administrative and logging data, and transient and temporary files.


/var is specified here in order to make it possible to mount /usr read-only. Everything that once went into /usr that is written to during system operation (as opposed to installation and software maintenance) must be in /var

I'm primarily wondering how should it work in local multi-user system. /var is kind of global directory for a system, and all cache-data and logs of all users appear to be shared among them. Isn't it considered wrong in any way? I mean that programs (packages) being launched on behalf of different users will use the same cache, let alone the fact that all local user can read logs and look through cache-data of each other. Please help me to understand that concept. Thanks.

  • 3
    I believe that's what people use /home or /tmp for.
    – Jeff Schaller
    Jun 12, 2017 at 20:30
  • 1
    There are many files in /var that I can't read as an ordinary user. Jun 12, 2017 at 20:35

3 Answers 3


The /var directory is for system logs and caches. Individual user logs (rare) and caches (frequent) are kept in the user's home directory.

  • 1
    Could you elaborate please on why you think so? Is there any official document stating that /var should keep only system cache? FHS doesn't seem to say the same. I also found another relevant discussion where /var/cache is considered decent for a third-party Ubuntu application cache: superuser.com/questions/474157/… Jun 13, 2017 at 19:00

Most of the underlying issues can be usefully explored with a single example, such as the printer. Alice doesn't really want the lpr(1) to block until Joe finishes printing out his thesis. The system doesn't want Alice deleting her file before it's printed. The obvious solution is to place a copy of the file in a spool directory until it's safely on paper.

Traditionally print jobs were queued in /usr/spool/lp. The problem, as noted, is that this effectively prohibits mounting /usr read-only. Keep in mind that the issue extends to every queue (mail, uucp, etc) and all of the system logs. This causes a secondary problem, namely that the size of /usr is totally independent of the size of the operating system install. Imagine you're provisioning a new system which has 35MB of binaries. How large do you need to make the /usr partition? Trick question! 35MB plus required time to retain logs times the average use of email, printers, newsreaders.

Moving everything to /var neatly solves the read-only issue, and makes significant inroads on the administrative nightmares. For one thing it allows easy measurement of how much space that data is using. It's also quite a bit less painful to extend or replace one single partition than worrying about /usr/spool, /usr/log, etc.

Storing system state spread amongst home directories buys you nothing but increased complexity. Instead of a single, global directory to manage permissions on you have possibly hundreds of individual ones. On top of that you can add the overhead of continuously scanning through all those directories.

Less obvious is the fact that home directories are not system specific. Network mounted ones are fairly common. Chances are when printing a file you only want it printed where you're logged in, not every machine your home directory is mounted on. Availability is an issue here too, as home directories can vanish if the file server craps out. Or to add a more modern twist, if the home directory is encrypted and the system can't read it.

Historically global storage has served as a cache for public information. In the absence of a news server usenet articles were downloaded in batches and stored in a central location. After all, there's no reason to duplicate the large news feed across multiple users. Centralized queues also serve as a buffer for incoming information. Consider the mail queue, which may not be able to deposit mail into your encrypted home directory. (Availability again) Or the case where you get a ton of spam while away on vacation. Should the system discard all messages after you exceed your disk quota, or save them and let you sort it out later?


/var is kind of global directory for a system, and all cache-data and logs of all users appear to be shared among them.

This is partially incorrect. Not all cache and logs are stored under /var, and what is stored there is not necessarily shared by all users. Applications and/or the OS own what is stored in /var.

The only exception is a directory which is effectively shared and writable by all users: /var/tmp. Users and/or application deciding to store something here can still protect the subdirectories and files they create with unix file permissions.

I mean that programs (packages) being launched on behalf of different users will use the same cache, let alone the fact that all local user can read logs and look through cache-data of each other.

No, different users generally use different cache. There are also cases where a common cache is a plus.

When confidential / personal data is stored under /var, this data is protected by the application so the users are not granted the right to see other people's data; e.g. the mail spool is not readable by (non root) users.

  • Thanks for the answer. Does it mean that application create it's own group while installing? Otherwise i don't completely understand how it can limit access Jun 13, 2017 at 19:03
  • Applications (services) storing files under /var run under either the root or a technical account, not actual user's account. They also belong to technical groups, not user's group. Access limitation is done through Unix permissions (read/write/execute-access = rwx) and are tight to these users and groups ids.
    – jlliagre
    Jun 13, 2017 at 21:37

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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