On Tue, 17 Aug 2004, Matt Senjem wrote:
> Sorry if this question has been asked a million times already, but I am
> having some sort of permissions issue running fslview. I installed the
> redhat 9 binaries, following the instructions on the download page. The
> problem I am having, is that I need to become root in order to run
> fslview. All the other fsl programs seem to run fine except fslview.
> When I try to run it as a non-super-user, nothing happens. Any
I may be speaking out of turn here, especially as I don't use RedHat, but
if this is a standard Linux/Unix permissions issue then perhaps I can shed
some light on it :-) I dare say that it is a frequently-asked-question
so a search through the archives may be fruitful. In the meantime...
As root, navigate to the fsl installation area (eg. /usr/local/bin/fsl)
and do a
chmod -r 755 bin
to recursively give read and execute permissions to all
in the binary subdirectory for everybody (root will also have write
permissions to files.) Depending on your chmod implementation,
--recursive might be required, rather than -r
By way of some background, if needed, and apologies in advance if not...
Linux & Unix implement a three-tiered scheme for permission to do
"something" with a file (or a directory.) They have the concept of
"owner", "group" and "other" (sometimes referred to as "World"). Within
each of the above, permissions are given - or denied - to "read", "write"
and "execute" the file. For simplicity these permissions are most often
referenced as three "octets" - three octal numbers, which range from 0 to
7 made up of:
4 = permission to read
2 = permission to write/modify
1 = permission to execute (or to go to the next level in directories)
When you do a directory listing with the -al option (display all files and
their attributes) you see this information as, for example,
drwxr-xr-x 2 dsbrown dsbrown 4096 Feb 4 2004 bin
This case is a directory, the "bin" directory within my fsl installation.
The leftmost characer, "d", denotes this and it is irrelevant to the
discussion. The next three characters, r, w and x relate to the values
described above (4, 2 and 1). Because this is a directory, the "x's"
mean that we can go to the next level. For a file, these mean that it
can be executed, in the above case by the owner (dsbrown), the group (also
dsbrown, but RedHat may put all users into the "users" group, I don't
know) and everybody else.
Getting back to the numerical values, if the owner had read and execute
permissions the overall value would be 5 (made up of 4 + 1). In the
directory listing this would display as r-x If the group to which the
owner belonged had only permission to read the same file, the value would
be 4 (in a directory listing, r--). If the "other" users (the rest of
the World) had no permissions to do anything with it, the value would be
0, or --- in a lsiting. Overall the "mode" or value for this file's
permissions would be 540 (owner, group, world rspectively) showing as
For more authorative information regarding Linux/Unix permissions and
how to work with them, the Linux Documentation Project (do a Google,
Yahoo, etc search for Linux LDP) has some excellent reference guides.
Hopefully the first few lines of this reply contained the answer to your
problem. I have implemented fsl only from sources and so the
permissions issues have not arisen for me.