QGIS: Permissions on GRASS LOCATIONS

[micha]

Two GRASS datasets are included: spearfish60 and nc_spm_08. In each the PERMANENT mapset and landsat mapset are not writeable by 'user'. WHile this is OK in GRASS itself (PERMANENT mapset is not necessarily writeable by everyone), It is causing a crash of QGIS with the error:

Cannot get projection
Cannot run module
Command:...qgis.g.info
info= ... permission denied

The three offending directories are each symlinks to /usr/local/share/grass/.... These directories have permissions i.e.:

drwxr-xr-x 4 root users 4096 2012-02-23 00:49 spearfish60

A workaround might be to do in install_grass.sh:

chown -R $USER_NAME.$USER_NAME "/usr/local/share/grass/nc_spm_08"
chown -R $USER_NAME.$USER_NAME "/usr/local/share/grass/spearfish60"

I suppose the problem is in the QGIS GRASS plugin. The above is not ideal but it avoids the error and crash when loading layers from the PERMANENT mapset.

[epifanio]

+1 to apply this change.

creating new mapset/location in the grass data directory is common practice for me, when testing/using/demostrating grass.

Thanks.

[micha]

Replying to epifanio:

+1 to apply this change. creating new mapset/location in the grass data directory is common practice for me, when testing/using/demostrating grass. Thanks.

Creating a new LOCATION/MAPSET in the QGIS GRASS plugin seems to work fine. The problem appears only when trying to load layers from the existing PERMANENT mapsets in nc_spm_08 or spearfish60 LOCATIONS.

[hamish]

Hi,

this is a known bug in qgis, it does not support multi-user/collaborative GRASS locations. still unfixed :-(

 http://hub.qgis.org/issues/2947

this is important because it means that it can't be used for teaching qgis+grass in the classroom setting when the common source data is over NFS, Samba, or sshfs link; a typical use case.

unfortunately, making the user account the owner of the files* is not a healthy workaround, it's a no go for the ISO. qgis needs to be fixed.

[*] or be owner of anything in /usr/local/ for that matter

I assume qgis gives the permission denied error because it is trying to write something to the mapset? for a read-only task what is it trying to open for write and why?

cheers, Hamish

[micha]

Replying to hamish:

Hi, this is a known bug in qgis, it does not support multi-user/collaborative GRASS locations. still unfixed :-(  http://hub.qgis.org/issues/2947 this is important because it means that it can't be used for teaching qgis+grass in the classroom setting when the common source data is over NFS, Samba, or sshfs link; a typical use case.

Is this use case relevant to the LiveDVD?

unfortunately, making the user account the owner of the files* is not a healthy workaround, it's a no go for the ISO. qgis needs to be fixed. [*] or be owner of anything in /usr/local/ for that matter I assume qgis gives the permission denied error because it is trying to write something to the mapset? for a read-only task what is it trying to open for write and why?

Attached are screen shots of the error. Looks like it's failing on setting the region.

How about putting the North Carolina and Spearfish datasets right under ~/user/grassdata instead of a symlink to /usr/local/share ??

cheers, Hamish

[hamish]

Replying to hamish:

this is important because it means that it can't be used for teaching qgis+grass in the classroom setting when the common source data is over NFS, Samba, or sshfs link; a typical use case.

Replying to micha:

Is this use case relevant to the LiveDVD?

yes, it's specifically intended to be used for quickly seeding a computer lab for workshops and tutorials.

I assume qgis gives the permission denied error because it is trying to write something to the mapset? for a read-only task what is it trying to open for write and why?

Attached are screen shots of the error. Looks like it's failing on setting the region.

I played around with it a bit more. As far as I can tell to get it to work the user must be the owner of the PERMANENT mapset directory, but not any files within it. Full write permission is not enough, and AFAICT no files are actually written within the dir during the process (the stat mtime on the directory does not change, which it would if you created then removed a temporary .gislock file or so within it). Also I noticed with the user owning the PERMANENT/ directory that you could then open read-only maps from other mapsets (ie nc/landsat/) just fine. perhaps a glibc call to access() is checking for permissions wrongly? (the user must actually own the Mapset directory they open, not just have write permissions there)

QGIS should not be changing the region except if the user explicitly runs the g.region module; it can use the GRASS_REGION environment variable to locally override it without touching the disk. But since no file is written to PERMANENT I don't think that's the case (and anyway user1 is the open mapset so that should be the one being modified)

How about putting the North Carolina and Spearfish datasets right under ~/user/grassdata instead of a symlink to /usr/local/share ??

It is undesirable to make the disc dependent on the user account, & so far we've pretty much managed to make just the desktop setup and some superficial program configs rely on the dot files in that account. (mysql/postgres DB permissions might be an exception to that)

Also, wrt my earlier "no go" comment, I've never been 100% clear on this but AFAIU for the ISO version it loads /home/user into RAM(?) so there is a reason to keep ~user/ just containing very small files. One thing I'm not clear on is if that applies to every file user explicitly owns or just the home dir. The general work around we use is to make the files group writable and owned by the "users" group. The ISO-version remakes the user account at final-build time which wipes the slate clean on a number of things.

I did try copying the grass Locations into ~user/, but the DVD ISO (run in a VM) became highly unresponsive after I tried to open some maps. I can't say for sure that this was direct causation, but that's the only time I've seen that behaviour.

for now a "just make the darn thing work" end user work-around is a slight modification of your earlier suggestion to just change ownership of the PERM dir itself:

sudo chown user /usr/local/share/grass/nc_spm_08/PERMANENT
sudo chown user /usr/local/share/grass/spearfish60/PERMANENT

but as a general solution it is not satisfactory so I wouldn't like to include that in the install script. Understanding/fixing the bug in qgis may lead to a better work-around in the current version.

regards, Hamish

[hamish]

another work-around: open a terminal and do "sudo qgis", but then you'll have to make a mapset somewhere owned by root.

[hamish]

(this needs to be fixed in the qgis source code)

[hamish]

debugging session & problem identified in the C++ code here:

 http://hub.qgis.org/issues/2947#note-6

(the where and how it is broken, but not the why and exactly how to fix it)

Hamish

[hamish]

crappy work-around noted in comment:5 added in svn for testing.

start with comment:10 for a better way..

Hamish

[kalxas]

Tested yesterday and this workaround works. Lets wait for the next build to confirm.

[hamish]

the rc.local ownership change work-around is working in 6.0beta9, deferring ticket to 6.5..

[kalxas]

any news on this issue?

[hamish]

working but don't like the work around. punt down the line.