group id 46 belongs to plugdev which contains all users that can mount drives.
The rights shown by ls -l look like:
drwxrwxrwx 5 root plugdev 32K 2009-03-02 20:01 transfer
-rwxrwxrwx 1 root plugdev 0 2009-07-07 23:11 video.flv
When I start GRASS trying to access the GRASS data base at /media/daten/grassdata it says "ERROR: MAPSET PERMANENT - permission denied" and the GUI would abort.
Please inicate me how I need to set my permissions on the mounted drive that GRASS can use the data.
I do not encounter such problems with other programs, though.
group id 46 belongs to plugdev which contains all users that can mount
drives.
The rights shown by ls -l look like:
drwxrwxrwx 5 root plugdev 32K 2009-03-02 20:01 transfer
-rwxrwxrwx 1 root plugdev 0 2009-07-07 23:11 video.flv
When I start GRASS trying to access the GRASS data base at
/media/daten/grassdata it says "ERROR: MAPSET PERMANENT - permission
denied" and the GUI would abort.
Please inicate me how I need to set my permissions on the mounted drive
that GRASS can use the data.
You must be the owner of the directory selected as the current mapset.
A FAT/VFAT partition mounted by root must be mounted with the uid=
option to set the owner.
Alternatively, you can disable the checks in the source code and
re-compile. The checks are in G__mapset_permissions and
G__mapset_permissions2 in lib/gis/mapset_msc.c. This isn't recommended
on a multi-user system, as it can result in a user inadvertently
creating directories which the mapset's owner cannot delete or rename.
Hello,
thanks a lot for the answer (on the weekend)
You must be the owner of the directory selected as the current mapset. A FAT/VFAT partition mounted by root must be mounted with the uid=
option to set the owner.
OK. I was able to get access using the right uid in fstab.
But let's say that more than one person uses this computer.
What is the best way to handle this?
I cannot log in, change the uid in fstab and reboot and longin with another user account.
Alternatively, you can disable the checks in the source code and
re-compile. The checks are in G__mapset_permissions and
G__mapset_permissions2 in lib/gis/mapset_msc.c. This isn't recommended
on a multi-user system, as it can result in a user inadvertently
creating directories which the mapset's owner cannot delete or rename.
Could this not be converted in a configuration parameter?
See the following use case:
A desktop/notebook used by a group of people. Of course, these collegues would not work on this machine simultaniously but log in at different times with different user names.
> You must be the owner of the directory selected as the current mapset.
> A FAT/VFAT partition mounted by root must be mounted with the uid=
> option to set the owner.
OK. I was able to get access using the right uid in fstab.
But let's say that more than one person uses this computer.
What is the best way to handle this?
Use a filesystem which was designed for a multi-user OS.
> Alternatively, you can disable the checks in the source code and
> re-compile. The checks are in G__mapset_permissions and
> G__mapset_permissions2 in lib/gis/mapset_msc.c. This isn't recommended
> on a multi-user system, as it can result in a user inadvertently
> creating directories which the mapset's owner cannot delete or rename.
Could this not be converted in a configuration parameter?
It could, but that replaces one problem (using FAT filesystems on
Unix) with another (users accidentally trashing other users' mapsets).
See the following use case:
A desktop/notebook used by a group of people. Of course, these collegues
would not work on this machine simultaniously but log in at different
times with different user names.
Any solutions?
The ideal solution is to skip the ownership check on filesystems which
don't have any concept of ownership. Unfortunately, I'm not sure how
to detect that.
Use a filesystem which was designed for a multi-user OS.
It could, but that replaces one problem (using FAT filesystems on
Unix) with another (users accidentally trashing other users' mapsets).
See the following use case:
A desktop/notebook used by a group of people. Of course, these collegues would not work on this machine simultaniously but log in at different times with different user names.
Any solutions?
The ideal solution is to skip the ownership check on filesystems which
don't have any concept of ownership. Unfortunately, I'm not sure how
to detect that.
> It could, but that replaces one problem (using FAT filesystems on
> Unix) with another (users accidentally trashing other users' mapsets).
>
>> See the following use case:
>> A desktop/notebook used by a group of people. Of course, these collegues
>> would not work on this machine simultaniously but log in at different
>> times with different user names.
>>
>> Any solutions?
>
> The ideal solution is to skip the ownership check on filesystems which
> don't have any concept of ownership. Unfortunately, I'm not sure how
> to detect that.
I can't see how statvfs() could help. statfs() might help, although
it's Linux-specific. getmntent() is another option, although I don't
know how to reliably get the path to the mtab file (it's not safe to
assume that it's /etc/mtab; some systems put it in e.g. /var/run/mtab
so that the root filesystem can be mounted read-only).
