Hi, I compiled linuxsampler for PureDyne, and it gave me no errors. I have fulfilled all its dependencies, and when I try to run it, it says, "permission denied: llinuxsampler".

I've noticed that all the files I built are owned by the group "mail". I can't change their groups using chgrp, because everything is on a vfat partition. Does it matter that the group is "mail" for all the built files? Is that why I'm having my problem? Can't root open up files owned by the mail group? If not, is there any workaround for changing groups on a fat partition? Maybe there's a way to copy all the files and change there group at the same time...

Thanks!

Is the partition mounted as noexec?

No, it isn't.

Not wishing to state the obvious, but the executable does have the execute bit(s) set, doesn't it? (try 'chmod 755 linuxsampler').

Yeah, I chmod 777'd it. I'm pretty convinced now that it has to do with the group. I'm copying it over to a USB thumb drive with EXT3 as the filesystem. I noticed that when I do so it changes the group for me! Unfortunately, this process is going very slowly, since the laptop I'm using only has USB 1.0

Are you sure? Sometimes noexec is enabled by other options (such as user). To be sure, try forcing the exec option (as root)
As for actual ownership of files, root should be able to read and/or write any such files regardless of owner (as long as they have appropriate modes).

I somehow doubt it is a noexec problem. It is mounted just like all the other modules on the system.

on typing mount:
"/mnt/hd1/2/dyne/modules/sampler.dyne on /opt/sampler type squashfs (ro,loop=/dev/loop10)"

You may have trouble if you use a windows filesystem to store data for a linux application, if that application is concerned with the users and groups who own, or are allowed to access, the files. The reason is that win filesystems have no knowledge of the concepts of "Owner" "Group" "Other".

The (linux) mail program is likely to be concerned about this as mail is generally considered to be "private" data. If it is unsure that you have permissions to read the data, it will not allow you to do it. Hence, perhaps, "Permission Denied".

Maybe. If you chown / chgrp (maybe with the -R option) the mountpoint of your filesystem, while the filesystem is mounted, it might be happy. You'll need to make this change to owner / group as the root user.

I don't have this problem as I now have only linux at home. I just need to ensure that whenever I create a new account on a new PC that the new distro/PC has the same UID numbers associated with usernames as all the others. Failing to ensure this led to several reinstalls until I understood the concept. Now, it's almost intuitive, and I can appreciate that it is a sensible policy.

Let us know how you get on with the ext3 filesystem.
These things are sent to annoy us, but with permissions, there's always a "workaround", so persevere

Thanks for the reply and inspiration.

I'm not quite sure that I understand, though. If I recursively change the owner or group from the root mount point (/ ?) wouldn't I be changing the permissions on all files in my system in one fell swoop? To me this sounds like a bad idea.

I'm beginning to think this is only one stumbling block before I can get this module working (I'm also having linking problems with .so files).

If I actually finished, it would be nice to get away from the computer, but for me, a lot of the fun is hacking around and learning. Linux is very flexible, and I'm increasingly surprised by how the usability and quality of Open Source and FLOSS software is improving!

I would indeed be a very bad idea. What I meant was chown the mountpoint of your mounted vfat partition, or chgrp the mountpoint of your mounted vfat partition. NOT your root filesystem!
I should have made that clearer, sorry.

This could also be the source of a “Permission denied” error. Is the executable in your native format (e.g., if you are on x86 is it an x86 ELF)? Is the dynamic linker/loader (ld.so) correctly set up? Are all the shared object files mentioned in the dynamic section of the executable (find these with “ldd linuxsampler”) readable by ld.so, and also in the same ELF format (check each one with the file command)?

What I usually do is type the name of that .so file in it's entirety into the search field of RPM Search Advanced and select the OS type. Then yum install what package the search engine matches up against your query.
Usually solves that issue, not sure about linking to compiled apps though.

All of the problems were caused by permissions on a vfat filesystem. I repartitioned and used ext2. Now everything works fine, including the symbolic links. Yaaay!

Excellent