Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

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 have a most annoying question about building from sources. I've searched for an answer for a long while and nowhere can I find one... I've compiled software from sources before and this just baffled me.

So I am trying to install python 2.7.2 from sources. I can do a successful ./configure, also make seems to run fine. But when I do sudo make install, I get a variety of errors...

First, sudo make install gives me this:

make: stat: GNUmakefile: Permission denied
make: stat: makefile: Permission denied
make: stat: Makefile: Permission denied
make: stat: install: Permission denied
make: *** No rule to make target `install'. Stop.

So I did chmod +rx Makefile*. To no avail.

Then, sudo ls . says

ls: cannot access .: Permission denied

Then ls -d . says the permissions are drwxr-x---

Then, as a desperate measure, chmod +rx .. That gave me:

make: stat: Modules/ Permission denied
make: *** No rule to make target `Modules/', needed by `Makefile'. Stop.

So some progress... What is happening here? It looks like some sort of permission problem. I presumed that sudo would be the solution but clearly there is something else going on here... I tried sudo -s but I get those permission problems all over again...

I am using Ubuntu 10.04LTS.

share|improve this question
You're not doing this on an NFS volume by chance, are you? – FatalError Feb 7 '12 at 17:28
Yes, I am doing it on an NFS volume. I am the owner of the files. My home directory is pulled off NFS. And my files are somewhere on that mount. I am trying to install on the local machine (so, compile files on my NFS mount, install on local computer, where I am on the sudoers list). – Wojtek Rzepala Feb 8 '12 at 11:28
up vote 3 down vote accepted

I believe what you are hitting is actually an NFS policy called "root squash". It's not uncommon for users to need root on a particular host, but you don't want them to have the same sort of privileges on the shared NFS volumes. Thus, giving local root access doesn't allow a user to run roughshod over any mounted NFS volumes and access/modify the files of other users -- the NFS server will map root's uid from 0 to 65534 (nobody), which is why you can't even list the directory in your on example.

So, that leaves you with a couple options:

  1. You can try to make all the files accessible to nobody in your build by doing a chmod -R o+rw . at the top level directory, giving "others" read/write permissions on your files (may or may not be enough -- for example you might need to o+x directories if it needs to search them).
  2. If you have access to the NFS server's /etc/exports file, then you could disable root squash (perhaps not a great idea).
  3. Just build in a local directory like /usr/local/src, /usr/src, /tmp etc, or just create your own local directory (you can even make it owned by your user) like /scratch/myuser. This is probably the option that causes the fewest headaches.
share|improve this answer
Thank you! That worked perfectly. I used option 3 as it was the easiest (and 2 was not possible). It makes much more sense now... – Wojtek Rzepala Feb 8 '12 at 15:56

If your are using sshfs, mount using -o allow_other option

$ sudo sshfs -o allow_other hostfolder localfolder

before that you have to set user_allow_other in /etc/fuse.conf

share|improve this answer

Try chown-ing it to your user. That is, use "sudo chown user ./*" (replacing user with your username) when in the directory and it will change the owner of all the files in the directory to you.

share|improve this answer
I am the owner of the files. They live in my home directory. – Wojtek Rzepala Feb 8 '12 at 11:29

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.