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.

[kalxas]

This is still open after so much time. The fix has been pushed to QGIS 2, which I am not sure we will get in for 7.0.

[hamish]

qgis 2.0 doesn't seem to be arriving for 7.0, so postponing to 7.5..

[hamish]

Not fixed in QGIS 2.0, Paolo's moved ​http://hub.qgis.org/issues/2947 to the future, so we have to as well.

Hamish

[hamish]

AFAIK still not fixed.

[kalxas]

This ticket is invalid for 8.5 since we moved to GRASS7.

[kalxas]

Given recent comments on other tickets, perhaps this should be re-opened.

[kalxas]

Ticket retargeted after milestone closed

[kalxas]

Is this still valid with QGIS 3.4?

[micha]

Errors using Browser with GRASS layers, and GRASS modules in Processing

[micha]

Sorry, but the problem seems to persist. See attached screen shot.

If I create a new GRASS location (not dependent on the nc_basic_spm built in location) then there's no problem. The errors arise only when attempting to use nc_basic_spm (or any mapset in that location) since its PERMANENT mapset is a simlink to /usr/local/share where the user does not have permissions.

[kalxas]

Ticket retargeted after milestone closed

[neteler]

Micha, could you please give it another try in the current OSGeolive 14 rc2?

You find the download of Version 14 rc2 at:

​http://aiolos.survey.ntua.gr/gisvm/14.0/

[micha]

QGIS-GRASS on OSGeoLive 14

[micha]

This issue still persists. I tested in the current OSGeoLive 14 rc. In QGIS I can browse the GRASS Location and Mapset nc_basic_spm_grass. And I can load raster layers. But vector layers appear with a red X and error in the browser window.

See attached screenshot.

[neteler]

Is this worth a new QGIS bug ticket?

[micha]

I have never heard anyone encountering this issue except in the context of OSGeo Live, with the (unusual?) setup of user's data stored read-only under /user/share/....

We know that GRASS is designed to handle this situation. QGIS, apparently not. Furthermore, most of the use of GRASS modules from within QGIS is through the Processing toolbox, which always uses tmp locations. So again, the problem never occurs.

I think we have two choices:

1. Just drop the issue due to lack of interest, and rewrite the QGIS quickstart to remove any mention of the GRASS location under /usr/share/data.
2. Move grassdata to user's home dir in place of the symlink, at the cost of losing group-shared data in a classroom setup.

[kalxas]

Ticket retargeted after milestone closed

[kalxas]

Hi Micha,

I have made some updates in the grass folder permissions, I hope this one is fixed now.

Can you please test and confirm?

[micha]

Seems to be good now. Making the symlink in user's grassdata to the PERMANENT location in /usr/local/share/grass was a good idea. Now I can create GRASS maps in both GRASS and QGIS.

But... I don't see the GRASS special folders in the QGIS browser. I can't find any way to load GRASS maps into QGIS. (On my local machine there are those special GRASS icons in the browser for all folders recognized as grass data.)

Should I open a new issue for this??

Thanks for all your ongoing effort!

[kalxas]

Thank you for testing!

Please open a new ticket for the new issue you found.