5

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.

2
  • You're not doing this on an NFS volume by chance, are you?
    – FatalError
    Feb 7, 2012 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
    Feb 8, 2012 at 11:28

3 Answers 3

7

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.
3
  • 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
    Feb 8, 2012 at 15:56
  • worked for me too while installing ruby from source. Initially the build location was ~/downloads/ruby-2.4.0. ./configure, make worked, but sudo make install gave error: :~/downloads/ruby-2.4.0$ sudo make install 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. ``` . Ran the above steps by copying source files to /tmp and sudo make install worked fine. /usr/local/src, /usr/src did not work due to permission errors Feb 12, 2017 at 2:58
  • another workaround is to sudo chown the target directories to yourself, run the install, and sudo chown them and the installed files back to root.
    – malcook
    Jun 8, 2022 at 19:23
0

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

-1

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.

1
  • 1
    I am the owner of the files. They live in my home directory.
    – Wojtek
    Feb 8, 2012 at 11:29

You must log in to answer this question.

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