After installing (linux binaries) grass on my rh8 box,
during the initial run I get the following message:
Sorry, no access to <<user1>>.
Mapsets in location <spearfish>
----------------------
PERMANENT user1
note: you do not have access to any of these mapsets
----------------------
Hit RETURN -->
I have changed the permission bits in root and still I
cannot get a run.
You have to own the mapset directory; having write permission isn't
sufficient.
Additionally I cannot run the help commands ie d.rast
help or g.manual d.rast the system cannot see the
rast pages.
You can only run the commands within a GRASS session, so you have to
get GRASS to start first.
The manual pages will probably be stored in a directory which isn't
visible to "man"; the default is typically /usr/local/grass5/man. To
get "man" to see the files, you can either edit man.config (typically
/etc/man.config) or set MANPATH in your shell startup scripts
(/etc/profile, ~/.bashrc etc).
> > I have changed the permission bits in root and still I
> > cannot get a run.
>
> You have to own the mapset directory; having write permission isn't
> sufficient.
Why is that?
I doubt that anyone who is currently associated with GRASS can answer
that. Presumably the original author had his reasons.
However, one possibility is that it's part of a rather bizarre locking
mechanims. GRASS won't allow a user to have more than one session; if
a mapset can only be modified by its owner, and its owner is limited
to a single session, there's no chance of two sessions concurrently
modifying a mapset.
How can I setup a location/mapset to be able to share
data between users without having them using the same login ?
Note that you can read data from any mapset (use g.mapsets to add
additional mapsets to the search path), but you can only write to the
current mapset (the one which was selected in the startup screen).
You could just change the behaviour of G__mapset_permissions() in
src/libes/gis/mapset_msc.c, but then you need to find some other way
to prevent multiple sessions from making concurrent modifications to a
mapset directory (possibly resulting in corrupton and/or loss of
data).
However, one possibility is that it's part of a rather bizarre
locking mechanims. GRASS won't allow a user to have more than one
session; if a mapset can only be modified by its owner, and its owner
is limited to a single session, there's no chance of two sessions
concurrently modifying a mapset.
Unfortunately it's not a reliable mechanism in a NFS world.
A user with local home directories on two different machines can access
the same grass database on an NFS share from both login sessions.