UPDATE: between the suggestions made in comments, and Andrew Stacey's patient walkthrough/diagnostic, the problem was eventually solved by correcting a faulty environment variable in the bashrc. It's not entirely clear to me if this was the only problem all along, since I recall things not working even with a vanilla bashrc, but it does seem that the eventual problem lay in my ineptitude with paths rather than some exotic issue with permissions.

This may well be a duplicate of something that's already been covered here -- in fact it seems close to the problem described at "How does LaTeX find package files?" -- so I hope this is not too trivial.

I have just had to do a clean install (Ubuntu 12.04 if that makes a difference) on my desktop and after restoring files from my backup, set about reinstalling texlive by the naive apt-get method. Now I find latex test.tex is met with

This is pdfTeX, Version 3.1415926-1.40.10 (TeX Live 2009/Debian) entering extended mode (./test.tex LaTeX2e <2009/09/24> Babel and hyphenation patterns for english, usenglishmax, dumylang, nohyphenation, loaded.

! LaTeX Error: File `article.cls' not found.

while sudo latex test.tex works fine. I have tried restoring the bashrc to the one that was working before, but to no avail. Similarly, the advice suggested at answers to the question mentioned above doesn't seem to fix things; running texhash makes no difference, and purging and reinstalling also hasn't helped.

I guess I could add export lines to bashrc but since this was never necessary in any previous installation I had of TeXLive, I would like to know what I've done wrong this time.

  • I suggest install the Debian TeXLive 2009 from Ubuntu software center/synaptic manager/sudo temporarily. It will be a clean install( no need to tinker with .bashrc etc..). In the coming July/Aug install TeXLive 2013. Incase you are interested to do pretest TeXLive 2013. TeXLive 2012 is frozen now. May 2, 2013 at 2:49
  • 4
    What does kpsewhich article.cls return? If it doesn't find anything, or points to the wrong place, that's, well, not good. It is possible that you have reinstalled from your backup an old copy of texmf.cnf, which is causing some havok. That would be what I looked into first.
    – jon
    May 2, 2013 at 5:08
  • @jon It returns nothing. sudo kpsewhich article.cls returns /usr/share/texmf-texlive/tex/latex/base/article.cls - I'm afraid I'm puzzled as to how to intepret this
    – Yemon Choi
    May 2, 2013 at 7:40
  • @texenthusiast that doesn't help - after all, the methods you describe are more or less the same as doing a apt-get purge+autoremove+clean+install
    – Yemon Choi
    May 2, 2013 at 7:58
  • How to remove everything related to TeX Live for fresh install on Ubuntu? and reinstall texlive full 2009 sudo apt-get install texlive-full May 2, 2013 at 8:41

2 Answers 2


This looks very much like a permissions problem. I've encountered this when I've done an installation using tlmgr, though I'm surprised at its rearing its ugly head when installation is done using apt-get.

The Likely Problem

At some point in the installation, files were installed that were only usable by the root account. That is, ordinary users do not have permission to read the necessary files for latex to work.

In brief, every file and directory on a UNIX system has three sets of three permissions (sort of). The three sets are: owner, group, world and the three permissions are read, write, execute. In order to use a file or directory you have to have sufficient permissions to carry out the activity. Which permissions apply depend on your relationship to the file (or directory) in question. For the files installed in a TeXLive installation, the most likely situation is that you do not own the files (root does) nor are you in the same group as the files (probably something like admin) so the world permissions apply to you. When you do ls -l <file name> then the first block looks something like -rw-r--r--. It is the last three that therefore concern you. What you need is to have r-- for ordinary files and r-x for directories and executable files.

Diagnosing the Problem

To check this hypothesis, you need to find the permissions of (some of) the files. From the comments, the first thing to try is:

ls -l /usr/share/texmf-texlive/tex/latex/base/article.cls

With a bit of luck, this will complain:

cannot access /usr/share/texmf-texlive/tex/latex/base/article.cls: Permission denied

If so, it's a permissions problem. (It might be that the message is cannot open directory and that the path is only a part of the path given.)

Making sure it doesn't happen again

When software is installed, it tries to install it as permissively as possible so that any user can use it. However, when you create a file in your own directory you don't want this behaviour: you want it so that you can use it, but no other user can do so. Unfortunately, the system can't tell the difference between these two cases and just sees the instruction "Create a file/directory". Now you can say "Create a file/directory with these permissions" but then that's hard for a user to override if they want to do a local installation. So what happens is the request is "Create a file/directory and suggest these permissions". The "suggestion" is then matched against something called the umask to get the real permissions. You can think of the umask as a polariser: it only allows certain permissions to get through.

Permissions are stored as octal numbers, with 4 = read, 2 = write, 1 = executable. An installer might say "This is an executable file, I suggest permissions 755" meaning everyone can read and execute it, and the owner can write to it. This is then checked against the umask to see which of these permissions can be set. A common user umask is 077. This allows through all user permissions but none of the others so the resulting file permissions are 700. On the other hand, the standard umask for a system installation is 022. This guards against files being writeable by non-owners but otherwise lets everything else through. Then the 755 would work.

What is likely to have happened here is that the umask in effect was 077 instead of 022. This can sometimes happen when using sudo since then the umask is not changed from its user setting. To avoid this happening again, the command umask 022 changes the umask to 022 (umask by itself displays the current setting) so this can be done before the installation, and then reset afterwards.

(However, as I said, I'm a little surprised at this happening with apt-get since I would expect that to be umask-savvy and sort itself out. tlmgr does not, though.)

Fixing Things Afterwards

Deleting and reinstalling is one option, but given the size of TeXLive it's a bit of a sledgehammer. A little more refined is fixing the permissions.

The first thing to do is work out where the problem starts. To do that, start with the article.cls path that you have and find out where you first lose permission:

ls -l /usr/share/texmf-texlive/tex/latex/base/article.cls
ls -ld /usr/share/texmf-texlive/tex/latex/base
ls -ld /usr/share/texmf-texlive/tex/latex
ls -ld /usr/share/texmf-texlive/tex
ls -ld /usr/share/texmf-texlive
ls -ld /usr/share

(If you get to the bottom one and still have problems, then you have big problems.)

Most likely, it is /usr/share/texmf-texlive. Next is to get a sense of the scale of the problem:

sudo find /usr/share/texmf-texlive -not -perm -004

This gives you a list of all the files and folders below texmf-texlive which are not world-readable. It might just be that it is only the top directory that has the wrong permissions, if so then do the following:

  1. Give a small "whoop" of joy
  2. sudo chmod 755 /usr/share/texmf-texlive

If the list is very short, you can do something similar to the above on each of the files/directories. The rules are that the permission to give is whatever the owner has without the writeable one. chmod can take "symbolic" permissions so you don't have to remember the octal notation (symbolic is actually better here as the syntax for adding permissions is simple). In short:

  1. Do sudo ls -l <filename>
  2. Examine the first bit, it will start with one of drwx, -rwx, or -rw-
  3. If one of the first two, do sudo chmod go+rx <filename>
  4. If the last one, do sudo chmod go+r <filename>

If the list is quite long, going through each one is a pain. Fortunately, find can iterate through the list of files and execute a command on each one. We have to do it twice to fix the two situations.

First, we go through and add the read bit to all files and folders.

sudo find /usr/share/texmf-texlive -not -perm -004 -exec chmod go+r {} ';'

Then, we go through and add the execute bit to all executable files and all folders.

sudo find /usr/share/texmf-texlive -perm +100 -not -perm -001 -exec chmod go+x {} ';'

At this point, everything should have the right permissions.


There is a faint chance that there are some files which aren't meant to be world readable in the TeXLive tree, or executable files which aren't meant to be executable by anyone but root. However, I doubt that.

(Unfortunately, as I can't guarantee that my last TL installation didn't need this permission fix, I can't trust that the permissions in my installation are all as they were intended so I can't test this myself.)

  • Thanks for the very thorough walkthrough. (How does one get a quote environment in comments?) Unfortunately ls -l /usr/share/texmf-texlive/tex/latex/base/article.cls doesn't return a permissions error but gives me -rw-r--r-- (owner and group are root)
    – Yemon Choi
    Jun 5, 2013 at 16:47
  • 2
    Trying to track down some difference between the user account and the root account! Try kpsewhich -show-path .cls Jun 5, 2013 at 19:59
  • 1
    Bingo - user account just has my personal TEXINPUTS folders (as set in .bashrc) while root gives loads, including /usr/share/texmf and /usr/share/texmf-texlive
    – Yemon Choi
    Jun 5, 2013 at 20:23
  • 1
    Does the "Bingo" mean that you've solved it, or just that you're on the right track? If the former: Great! If the latter, I would now try removing all TeX-related environment variables and see if that works, then add them back one by one to see which one breaks things. Jun 5, 2013 at 21:11
  • 1
    Glad you got it sorted. Now, this question-and-answer is a bit of a mess since my answer wasn't the solution. It's also possible that given what the problem was, the correct thing to do is close as "too localised". However, having written out the answer I'm loathe to do that! What we could do is edit your question and my answer to make them both a bit more generic. Something on the lines of "I've installed TeX but can't compile any documents, though root can do so. What can I do?" whereupon my current answer is one possibility but environment variables is another which could be added. Jun 6, 2013 at 9:03

I had the same diagnose and same solution as Yemon Choi (and Loop Space) with TEXINPUTS being defined in the wrong way. My .pam_environment reads


Adding the colon at the end


corrects the problem.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .