Opened 11 years ago

Closed 4 months ago

Last modified 4 months ago

#868 closed defect (fixed)

QGIS: Permissions on GRASS LOCATIONS

Reported by: micha Owned by: live-demo@…
Priority: normal Milestone: OSGeoLive15.0
Component: OSGeoLive Keywords: QGIS, GRASS, data permissions, 7.0
Cc: osgeolive@…

Description

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.

Attachments (4)

QGIS_GRASS_error.png (18.2 KB ) - added by micha 11 years ago.
QGIS_GRASS_error2.png (19.6 KB ) - added by micha 11 years ago.
QGIS_scrot_OSGeo_13.png (228.6 KB ) - added by micha 3 years ago.
Errors using Browser with GRASS layers, and GRASS modules in Processing
QGIS_3.16_GRASS_screen.jpg (139.1 KB ) - added by micha 20 months ago.
QGIS-GRASS on OSGeoLive 14

Download all attachments as: .zip

Change history (41)

comment:1 by epifanio, 11 years ago

+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.

in reply to:  1 comment:2 by micha, 11 years ago

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.

comment:3 by hamish, 11 years ago

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

by micha, 11 years ago

Attachment: QGIS_GRASS_error.png added

by micha, 11 years ago

Attachment: QGIS_GRASS_error2.png added

in reply to:  3 ; comment:4 by micha, 11 years ago

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

in reply to:  4 ; comment:5 by hamish, 11 years ago

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

comment:6 by hamish, 11 years ago

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

comment:7 by hamish, 10 years ago

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

comment:8 by hamish, 10 years ago

Summary: Permissions on GRASS LOCATIONSQGIS: Permissions on GRASS LOCATIONS

comment:9 by kalxas, 10 years ago

Milestone: OSGeoLive6.0Final

comment:10 by hamish, 10 years ago

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

in reply to:  5 comment:11 by hamish, 10 years ago

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

start with comment:10 for a better way..

Hamish

comment:12 by kalxas, 10 years ago

Priority: majornormal

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

comment:13 by hamish, 10 years ago

Keywords: 6.5 added

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

comment:14 by hamish, 10 years ago

Milestone: OSGeoLive6.0FinalOSGeoLive6.5

comment:15 by kalxas, 10 years ago

any news on this issue?

comment:16 by hamish, 10 years ago

Milestone: OSGeoLive6.5OSGeoLive7.0

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

comment:17 by camerons, 10 years ago

Keywords: 7.0 added; 6.5 removed

comment:18 by kalxas, 10 years ago

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.

comment:19 by hamish, 9 years ago

Keywords: QGIS GRASS data permissions, 7.0 → QGIS, GRASS, data permissions, 7.0
Milestone: OSGeoLive7.0OSGeoLive7.5

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

comment:20 by hamish, 9 years ago

Milestone: OSGeoLive7.9OSGeoLive8.0

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

comment:21 by hamish, 8 years ago

Milestone: OSGeoLive8.0OSGeoLive8.5

AFAIK still not fixed.

comment:22 by kalxas, 8 years ago

Resolution: invalid
Status: newclosed

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

comment:23 by kalxas, 4 years ago

Milestone: OSGeoLive8.5OSGeoLive12.0
Resolution: invalid
Status: closedreopened

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

comment:24 by kalxas, 4 years ago

Cc: osgeolive@… added

comment:25 by kalxas, 4 years ago

Milestone: OSGeoLive12.0OSGeoLive13.0

Ticket retargeted after milestone closed

comment:26 by kalxas, 3 years ago

Is this still valid with QGIS 3.4?

by micha, 3 years ago

Attachment: QGIS_scrot_OSGeo_13.png added

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

comment:27 by micha, 3 years ago

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.

comment:28 by kalxas, 3 years ago

Milestone: OSGeoLive13.0OSGeoLive14.0

Ticket retargeted after milestone closed

comment:29 by neteler, 20 months ago

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/

by micha, 20 months ago

Attachment: QGIS_3.16_GRASS_screen.jpg added

QGIS-GRASS on OSGeoLive 14

comment:30 by micha, 20 months ago

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.

QGIS-GRASS on OSGeoLive 14

comment:31 by neteler, 20 months ago

Is this worth a new QGIS bug ticket?

comment:32 by micha, 20 months ago

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.

comment:33 by kalxas, 18 months ago

Milestone: OSGeoLive14.0OSGeoLive15.0

Ticket retargeted after milestone closed

comment:34 by kalxas, 4 months ago

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?

comment:35 by micha, 4 months ago

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!

comment:36 by micha, 4 months ago

Resolution: fixed
Status: reopenedclosed

comment:37 by kalxas, 4 months ago

Thank you for testing!

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

Note: See TracTickets for help on using tickets.