Opened 7 years ago

Last modified 4 weeks ago

#868 reopened defect

QGIS: Permissions on GRASS LOCATIONS

Reported by: micha Owned by: live-demo@…
Priority: normal Milestone: OSGeoLive13.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 (3)

QGIS_GRASS_error.png (18.2 KB) - added by micha 7 years ago.
QGIS_GRASS_error2.png (19.6 KB) - added by micha 7 years ago.
QGIS_scrot_OSGeo_13.png (228.6 KB) - added by micha 4 weeks ago.
Errors using Browser with GRASS layers, and GRASS modules in Processing

Download all attachments as: .zip

Change history (30)

comment:1 Changed 7 years ago by 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.

comment:2 in reply to:  1 Changed 7 years ago by 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.

comment:3 Changed 7 years ago by 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

Changed 7 years ago by micha

Attachment: QGIS_GRASS_error.png added

Changed 7 years ago by micha

Attachment: QGIS_GRASS_error2.png added

comment:4 in reply to:  3 ; Changed 7 years ago by 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

comment:5 in reply to:  4 ; Changed 7 years ago by 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

comment:6 Changed 7 years ago by hamish

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 Changed 7 years ago by hamish

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

comment:8 Changed 7 years ago by hamish

Summary: Permissions on GRASS LOCATIONSQGIS: Permissions on GRASS LOCATIONS

comment:9 Changed 7 years ago by kalxas

Milestone: OSGeoLive6.0Final

comment:10 Changed 7 years ago by 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

comment:11 in reply to:  5 Changed 7 years ago by hamish

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

start with comment:10 for a better way..

Hamish

comment:12 Changed 7 years ago by kalxas

Priority: majornormal

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

comment:13 Changed 7 years ago by hamish

Keywords: 6.5 added

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

comment:14 Changed 7 years ago by hamish

Milestone: OSGeoLive6.0FinalOSGeoLive6.5

comment:15 Changed 7 years ago by kalxas

any news on this issue?

comment:16 Changed 7 years ago by hamish

Milestone: OSGeoLive6.5OSGeoLive7.0

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

comment:17 Changed 7 years ago by camerons

Keywords: 7.0 added; 6.5 removed

comment:18 Changed 6 years ago by 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.

comment:19 Changed 6 years ago by hamish

Keywords: QGIS GRASS data permissions, 7.0QGIS, 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 Changed 5 years ago by hamish

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 Changed 5 years ago by hamish

Milestone: OSGeoLive8.0OSGeoLive8.5

AFAIK still not fixed.

comment:22 Changed 5 years ago by kalxas

Resolution: invalid
Status: newclosed

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

comment:23 Changed 12 months ago by kalxas

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

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

comment:24 Changed 12 months ago by kalxas

Cc: osgeolive@… added

comment:25 Changed 5 months ago by kalxas

Milestone: OSGeoLive12.0OSGeoLive13.0

Ticket retargeted after milestone closed

comment:26 Changed 4 weeks ago by kalxas

Is this still valid with QGIS 3.4?

Changed 4 weeks ago by micha

Attachment: QGIS_scrot_OSGeo_13.png added

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

comment:27 Changed 4 weeks ago by 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.

Note: See TracTickets for help on using tickets.