Why can't I execute files produced by g++ in Suse 9.1?

cedar · 08-16-2004, 11:01 AM

I wrote a simple c++ program and compiled it fine with g++ but when I try to execute the executable file I get a "Permission denied" error. I checked the permissions of the file and my user and group are both authorized to execute, but I get the error even as root. Thanks for any help.

cheers

Dark_Helmet · 08-16-2004, 11:42 AM

We'd need to know a little more about what you're doing, but I'll go into a common problem.

When you try to run the command, are you specifying the path to it? Your shell normally does not include the current directory in its search path. So, to run something in your current directory, you need to preface it with "./".

As a walk-through example, this code could be stored in a file named simple.cpp:

Code:

#include <iostream.h>
using namespace std;

int main( void )
{
  cout << "Hello World!" << endl;
  return 0;
}

Compile the program with: g++ -o simple simple.cpp

Run the program with: ./simple

If you still get a problem with permissions, do an "ls -l" and make sure the compiled program has execute permissions set. Nobody (including root), can execute a program if it's execution permission is not set.

shyamsg · 08-16-2004, 11:57 AM

I think that if the current directory is not in the path list, you should get an error of file/command not found and not "Permission denied". If you checked the permissions on the file for your user and group and are sure that the permissions are set to execute, I cant see any problem. Please send more details.

Shyam

cedar · 08-16-2004, 12:10 PM

I did "ls -l" and confirmed that the file is executable. I can't execute any of the programs I've compiled with g++ and all of them have the same permissions, all with execution permission and all give the same Permission denied error...even as root.
As much as I like Suse, this really puts a damper on things. I may have to go back to Mandrake 10.

cheers

Dark_Helmet · 08-16-2004, 02:01 PM

One possibility that came to mind (it could be a long-shot):

The partition you're developing on, is it a "normal" partition or is it specially mounted? What I'm getting at is this: the mount command allows you to mount a partition with the "noexec" option, meaning (obviously) you can't execute programs on that partition. Check your /etc/fstab file to see if this is the case. If you partition is a shared FAT32 partition between Windows and Linux, then it might be default for Suse to deny execute permissions to those partitions.

Like I said, it might not apply, but I can't think of anything else off-hand that might cause this type of behavior.

laceupboots · 08-16-2004, 03:08 PM

I'd try chmod 777 on the file anyway and see if that helps. Might be a problem with the compiler.

cedar · 08-16-2004, 03:51 PM

Dark Helmet-
That's almost exactly it. The partition is a Fat32 partition I share with Windows, but there's not a noexec option in the fstab and the umask=0000 so there shouldn't be a problem there. I've got rwx on all the files on the drive, but can't execute anything. I can't figure out how to fix it. I find that if I copy the file to my home partition it works fine. Thank you for your insight and thank everyone for trying to help. I'll keep looking for a solution and let you know what happens.

cheers

Dark_Helmet · 08-16-2004, 04:23 PM

Hmmm... I think we're real close to the finish line on this one. Do me a favor and try this command in the shell (you'll probably have to be root):

mount -o remount,exec device mount_point

Obviously, replace device and mount_point with the values associated with your FAT32 partition.

If you perform that command, and you're allowed to execute files afterwards, then I would bet a large sum of money something, somewhere is mounting that partition with the noexec attribute. If this is the case, I'd suggest browsing through your startup scripts (assuming the partition is mounted automatically). I can't say for sure where they're located in Suse, but my system (Red Hat) stores them in /etc/rc.d/init.d. Rather than trudge through all of them manually, you could do something like:
grep mount_point /etc/rc.d/init.d/*

Then double-check any matches grep spits out. This could end up being very tedious and time-consuming. It might end up that you follow a breadcrumb trail: one script calls another script, which calls another, etc. Then again, it could be just a simple edit.

Another option (not the cleanest) is simply to remount it automatically. I'm sure Suse has some file/script whatever equivalent to Red Hat's rc.local. rc.local is just a convenient spot for the user to add startup commands after everything else in the system has started. So, if the remount command works, you can just slap it into that file. Again, this really isn't fixing the root cause of the problem, but addressing the symptoms. However, if it works, and you're happy with it, then go for it

If the partition is not mounted automatically, check the configuration for whatever utility you're using to perform the mount. It might have some undesireable attributes tucked away in a hidden config file.

cedar · 08-16-2004, 04:41 PM

What I ended up doing was adding exec to the fstab for that partition rather than just making sure it didn't have a noexec. It worked. Thanks for all your help. I'll be back again I'm sure with something else.

cheers