sudo chmod o+x but still can't run as regular user

Question

I thought that doing sudo chmod a+x /root/file.to.execute or even sudo chmod 777 /root/file.to.execute should allow me—as a user—to run the program in question. But after doing this I still can’t run it as a regular user.

What else could be going wrong? Every tutorial I look at about chmod says to do exactly this.

---

edit:

$ sudo ls -l /root/.cabal/bin/pandoc
-rwxrwxrwx 1 root root 37443252 Feb 23 14:56 /root/.cabal/bin/pandoc

edit: Just calling /root/.cabal/bin/pandoc -v to remove other sources of error: just the simplest call to the program.

Answer 1

To execute a file /path/to/file (and access it in general) the user account must be able to get to it first, i.e., for all parents of file the user must have the x permission.

In your case, you would need to chmod +x /root /root/.cabal /root/.cabal/bin but a better approach would probably be to install cabal packages either locally (for the user that needs them) or globally if all users should have them. Please refer to the cabal manual for details.

Also, see related questions here and here for more background on directory permissions.

Answer 2

Could be all sorts of potential problems.

Knowing more details about what the program might do could be useful. For instance, a program might not be permitted to write to a directory on a file system that is mounted as read-only, even if the files specify that Unix-style permissions would allow the file to be overwritten (when it is mounted read/write).

Your Unix-style permissions settings for the file, that are set by chmod, look fine. I agree with that, based on the output you've shown. So let's try looking at some other things.

Some quick ideas: mount may have noexec (check the /root mount point if it exists; my guess is most probably not, in which case you'll want to check the / mount point)

Permissions caused by something else. e.g., first line of a script file says !#/bin/my-interpretor but you don't have permissions to run my-interpretor

If you're getting a permissions error, perhaps a file runs my-interpretor, but then the file runs another program which is erroring out.

Frank's answer notes SELinux. So there may be sources of permissions other than just what's on a file. If the file is a script file, try sourcing it. (That is: instead of running "/path/file", run ". /path/file" -- with a period and a space and then a filename. Or the "source" command; details might be shell-dependent.

Maybe another possible reason could be related to "ulimit -a"? (This may be a command internal to a shell, so don't just "man ulimit" -- instead, "man $SHELL")

Maybe some of those ideas are a bit off, but those are just some of the ideas that readily pop into my head. So, I'm not saying these are all possible answers, or even that all of these are definitely possible; they're just some ideas and maybe one of them is right.

Troubleshooting thoughts: Check log files. Check return value ( echo $? ). What if root runs the program? What if a person uses "sudo"? What if a person in "wheel" group runs the program?