Super User is a question and answer site for computer enthusiasts and power users. 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 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/config.c.in: Permission denied
make: *** No rule to make target `Modules/config.c.in', 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

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
1  
I am the owner of the files. They live in my home directory. – Wojtek Rzepala Feb 8 '12 at 11:29

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

You must log in to answer this question.

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